CVE-2026-93191 in Linuxinfo

Summary

by MITRE • 09/18/2026

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)

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 09/18/2026

The Linux Security Module Smack implements Mandatory Access Control to enforce security policies based on labels assigned to processes and objects. A critical flaw was identified in the implementation of message queue receive operations within this module, specifically in the function smack_msg_queue_msgrcv. This vulnerability stems from an incorrect evaluation of task context during permission checks when a message is transferred directly between tasks via kernel optimization paths. The issue arises because the security hook receives a target parameter representing the receiving process but fails to utilize it for access control decisions, instead defaulting to checking permissions against the currently executing task.

The operational impact becomes apparent during the execution of the msgsnd system call when a receiver is already waiting on a System V message queue. In such scenarios, the kernel employs an optimization known as pipelined_send to bypass standard queuing mechanisms and deliver the message directly to the receiving task's buffer. During this direct transfer, the security subsystem invokes smack_msg_queue_msgrcv with the target parameter set to the receiver task structure. However, the vulnerable implementation ignores this target context and evaluates access rights against current, which refers to the sender process that initiated the write operation. This logical error allows a message to be delivered even if the actual recipient lacks the necessary Smack labels or permissions to read it, effectively bypassing Mandatory Access Control restrictions.

This flaw constitutes an unauthorized information disclosure vulnerability where sensitive data can leak across security domains due to insufficient access control enforcement. From a classification perspective, this aligns with CWE-284 Improper Access Control and CWE-755 Incorrect Choice of Less Restrictive Operation. In the context of the MITRE ATT&CK framework, this behavior facilitates lateral movement or privilege escalation by allowing processes operating under lower security labels to receive data intended for higher privileged contexts if the sender has sufficient permissions. The vulnerability undermines the integrity of the Smack policy model by decoupling access decisions from the actual subject performing the action in asynchronous message passing scenarios.

The resolution involves modifying smack_msg_queue_msgrcv to correctly utilize the target task parameter when determining read-write permissions. By ensuring that permission checks are performed against the receiving process rather than the sending process, the kernel restores proper enforcement of Smack labels on System V IPC objects. To mitigate this risk in affected systems, administrators should apply the latest available kernel patches that include this fix. Additionally, organizations relying on Smack for strict isolation between processes should verify their message queue configurations and ensure that all components are updated to prevent potential policy violations through direct task-to-task communication paths.

Responsible

Linux

Reservation

09/17/2026

Disclosure

09/18/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you need the next level of professionalism?

Upgrade your account now!