kernel/git/next/linux-next.git/security/smack, branch master

security: Remove pagemap.h includes

2026-08-25T19:12:26+00:00

The security subsystem does not use the page cache. Removing just the pagemap.h includes isn't quite enough to insulate it from changes to pagemap as it's also pulled in by swap.h and hugetlb.h. Fortunately, security doesn't need either of those so we can lose all three. Now touching pagemap.h causes no rebuilds in the security subsystem. Signed-off-by: Matthew Wilcox (Oracle)

Merge tag 'Smack-for-7.3' of https://github.com/cschaufler/smack-next

2026-08-19T23:51:39+00:00

Pull smack updates from Casey Schaufler: - Spelling fix - Code optimization in smackfs - Fix credential mis-uses - Place limits on two of the smackfs interfaces * tag 'Smack-for-7.3' of https://github.com/cschaufler/smack-next: smack: fix cred UAF in smack_file_send_sigiotask() smack: restrict smackfs/{direct,mapped} values to 0-255 smack: deduplicate smackfs/{direct,mapped} file_operations smack: show msgrcv() subject task in audit smack: fix incorrect task context in smack_msg_queue_msgrcv security: smack: fix spelling mistake smack: simplify write handlers of sysfs entries Smack: Fix error in capability bypass

smack: fix cred UAF in smack_file_send_sigiotask()

2026-08-08T16:47:22+00:00

When inspecting the credentials of another task, objective credentials (->real_cred, accessed with __task_cred()) must always be used. Accessing ->cred on a non-current task is forbidden unless that task is being created or destroyed; a task is allowed to change its own ->cred pointer with no synchronization, and changing ->cred should only affect the current syscall. smack_file_send_sigiotask() was accessing both sets of credentials: First tsk->cred, then __task_cred(tsk). Fix it, always access the objective credentials here. I have tested that this bug can lead to a KASAN-reported UAF of struct cred in smack_file_send_sigiotask(), and that this fix prevents the race. Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Signed-off-by: Casey Schaufler

smack: restrict smackfs/{direct,mapped} values to 0-255

2026-06-22T20:52:24+00:00

Both smackfs/direct and smackfs/mapped incorrectly accept the full range of integer values. For example: # cd /sys/fs/smackfs/ # cat direct ; echo 250 # cat cipso2 @ 250/2 _ 250/2,4,5,6,7,8 * 250/3,5,7 ^ 250/2,4,5,6,7 ? 250/3,4,5,6,7,8 # echo -1234 >direct ; cat direct ; echo -1234 # cat cipso2 @ -1234/2 _ -1234/2,4,5,6,7,8 * -1234/3,5,7 ^ -1234/2,4,5,6,7 ? -1234/3,4,5,6,7,8 # I noticed two things regarding this: 1) sensitivity levels are truncated to 8 bits when labeling outgoing packets (0x2e = 46 for the -1234 example above) 2) the reverse process fails: incoming packets with sensitivity level 46 do not match these smackfs/cipso2 entries. Even observation (1) on its own warrants a fix. This patch restricts smackfs/direct and smackfs/mapped accepted values to the 0-255 range. Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler

smack: deduplicate smackfs/{direct,mapped} file_operations

2026-06-22T20:52:07+00:00

The file_operations for smackfs/direct and smackfs/mapped are identical up to a textual replacement of "direct" with "mapped" This patch combines two instances of file_operations into one, handling both files. Fixes: f7112e6c9abf ("Smack: allow for significantly longer Smack labels v4") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler

smack: show msgrcv() subject task in audit

2026-06-22T18:16:40+00:00

When a task msgrcv()'es some message the SMACK audit log message looks like: fn=smk_tskacc_msq action=denied subject="bar" object="foo" requested=rw pid=456 comm="mrcv" ipc_key=2 fn=smk_tskacc_msq action=granted subject="bar" object="foo" requested=rw pid=519 comm="mrcv" ipc_key=2 where pid= is a pid of a “current” task which calls smk_tskacc_msq(). Usually, the caller of smk_tskacc_msq() is also a subject task which determines its own permission. In the example above the 'mrcv' process has label 'bar' and wants "rw" for label "foo". However, when sender task delivers message using ipc/msg.c`pipelined_send(): ` security_msg_queue_msgrcv(,, msr->r_tsk,,) ` smp_store_release(&msr->r_msg, msg) “current” task and “subject” task differ, and the “subject” task is missed from the audit message. This patch adds two fields, subj_pid and subj_comm, into the audit message: fn=smk_tskacc_msq action=granted subject="bar" object="foo" requested=rw subj_pid=564 subj_comm="mrcv" pid=577 comm="msnd" ipc_key=2 Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler

smack: fix incorrect task context in smack_msg_queue_msgrcv

2026-06-22T18:16:23+00:00

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) Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel") Signed-off-by: Konstantin Andreev Signed-off-by: Casey Schaufler

security: smack: fix spelling mistake

2026-06-22T17:23:37+00:00

Fix misspelling: overriden → overridden Signed-off-by: Qingshuang Fu Changes since v1: - Split original single patch into two standalone patches, separate AppArmor and Smack changes for different maintainer trees. Signed-off-by: Casey Schaufler

security,fs,nfs,net: update security_inode_listsecurity() interface

2026-05-01T15:29:33+00:00

Update the security_inode_listsecurity() interface to allow use of the xattr_list_one() helper and update the hook implementations. Link: https://lore.kernel.org/selinux/20250424152822.2719-1-stephen.smalley.work@gmail.com Signed-off-by: Stephen Smalley [PM: forward porting to bring this patch up to v7.1-rc1+] Signed-off-by: Paul Moore

smack: simplify write handlers of sysfs entries

2026-04-29T21:14:35+00:00

Use the convenient 'kstrto{u,s}32_from_user()' to simplify write handlers of /smack/{doi,direct,mapped,logging,ptrace} sysfs entries. Signed-off-by: Dmitry Antipov Signed-off-by: Casey Schaufler