CVE-2026-93191
NoneCVSS
—
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A kernel bug could let some programs read messages sent through the operating system that they were never supposed to see.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Authorization Bypass
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
The smack_msg_queue_msgrcv() function performs its MAC permission check against the calling task instead of the intended receiver task passed via the target parameter during pipelined_send(), allowing a receiver whose label would fail the check to obtain messages anyway.
Why it matters to the business
Processes may receive inter-process messages across mandatory access-control boundaries, enabling unauthorized data flow that can expose sensitive information in Smack-protected environments.
How an attack unfolds
An attacker prepares a SysV message queue labeled foo and configures Smack rules so that only foo-labeled tasks should read or write it. A receiver task labeled bar is made to block in msgrcv(). When a foo-labeled sender calls msgsnd(), the pipelined_send() path invokes the LSM hook with the bar task as target, yet the flawed check evaluates the sender instead, delivering the message to bar and bypassing policy.
How to fix it
Apply the upstream fix that changes smack_msg_queue_msgrcv() to evaluate permissions against the supplied target task rather than current; rebuild and deploy the corrected kernel on all affected systems.
How to confirm the fix worked
Inspect the patched smack_msg_queue_msgrcv() implementation to confirm the target task is used for the smk_curacc_msq() call, then re-execute the labeled-task test case to verify the receiver is now denied.
Typical attack path
- Create a SysV message queue labeled foo
- Load Smack rules permitting foo read/write access but denying it to bar
- Start a bar-labeled task that blocks in msgrcv() on the queue
- Execute msgsnd() from a foo-labeled task
- Observe the bar-labeled task receiving the message despite the policy violation
How to detect it
Examine system call traces or audit logs for sequences of msgsnd() immediately followed by msgrcv() completion across tasks whose Smack labels would normally be denied; correlate with /smack/load2 rule changes around the same time.
What your security team should do
- Prioritize kernel updates containing the fix for all Smack-enabled distributions
- Audit custom kernels or out-of-tree LSM modules for similar target-parameter handling errors
- Review IPC usage in high-security workloads for reliance on Smack message-queue enforcement
The record
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)
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|