[PATCH] smack: fix cred UAF in smack_file_send_sigiotask()
Jann Horn
jannh at google.com
Thu Aug 6 19:46:14 UTC 2026
On Thu, Aug 6, 2026 at 9:41 PM Jann Horn <jannh at 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
==================================================================
More information about the Linux-security-module-archive
mailing list