Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1359 CNY

100%

CVE-2021-47069— ipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry

Quick assessment

Affected
Linux Linux
Exploitation
No confirmed in-the-wild exploitation; assess based on exposure
Recommended action
Check the vendor advisory and references for a fixed version. If immediate upgrade is impossible, restrict exposure and increase monitoring.

Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。 Linux kernel存在安全漏洞,该漏洞源于do_mq_timedreceive 调用可能会返回并让 do_mq_timedsend 依赖于无效地址。

CVSS 7.8 · High EPSS 0.26% · P17

Affected Version Matrix 8

VendorProduct Version RangeStatus
Linux Linux c5b2cbdbdac563f46ecd5e187253ab1abbd6fc04< 4528c0c323085e645b8765913b4a7fd42cf49b65 affected
c5b2cbdbdac563f46ecd5e187253ab1abbd6fc04< 807fa14536b26803b858da878b643be72952a097 affected
c5b2cbdbdac563f46ecd5e187253ab1abbd6fc04< a11ddb37bf367e6b5239b95ca759e5389bb46048 affected
5.6 affected
< 5.6 unaffected
5.10.40≤ 5.10.* unaffected
5.12.7≤ 5.12.* unaffected
5.13≤ * unaffected
Get alerts for future matching vulnerabilities Log in to subscribe

I. Basic Information for CVE-2021-47069

Vulnerability Information

Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗

Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.

Vulnerability Title
ipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry
Source: CVE Program / CVE List V5
Vulnerability Description
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: 1. do_mq_timedreceive calls wq_sleep with the address of `struct ext_wait_queue` on function stack (aliased as `ewq_addr` here) - it holds a valid `struct ext_wait_queue *` as long as the stack has not been overwritten. 2. `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. 3. Sender calls __pipelined_op::smp_store_release(&this->state, STATE_READY). Here is where the race window begins. (`this` is `ewq_addr`.) 4. If the receiver wakes up now in do_mq_timedreceive::wq_sleep, it will see `state == STATE_READY` and break. 5. do_mq_timedreceive returns, and `ewq_addr` is no longer guaranteed to be a `struct 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.) 6. do_mq_timedsend::__pipelined_op() still believes `ewq_addr` is a `struct 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 overwritten `ewq_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.
Source: CVE Program / CVE List V5
CVSS Information
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Source: CVE Program / CVE List V5
Vulnerability Type
N/A
Source: CVE Program / CVE List V5
Vulnerability Title
Linux kernel 安全漏洞
Source: CNNVD (China National Vulnerability Database)
Vulnerability Description
Linux kernel是美国Linux基金会的开源操作系统Linux所使用的内核。 Linux kernel存在安全漏洞,该漏洞源于do_mq_timedreceive 调用可能会返回并让 do_mq_timedsend 依赖于无效地址。
Source: CNNVD (China National Vulnerability Database)
CVSS Information
N/A
Source: CNNVD (China National Vulnerability Database)
Vulnerability Type
N/A
Source: CNNVD (China National Vulnerability Database)

Affected Products

Vendor Product Affected Versions CPE Subscribe
Linux Linux c5b2cbdbdac563f46ecd5e187253ab1abbd6fc04 ~ 4528c0c323085e645b8765913b4a7fd42cf49b65 -
Linux Linux 5.6 -

II. Public POCs for CVE-2021-47069

# POC Description Source Link Shenlong Link
AI-Generated POC Premium

No public POC found.

Login to generate AI POC

III. Intelligence Information for CVE-2021-47069

请登录查看更多情报信息。

Other References for CVE-2021-47069 (3)

Same Patch Batch · Linux · 2024-03-01 · 13 CVEs total

CVE-2021-47081 7.8 HIGH habanalabs/gaudi: Fix a potential use after free in gaudi_memset_device_memory
CVE-2021-47078 7.8 HIGH RDMA/rxe: Clear all QP fields if creation failed
CVE-2021-47080 RDMA/core: Prevent divide-by-zero error triggered by the user
CVE-2021-47079 platform/x86: ideapad-laptop: fix a NULL pointer dereference
CVE-2021-47077 scsi: qedf: Add pointer checks in qedf_update_link_speed()
CVE-2021-47075 nvmet: fix memory leak in nvmet_alloc_ctrl()
CVE-2021-47076 RDMA/rxe: Return CQE error if invalid lkey was supplied
CVE-2021-47074 nvme-loop: fix memory leak in nvme_loop_create_ctrl()
CVE-2021-47072 btrfs: fix removed dentries still existing after log is synced
CVE-2021-47073 platform/x86: dell-smbios-wmi: Fix oops on rmmod dell_smbios
CVE-2021-47071 uio_hv_generic: Fix a memory leak in error handling paths
CVE-2021-47070 uio_hv_generic: Fix another memory leak in error handling paths

IV. Related Vulnerabilities

V. Comments for CVE-2021-47069

No comments yet


Leave a comment