In the Linux kernel, the following vulnerability has been resolved:
rcu: dump vmalloc memory info safely
Currently, for double invoke callrcu(), will dump rcuhead objects memory info, if the objects is not allocated from the slab allocator, the vmallocdumpobj() will be invoke and the vmaparealock spinlock need to be held, since the call_rcu() can be invoked in interrupt context, therefore, there is a possibility of spinlock deadlock scenarios.
And in Preempt-RT kernel, the rcutorture test also trigger the following lockdep warning:
BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 1, name: swapper/0 preemptcount: 1, expected: 0 RCU nest depth: 1, expected: 1 3 locks held by swapper/0/1: #0: ffffffffb534ee80 (fullstopmutex){+.+.}-{4:4}, at: tortureinitbegin+0x24/0xa0 #1: ffffffffb5307940 (rcureadlock){....}-{1:3}, at: rcutortureinit+0x1ec7/0x2370 #2: ffffffffb536af40 (vmaparealock){+.+.}-{3:3}, at: findvmaparea+0x1f/0x70 irq event stamp: 565512 hardirqs last enabled at (565511): [<ffffffffb379b138>] _callrcucommon+0x218/0x940 hardirqs last disabled at (565512): [<ffffffffb5804262>] rcutortureinit+0x20b2/0x2370 softirqs last enabled at (399112): [<ffffffffb36b2586>] _localbhenableip+0x126/0x170 softirqs last disabled at (399106): [<ffffffffb43fef59>] inetregisterprotosw+0x9/0x1d0 Preemption disabled at: [<ffffffffb58040c3>] rcutortureinit+0x1f13/0x2370 CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.5.0-rc4-rt2-yocto-preempt-rt+ #15 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x68/0xb0 dumpstack+0x14/0x20 _mightresched+0x1aa/0x280 ? _pfxrcutortureerrcb+0x10/0x10 rtspinlock+0x53/0x130 ? findvmaparea+0x1f/0x70 findvmaparea+0x1f/0x70 vmallocdumpobj+0x20/0x60 memdumpobj+0x22/0x90 _callrcucommon+0x5bf/0x940 ? debugsmpprocessorid+0x1b/0x30 callrcuhurry+0x14/0x20 rcutortureinit+0x1f82/0x2370 ? _pfxrcutortureleakcb+0x10/0x10 ? _pfxrcutortureleakcb+0x10/0x10 ? _pfxrcutortureinit+0x10/0x10 dooneinitcall+0x6c/0x300 ? debugsmpprocessorid+0x1b/0x30 kernelinitfreeable+0x2b9/0x540 ? _pfxkernelinit+0x10/0x10 kernelinit+0x1f/0x150 retfromfork+0x40/0x50 ? _pfxkernelinit+0x10/0x10 retfromforkasm+0x1b/0x30 </TASK>
The previous patch fixes this by using the deadlock-safe best-effort version of findvmarea. However, in case of failure print the fact that the pointer was a vmalloc pointer so that we print at least something.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2023/54xxx/CVE-2023-54113.json"
}