Bug 2266340 (CVE-2023-52468)

Summary:	CVE-2023-52468 kernel: use-after-free in class_register()
Product:	[Other] Security Response	Reporter:	Rohit Keshri <rkeshri>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	acaringi, allarkin, aquini, bhu, chwhite, cye, cyin, dbohanno, debarbos, dfreiber, drow, dvlasenk, esandeen, ezulian, gcovolo, hkrzesin, jarod, jburrell, jdenham, jfaracco, jforbes, jlelli, joe.lawrence, jshortt, jstancek, jwyatt, kcarcia, ldoskova, lgoncalv, lzampier, mleitner, mmilgram, mstowell, nmurray, ptalbert, rparrazo, rrobaina, rvrbovsk, scweaver, sukulkar, tglozar, vkumar, wcosta, williams, wmealing, ycote, ykopkova, zhijwang
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:	A use-after-free flaw was found in class_register() in the Linux kernel. This issue occurs due to the lock_class_key is still being registered and found in lock_keys_hash hlist after subsys_private is freed in the error handler path. If a task iterates over the lock_keys_hash, it may cause a use-after-free.	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:	2266342
Bug Blocks:	2266208

Description Rohit Keshri 2024-02-27 16:32:32 UTC

In the Linux kernel, the following vulnerability has been resolved:

class: fix use-after-free in class_register()

The lock_class_key is still registered and can be found in
lock_keys_hash hlist after subsys_private is freed in error
handler path.A task who iterate over the lock_keys_hash
later may cause use-after-free.So fix that up and unregister
the lock_class_key before kfree(cp).

On our platform, a driver fails to kset_register because of
creating duplicate filename '/class/xxx'.With Kasan enabled,
it prints a invalid-access bug report.

KASAN bug report:

BUG: KASAN: invalid-access in lockdep_register_key+0x19c/0x1bc
Write of size 8 at addr 15ffff808b8c0368 by task modprobe/252
Pointer tag: [15], memory tag: [fe]

CPU: 7 PID: 252 Comm: modprobe Tainted: G        W
 6.6.0-mainline-maybe-dirty #1

Call trace:
dump_backtrace+0x1b0/0x1e4
show_stack+0x2c/0x40
dump_stack_lvl+0xac/0xe0
print_report+0x18c/0x4d8
kasan_report+0xe8/0x148
__hwasan_store8_noabort+0x88/0x98
lockdep_register_key+0x19c/0x1bc
class_register+0x94/0x1ec
init_module+0xbc/0xf48 [rfkill]
do_one_initcall+0x17c/0x72c
do_init_module+0x19c/0x3f8
...
Memory state around the buggy address:
ffffff808b8c0100: 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a
ffffff808b8c0200: 8a 8a 8a 8a 8a 8a 8a 8a fe fe fe fe fe fe fe fe
>ffffff808b8c0300: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
                                     ^
ffffff808b8c0400: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03

As CONFIG_KASAN_GENERIC is not set, Kasan reports invalid-access
not use-after-free here.In this case, modprobe is manipulating
the corrupted lock_keys_hash hlish where lock_class_key is already
freed before.

It's worth noting that this only can happen if lockdep is enabled,
which is not true for normal system.

https://git.kernel.org/stable/c/0f1486dafca3398c4c46b9f6e6452fa27e73b559
https://git.kernel.org/stable/c/93ec4a3b76404bce01bd5c9032bef5df6feb1d62
https://git.kernel.org/stable/c/b57196a5ec5e4c0ffecde8348b085b778c7dce04

Comment 1 Rohit Keshri 2024-02-27 16:44:04 UTC

Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 2266342]

Comment 3 Justin M. Forbes 2024-02-27 18:54:18 UTC

This was resolved for Fedora with the 6.6.14 stable kernel updates.

Comment 6 Alex 2024-06-09 16:44:50 UTC

The result of automatic check (that is developed by Alexander Larkin) for this CVE-2023-52468 is: CHECK	Maybe valid. Check manually. with impact LOW (that is an approximation based on flags KASAN INIT UAF  ; 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.