Bug 2265798 (CVE-2023-52462)

Summary: CVE-2023-52462 kernel: bpf: fix check for attempt to corrupt spilled pointer
Product: [Other] Security Response Reporter: Patrick Del Bello <pdelbell>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: acaringi, allarkin, aquini, bhu, chwhite, cye, cyin, dbohanno, debarbos, dfreiber, drow, dvlasenk, esandeen, ezulian, hkrzesin, jarod, jburrell, jdenham, jfaracco, jforbes, jlelli, joe.lawrence, jshortt, jstancek, jwyatt, kcarcia, ldoskova, lgoncalv, lzampier, mleitner, mmilgram, mstowell, nmurray, ptalbert, rparrazo, rrobaina, rvrbovsk, rysulliv, scweaver, sukulkar, tglozar, tyberry, vkumar, wcosta, williams, wmealing, ycote, ykopkova, zhijwang
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: kernel 6.8-rc1 Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in the Linux kernel. When the register is spilled onto a stack as a 1/2/4-byte register, the slot_type[BPF_REG_SIZE - 1]  is set, possibly including a few more below it, depending on the actual spill size. To confirm if some stack slots have a spilled register, consult slot_type[7], not slot_type[0]. To avoid the need to remember and double-check this in the future, use the is_spilled_reg() helper.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2265810    
Bug Blocks: 2265790    

Description Patrick Del Bello 2024-02-24 11:20:21 UTC
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.

Comment 1 Patrick Del Bello 2024-02-24 11:25:38 UTC
Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 2265810]

Comment 3 Justin M. Forbes 2024-02-27 00:04:14 UTC
	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

Comment 4 Justin M. Forbes 2024-02-27 00:04:43 UTC
This was fixed for Fedora with the 6.6.14 stable kernel updates.

Comment 6 Alex 2024-06-09 16:52:26 UTC
The result of automatic check (that is developed by Alexander Larkin) for this CVE-2023-52462 is: CHECK	Maybe valid. Check manually. with impact LOW (that is an approximation based on flags BPF SIMPLEFIX LEAK IMPROVEONLY  ; these flags parsed automatically based on patch data). Such automatic check happens only for Low/Moderates (and only when not from reporter, but parsing already existing CVE). Highs always checked manually (I check it myself and then we check it again in Remediation team). In rare cases some of the Moderates could be increased to High later.

Comment 7 errata-xmlrpc 2024-11-12 09:18:41 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2024:9315 https://access.redhat.com/errata/RHSA-2024:9315