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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, Mar 05, 2024 at 11:41:52PM +0800, Shung-Hsi Yu wrote:
> 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.

Thanks for the information!

greg k-h

> 
> > [snip]
>