CVE-2024-53160: rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu
In the Linux kernel, the following vulnerability has been resolved:
rcu/kvfree: Fix data-race in modtimer / kvfreecallrcu
KCSAN reports a data race when access the krcp->monitorwork.timer.expires variable in the scheduledelayedmonitorwork() function:
<snip> BUG: KCSAN: data-race in modtimer / kvfreecallrcu
read to 0xffff888237d1cce8 of 8 bytes by task 10149 on cpu 1: scheduledelayedmonitorwork kernel/rcu/tree.c:3520 [inline] kvfreecallrcu+0x3b8/0x510 kernel/rcu/tree.c:3839 trieupdateelem+0x47c/0x620 kernel/bpf/lpmtrie.c:441 bpfmapupdatevalue+0x324/0x350 kernel/bpf/syscall.c:203 genericmapupdatebatch+0x401/0x520 kernel/bpf/syscall.c:1849 bpfmapdobatch+0x28c/0x3f0 kernel/bpf/syscall.c:5143 sysbpf+0x2e5/0x7a0 dosysbpf kernel/bpf/syscall.c:5741 [inline] sesysbpf kernel/bpf/syscall.c:5739 [inline] x64sysbpf+0x43/0x50 kernel/bpf/syscall.c:5739 x64syscall+0x2625/0x2d60 arch/x86/include/generated/asm/syscalls64.h:322 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xc9/0x1c0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f
write to 0xffff888237d1cce8 of 8 bytes by task 56 on cpu 0: modtimer+0x578/0x7f0 kernel/time/timer.c:1173 addtimerglobal+0x51/0x70 kernel/time/timer.c:1330 queuedelayedwork+0x127/0x1a0 kernel/workqueue.c:2523 queuedelayedworkon+0xdf/0x190 kernel/workqueue.c:2552 queuedelayedwork include/linux/workqueue.h:677 [inline] scheduledelayedmonitorwork kernel/rcu/tree.c:3525 [inline] kfreercumonitor+0x5e8/0x660 kernel/rcu/tree.c:3643 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0x483/0x9a0 kernel/workqueue.c:3310 workerthread+0x51d/0x6f0 kernel/workqueue.c:3391 kthread+0x1d1/0x210 kernel/kthread.c:389 retfromfork+0x4b/0x60 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244
Reported by Kernel Concurrency Sanitizer on: CPU: 0 UID: 0 PID: 56 Comm: kworker/u8:4 Not tainted 6.12.0-rc2-syzkaller-00050-g5b7c893ed5ed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: eventsunbound kfreercumonitor <snip>
kfreercumonitor() rearms the work if a "krcp" has to be still offloaded and this is done without holding krcp->lock, whereas the kvfreecallrcu() holds it.
Fix it by acquiring the "krcp->lock" for kfreercumonitor() so both functions do not race anymore.
Other sources
In the Linux kernel, the following vulnerability has been resolved:
rcu/kvfree: Fix data-race in modtimer / kvfreecallrcu
KCSAN reports a data race when access the krcp->monitorwork.timer.expires variable in the scheduledelayedmonitorwork() function:
<snip> BUG: KCSAN: data-race in modtimer / kvfreecallrcu
read to 0xffff888237d1cce8 of 8 bytes by task 10149 on cpu 1: scheduledelayedmonitorwork kernel/rcu/tree.c:3520 [inline] kvfreecallrcu+0x3b8/0x510 kernel/rcu/tree.c:3839 trieupdateelem+0x47c/0x620 kernel/bpf/lpmtrie.c:441 bpfmapupdatevalue+0x324/0x350 kernel/bpf/syscall.c:203 genericmapupdatebatch+0x401/0x520 kernel/bpf/syscall.c:1849 bpfmapdobatch+0x28c/0x3f0 kernel/bpf/syscall.c:5143 sysbpf+0x2e5/0x7a0 dosysbpf kernel/bpf/syscall.c:5741 [inline] sesysbpf kernel/bpf/syscall.c:5739 [inline] x64sysbpf+0x43/0x50 kernel/bpf/syscall.c:5739 x64syscall+0x2625/0x2d60 arch/x86/include/generated/asm/syscalls64.h:322 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xc9/0x1c0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f
write to 0xffff888237d1cce8 of 8 bytes by task 56 on cpu 0: modtimer+0x578/0x7f0 kernel/time/timer.c:1173 addtimerglobal+0x51/0x70 kernel/time/timer.c:1330 queuedelayedwork+0x127/0x1a0 kernel/workqueue.c:2523 queuedelayedworkon+0xdf/0x190 kernel/workqueue.c:2552 queuedelayedwork include/linux/workqueue.h:677 [inline] scheduledelayedmonitorwork kernel/rcu/tree.c:3525 [inline] kfreercumonitor+0x5e8/0x660 kernel/rcu/tree.c:3643 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0x483/0x9a0 kernel/workqueue.c:3310 workerthread+0x51d/0x6f0 kernel/workqueue.c:3391 kthread+0x1d1/0x210 kernel/kthread.c:389 retfromfork+0x4b/0x60 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244
Reported by Kernel Concurrency Sanitizer on: CPU: 0 UID: 0 PID: 56 Comm: kworker/u8:4 Not tainted 6.12.0-rc2-syzkaller-00050-g5b7c893ed5ed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: eventsunbound kfreercumonitor <snip>
kfreercumonitor() rearms the work if a "krcp" has to be still offloaded and this is done without holding krcp->lock, whereas the kvfreecallrcu() holds it.
Fix it by acquiring the "krcp->lock" for kfreercumonitor() so both functions do not race anymore.
— NVD
This CVE was automatically created from a reference found in an email or other text. If you are reading this, then this CVE entry is probably erroneous, since this text should be replaced by the official CVE description automatically.
— Launchpad
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2024-53160?
CVE-2024-53160 has been classified with a moderate severity due to the data race issues it introduces in the Linux kernel.
How do I fix CVE-2024-53160?
To fix CVE-2024-53160, upgrading to the latest stable version of the Linux kernel that includes the patch for this vulnerability is recommended.
What component of the Linux kernel is affected by CVE-2024-53160?
CVE-2024-53160 affects the rcu/kvfree subsystem of the Linux kernel.
What are the potential consequences of exploiting CVE-2024-53160?
Exploitation of CVE-2024-53160 could lead to data corruption or unpredictable behavior due to the data race present in the code.
Are there any workarounds for CVE-2024-53160 before applying a patch?
There are no specific workarounds for CVE-2024-53160 recommended; applying the patch is the best course of action.