Microsoft Security Response Center guidance
Vendor revision: Oct 21, 2026Release Notes
Vendor-listed releases
- 6.6.157.1-1
Vulnerability intelligence
CVE-2026-93191. It is not in the current CISA KEV record we collected. That does not prove exploitation has not occurred.
Release Notes
Vendor-listed releases
In the Linux kernel, the following vulnerability has been resolved:
smack: fix incorrect task context in smack_msg_queue_msgrcv
The smack_msg_queue_msgrcv() function incorrectly checks the permissions of the 'current' task instead of the 'target' task.
In the msgsnd() syscall path, if a receiver is already waiting, the pipelined_send() optimization is used to push the message directly to the receiver task:
ipc/msg.c`pipelined_send(): ` smp_store_release(&msr->r_msg, msg)
In this case, the 'sender' (current) task performs the check on behalf of the 'receiver' task (msr->r_tsk, passed as the 'target' parameter):
ipc/msg.c`pipelined_send(): ` security_msg_queue_msgrcv(,, target := msr->r_tsk,,)
However, smack_msg_queue_msgrcv() ignores the 'target' and checks 'current':
smack_msg_queue_msgrcv(…) ` smk_curacc_msq(isp, MAY_READWRITE); // current task
'current' MAY satisfy smack_msg_queue_msgrcv r/w requirement, but 'target' (the receiver task) might NOT; as a result, an unauthorized receiver gets the message, violating MAC policy.
Test: 1) create a sysv message queue with label “foo” 2) echo "bar foo r" >/smack/load2 3) msgrcv(,,,0,MSG_NOERROR) in "bar"-labeled task. The task is waiting for the messages ...
4) msgsnd() from a "foo"-labeled task: "bar"-labeled task gets the message.
This patch fixes the issue by checking permission on the 'target' task instead of 'current'.
(2008-02-04, Casey Schaufler)
Source: NVD