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

["Valdis Klētnieks" <valdis.kletnieks@vt.edu>]

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?

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* :)


\0\0\0\0\0\0\0\0

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies