[PATCH] smack: fix cred UAF in smack_file_send_sigiotask()

[PATCH] smack: fix cred UAF in smack_file_send_sigiotask()

[Jann Horn]

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 <jannh@google.com>
---
 security/smack/smack_lsm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index ff115068c5c0..bbe6cd6b03f7 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -1964,7 +1964,7 @@ static int smack_file_send_sigiotask(struct task_struct *tsk,
 {
 	struct smack_known **blob;
 	struct smack_known *skp;
-	struct smack_known *tkp = smk_of_task(smack_cred(tsk->cred));
+	struct smack_known *tkp = smk_of_task_struct_obj(tsk);
 	const struct cred *tcred;
 	struct file *file;
 	int rc;

---
base-commit: fcaeecb8b0cd44f77d03b28de0671258d4db18f8
change-id: 20260806-smack-uaf-fix-3fee58e5d92e

Best regards,
--  
Jann Horn <jannh@google.com>

Re: [PATCH] smack: fix cred UAF in smack_file_send_sigiotask()

[Jann Horn]

On Thu, Aug 6, 2026 at 9:41 PM Jann Horn <jannh@google.com> wrote:
> 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.

This is the testcase that I used to trigger a KASAN splat, with a
custom harness that allows me to test specific orderings of a race
condition:
```
#define _GNU_SOURCE
#include <errno.h>
#include <fcntl.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

static int pipefds[2];

/* runs in the same thread as test_thread1() */
void test_setup(void) {
  seteuid(1);
  signal(SIGIO, SIG_IGN);
  pipe(pipefds);
  fcntl(pipefds[0], F_SETFL, O_ASYNC);
  struct f_owner_ex owner = {
    .type = F_OWNER_TID,
    .pid = gettid()
  };
  fcntl(pipefds[0], F_SETOWN_EX, &owner);
}
void test_thread1(void) {
  access("/", R_OK);
}
void test_thread2(void) {
  write(pipefds[1], "A", 1);
}
void test_end(void) {}
```

Resulting in this splat:
==================================================================
BUG: KASAN: slab-use-after-free in smack_file_send_sigiotask+0x48/0x170
Read of size 8 at addr ffff8881001ad858 by task kcov-vsock-clie/60

CPU: 1 UID: 1 PID: 60 Comm: kcov-vsock-clie Not tainted
7.2.0-rc3-00019-ga4fe47ae7d00 #4 PREEMPT(full)
Call Trace:
 <TASK>
 __dump_stack+0x21/0x30
 dump_stack_lvl+0x95/0xd0
 print_address_description+0x77/0x1f0
 print_report+0x5b/0x70
[...]
 kasan_report+0x144/0x180
[...]
 __asan_load8+0xbb/0xc0
 smack_file_send_sigiotask+0x48/0x170
 security_file_send_sigiotask+0x85/0xc0
 send_sigio_to_task+0x141/0x350
[...]
 send_sigio+0x95/0x190
 kill_fasync+0xfe/0x180
 anon_pipe_write+0xe24/0xf50
[...]
 vfs_write+0x520/0x950
[...]
 ksys_write+0x11c/0x1f0
[...]
 __x64_sys_write+0x47/0x60
 x64_sys_call+0x2762/0x3030
 do_syscall_64+0xcd/0x310
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
[...]
 </TASK>

Allocated by task 59:
 kasan_save_track+0x3e/0x80
 kasan_save_alloc_info+0x3a/0x50
 __kasan_slab_alloc+0x52/0x70
 kmem_cache_alloc_noprof+0x161/0x290
 prepare_creds+0x3b/0x2d0
 do_faccessat+0x1cd/0x7d0
 __x64_sys_access+0x3b/0x50
 x64_sys_call+0x297e/0x3030
 do_syscall_64+0xcd/0x310
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Freed by task 59:
 kasan_save_track+0x3e/0x80
 kasan_save_free_info+0x44/0x50
 __kasan_slab_free+0x47/0x80
 kmem_cache_free+0x132/0x340
 put_cred_rcu+0x131/0x1b0
 __put_cred+0xb2/0x100
 do_faccessat+0x5cf/0x7d0
 __x64_sys_access+0x3b/0x50
 x64_sys_call+0x297e/0x3030
 do_syscall_64+0xcd/0x310
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

The buggy address belongs to the object at ffff8881001ad800
 which belongs to the cache cred of size 144
The buggy address is located 88 bytes inside of
 freed 144-byte region [ffff8881001ad800, ffff8881001ad890)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1001ad
flags: 0x8000000000000000(zone=2)
page_type: f5(slab)
raw: 8000000000000000 ffff8881001ce280 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000100010 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff8881001ad700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff8881001ad780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff8881001ad800: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                    ^
 ffff8881001ad880: fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff8881001ad900: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================