Race Condition Affecting kernel-zfcpdump-devel package, versions <0:4.18.0-372.119.1.el8_6
Threat Intelligence
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk ID SNYK-RHEL8-KERNELZFCPDUMPDEVEL-7755083
- published 21 Aug 2024
- disclosed 1 Mar 2024
Introduced: 1 Mar 2024
CVE-2021-47069 Open this link in a new tabHow to fix?
Upgrade RHEL:8
kernel-zfcpdump-devel
to version 0:4.18.0-372.119.1.el8_6 or higher.
This issue was patched in RHSA-2024:5692
.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-zfcpdump-devel
package and not the kernel-zfcpdump-devel
package as distributed by RHEL
.
See How to fix?
for RHEL:8
relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
ipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry
do_mq_timedreceive calls wq_sleep with a stack local address. The sender (do_mq_timedsend) uses this address to later call pipelined_send.
This leads to a very hard to trigger race where a do_mq_timedreceive call might return and leave do_mq_timedsend to rely on an invalid address, causing the following crash:
RIP: 0010:wake_q_add_safe+0x13/0x60 Call Trace: __x64_sys_mq_timedsend+0x2a9/0x490 do_syscall_64+0x80/0x680 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f5928e40343
The race occurs as:
do_mq_timedreceive calls wq_sleep with the address of
struct ext_wait_queue
on function stack (aliased asewq_addr
here) - it holds a validstruct ext_wait_queue *
as long as the stack has not been overwritten.ewq_addr
gets added to info->e_wait_q[RECV].list in wq_add, and do_mq_timedsend receives it via wq_get_first_waiter(info, RECV) to call __pipelined_op.Sender calls __pipelined_op::smp_store_release(&this->state, STATE_READY). Here is where the race window begins. (
this
isewq_addr
.)If the receiver wakes up now in do_mq_timedreceive::wq_sleep, it will see
state == STATE_READY
and break.do_mq_timedreceive returns, and
ewq_addr
is no longer guaranteed to be astruct ext_wait_queue *
since it was on do_mq_timedreceive's stack. (Although the address may not get overwritten until another function happens to touch it, which means it can persist around for an indefinite time.)do_mq_timedsend::__pipelined_op() still believes
ewq_addr
is astruct ext_wait_queue *
, and uses it to find a task_struct to pass to the wake_q_add_safe call. In the lucky case where nothing has overwrittenewq_addr
yet,ewq_addr->task
is the right task_struct. In the unlucky case, __pipelined_op::wake_q_add_safe gets handed a bogus address as the receiver's task_struct causing the crash.
do_mq_timedsend::__pipelined_op() should not dereference this
after
setting STATE_READY, as the receiver counterpart is now free to return.
Change __pipelined_op to call wake_q_add_safe on the receiver's
task_struct returned by get_task_struct, instead of dereferencing this
which sits on the receiver's stack.
As Manfred pointed out, the race potentially also exists in ipc/msg.c::expunge_all and ipc/sem.c::wake_up_sem_queue_prepare. Fix those in the same way.