CVE-2026-93191: smack: fix incorrect task context in smack_msg_queue_msgrcv
In the Linux kernel, the following vulnerability has been resolved:
smack: fix incorrect task context in smackmsgqueuemsgrcv
The smackmsgqueuemsgrcv() 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 pipelinedsend() optimization is used to push the message directly to the receiver task:
ipc/msg.cpipelinedsend(): smpstorerelease(&msr->rmsg, msg)
In this case, the 'sender' (current) task performs the check on behalf of the 'receiver' task (msr->rtsk, passed as the 'target' parameter):
ipc/msg.cpipelinedsend(): securitymsgqueuemsgrcv(,, target := msr->rtsk,,)
However, smackmsgqueuemsgrcv() ignores the 'target' and checks 'current':
smackmsgqueuemsgrcv(…) smkcuraccmsq(isp, MAYREADWRITE); // current task
'current' MAY satisfy smackmsgqueuemsgrcv 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,MSGNOERROR) 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)
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch smack: fix incorrect task context in smack_msg_queue_msgrcv
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems using the Linux kernel's Smack mandatory access control mechanism and System V message queues are exposed when a receiver is already waiting for a message. The demonstrated policy setup involves a queue labeled "foo" and a waiting receiver task labeled "bar".
What conditions are required for exploitation?
A sender must send to a System V message queue while a receiver is already waiting, causing the kernel to use the pipelined_send() path. The sender must satisfy the queue read/write permission check even though the waiting receiver does not have the required access.
What is the security impact?
An unauthorized waiting receiver can receive a message despite lacking the Smack MAC permissions required for that queue. This violates the configured mandatory access-control policy.
How can I tell whether a system is affected?
Check whether Smack is enabled and whether workloads use System V message queues with waiting receivers under differing Smack labels. A relevant test setup is a queue labeled "foo", a "bar"-labeled task waiting in msgrcv(), and a rule granting "bar" read access to "foo".