linux-kernel - Re: Query Regarding Stack-Out-of-Bounds Error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHhAz+gknOcLZKqU1EvNtH0JbWMVvyj7LjGbFpdeiDbUM8HsHw@mail.gmail.com>
Date: Tue, 27 Aug 2024 16:01:49 +0530
From: Muni Sekhar <munisekharrms@...il.com>
To: Valdis Klētnieks <valdis.kletnieks@...edu>
Cc: kernelnewbies <kernelnewbies@...nelnewbies.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Query Regarding Stack-Out-of-Bounds Error

On Tue, Aug 27, 2024 at 1:16 AM Valdis Klētnieks
<valdis.kletnieks@...edu> wrote:
>
> On Mon, 26 Aug 2024 18:04:39 +0530, Muni Sekhar said:
>
> > static struct cmd_info *find_cmd_entry_any_ring(struct intel_gvt *gvt,
> >                unsigned int opcode, int rings)
> > {
> >         struct cmd_info *info = NULL;
> >         unsigned int ring;
> >         ...
> >         for_each_set_bit(ring, (unsigned long *)&rings, I915_NUM_ENGINES) {
> >
> > In the above code, a 32-bit integer pointer (rings) is being cast to a
> > 64-bit unsigned long pointer, which leads to an extra 4 bytes being
> > accessed. This raises a concern regarding a stack-out-of-bounds bug.
> >
> > My specific query is: While it is logically understandable that a
> > write operation involving these extra 4 bytes could cause a kernel
> > crash, in this case, it is a read operation that is occurring.
>
> Note that 'ring' is located in the stack frame for the current function. So to
> complete the analysis - is there any way that the stack frame can be located in
> such a way that 'ring' is the *very last* 4 bytes on a page, and the next page
> *isn't* allocated, *and* I915_NUM_ENGINES is big enough to cause the loop to walk
> off the end?
>
> For bonus points, part 1:  Does the answer depend on whether the architecture
> has stacks that grow up, or grow down in address?

Stack Frame Example

|---------------------------|
| Return Address            |
|---------------------------|
| Saved Frame Pointer       |
|---------------------------|
| Parameter: gvt            |
|---------------------------|
| Parameter: opcode         |
|---------------------------|
| Parameter: rings          |
|---------------------------|
| Local Variable: info      |
|---------------------------|
| Local Variable: ring      |
|---------------------------|

If the stack grows downwards, the previous 32 bits (4 bytes) before
rings will be read as part of the 64-bit value.
If the stack grows upwards, the next 32 bits (4 bytes) after rings
will be read as part of the 64-bit value.
Consider that the stack grows upwards and the "ring" variable is
located at the very end of a stack page. What should be the value of
I915_NUM_ENGINES to trigger the Stack-Out-of-Bounds crash?

>
> For bonus points, part 2: can this function be called quickly enough, and
> enough times, that it can be abused to do something interesting to L1/L2 cache
> and speculative execution, because some systems will fetch not only the bytes
> needed, but as much as 64 or 128 bytes of cache line?  Can you name 3 security
> bugs that abused this sort of thing?
>
> Free hint:  There's a bit of interesting code in kernel/exit.c that tells you if
> your system has gotten close to running out of kernel stack.
>
> [/usr/src/linux-next] dmesg | grep 'greatest stack'
> [    1.093400] [     T40] pgdatinit0 (40) used greatest stack depth: 13920 bytes left
> [    3.832907] [     T82] modprobe (82) used greatest stack depth: 8 bytes left
>
> Hmm... wonder how that modprobe managed *that* :)
>
>
>


-- 
Thanks,
Sekhar