Re: CVE-2023-52462: bpf: fix check for attempt to corrupt spilled pointer

[Shung-Hsi Yu]

On Fri, Feb 23, 2024 at 03:47:35PM +0100, Greg Kroah-Hartman wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> bpf: fix check for attempt to corrupt spilled pointer
> 
> When register is spilled onto a stack as a 1/2/4-byte register, we set
> slot_type[BPF_REG_SIZE - 1] (plus potentially few more below it,
> depending on actual spill size). So to check if some stack slot has
> spilled register we need to consult slot_type[7], not slot_type[0].
> 
> To avoid the need to remember and double-check this in the future, just
> use is_spilled_reg() helper.
> 
> The Linux kernel CVE team has assigned CVE-2023-52462 to this issue.
> 
> 
> Affected and fixed versions
> ===========================
> 
> 	Issue introduced in 5.10.163 with commit cdd73a5ed084 and fixed in 5.10.209 with commit 2757f17972d8
> 	Issue introduced in 5.15.86 with commit 07c286c10a9c and fixed in 5.15.148 with commit 67e6707f0735
> 	Issue introduced in 5.16 with commit 27113c59b6d0 and fixed in 6.1.75 with commit fc3e3c50a0a4
> 	Issue introduced in 5.16 with commit 27113c59b6d0 and fixed in 6.6.14 with commit 8dc15b067059
> 	Issue introduced in 5.16 with commit 27113c59b6d0 and fixed in 6.7.2 with commit 40617d45ea05
> 	Issue introduced in 5.16 with commit 27113c59b6d0 and fixed in 6.8-rc1 with commit ab125ed3ec1c

While commit 27113c59b6d0 ("bpf: Check the other end of slot_type for
STACK_SPILL") is referenced in the Fixes tag, and made the switch to use
slot_type[7] instead of slot_type[0]. This shouldn't cause any issue
because its commit message stated that

  ... Verifier currently only saves the reg state if the whole 8 bytes
  are spilled to the stack, so checking the slot_type[7] is the same as
  checking slot_type[0].

It is the next commit in the series, commit 354e8f1970f8 ("bpf: Support
<8-byte scalar spill and refill"), that rendered checking slot_type[0]
problematic.

So I believe the issue is introduced with commit 354e8f1970f8 rather
than 27113c59b6d0. That said kernel releases seems to either contain
both or none of them at all, so in pratice the difference probably
doesn't matter too much.

> [snip]