| 0/0 |
2026/06/12 21:59 |
flow |
assessment-security |
49m
Results: map[DenialOfService:true Explanation:Based on the analysis of the bug report and the provided reproducer, here is the
assessment of the security impact:
**Bug Analysis:**
The bug report indicates a memory leak of a `struct file` object (size 176
bytes) allocated in `alloc_empty_file` during the `path_openat` syscall. The
reproducer triggers this by opening a Video4Linux device node (`/dev/vbi#`,
which is handled by the `vivid` test driver) and subsequently interacting with
`io_uring` and `sendmsg`.
Because the `struct file` reference count is incremented but not properly
decremented (or the file is removed from the fd table without calling `fput`),
the kernel fails to free the memory associated with the file object when the
process exits.
**Exploitability:**
Memory leaks of this nature (where an object is simply abandoned without being
freed) do not result in memory corruption, use-after-free, out-of-bounds
accesses, or control-flow hijacking. Therefore, this bug is **not exploitable**
for privilege escalation or arbitrary code execution.
**Denial of Service (DoS):**
An attacker can repeatedly trigger this bug to leak `struct file` objects. Over
time, this will consume a significant amount of kernel memory (slab memory) and
potentially exhaust the system-wide limit on open files (`fs.file-max`), leading
to a Denial of Service (OOM conditions or inability for other processes to open
files).
**Accessibility:**
The bug can be triggered by a standard, unprivileged local user process. The
reproducer uses basic syscalls (`open`, `mmap`, `io_uring_setup`, `sendmsg`)
that do not require `CAP_SYS_ADMIN` or any other special capabilities. It is
also accessible from within user namespaces.
**Other Triggers:**
This is a local syscall-based vulnerability. It cannot be triggered remotely via
network traffic (Ethernet or otherwise), nor is it related to parsing malicious
filesystems, peripheral devices, or virtualization boundaries (VM Guest/Host). Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:false RemoteTrigger:false Unprivileged:true UserNamespace:true VMGuestTrigger:false VMHostTrigger:false]
|
| 1/1 |
2026/06/12 21:59 |
action |
syz-repro-to-c-repro |
0m
Results: map[SimplifiedCRepro:// autogenerated by syzkaller (https://github.com/google/syzkaller)
#define _GNU_SOURCE
#include <endian.h>
#include <fcntl.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mount.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>
#ifndef __NR_io_uring_enter
#define __NR_io_uring_enter 426
#endif
#ifndef __NR_io_uring_setup
#define __NR_io_uring_setup 425
#endif
#define BITMASK(bf_off,bf_len) (((1ull << (bf_len)) - 1) << (bf_off))
#define STORE_BY_BITMASK(type,htobe,addr,val,bf_off,bf_len) *(type*)(addr) = htobe((htobe(*(type*)(addr)) & ~BITMASK((bf_off), (bf_len))) | (((type)(val) << (bf_off)) & BITMASK((bf_off), (bf_len))))
static long syz_open_dev(volatile long a0, volatile long a1, volatile long a2)
{
if (a0 == 0xc || a0 == 0xb) {
char buf[128];
sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block", (uint8_t)a1, (uint8_t)a2);
return open(buf, O_RDWR, 0);
} else {
unsigned long nb = a1;
char buf[1024];
char* hash;
strncpy(buf, (char*)a0, sizeof(buf) - 1);
buf[sizeof(buf) - 1] = 0;
while ((hash = strchr(buf, '#'))) {
*hash = '0' + (char)(nb % 10);
nb /= 10;
}
return open(buf, a2 & ~O_CREAT, 0);
}
}
uint64_t r[1] = {0xffffffffffffffff};
int main(void)
{
syscall(__NR_mmap, /*addr=*/0x1ffffffff000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
syscall(__NR_mmap, /*addr=*/0x200000000000ul, /*len=*/0x1000000ul, /*prot=PROT_WRITE|PROT_READ|PROT_EXEC*/7ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
syscall(__NR_mmap, /*addr=*/0x200001000000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
const char* reason;
(void)reason;
intptr_t res = 0;
if (write(1, "executing program\n", sizeof("executing program\n") - 1)) {}
// socket$nl_generic arguments: [
// domain: const = 0x10 (8 bytes)
// type: const = 0x3 (8 bytes)
// proto: const = 0x10 (4 bytes)
// ]
// returns sock_nl_generic
syscall(__NR_socket, /*domain=*/0x10ul, /*type=*/3ul, /*proto=*/0x10);
// socket arguments: [
// domain: socket_domain = 0x2 (8 bytes)
// type: socket_type = 0x3 (8 bytes)
// proto: int32 = 0x67 (4 bytes)
// ]
// returns sock
syscall(__NR_socket, /*domain=AF_INET*/2ul, /*type=SOCK_RAW*/3ul, /*proto=*/0x67);
// prctl$PR_SET_MM_MAP arguments: [
// option: const = 0x23 (8 bytes)
// opt: const = 0xe (8 bytes)
// arg: ptr[in, prctl_mm_map] {
// prctl_mm_map {
// start_code: VMA[0x1000]
// end_code: VMA[0xf000]
// start_data: VMA[0x2000]
// end_data: VMA[0x3000]
// start_brk: VMA[0x4000]
// brk: VMA[0x3000]
// start_stack: VMA[0x3000]
// arg_start: VMA[0x3000]
// arg_end: VMA[0x1000]
// env_start: VMA[0x3000]
// env_end: VMA[0x2000]
// auxv: nil
// auxv_size: bytesize = 0x0 (4 bytes)
// exe_fd: fd (resource)
// }
// }
// len: bytesize = 0x68 (8 bytes)
// ]
*(uint64_t*)0x200000000080 = 0x200000ff7000;
*(uint64_t*)0x200000000088 = 0x200000ff1000;
*(uint64_t*)0x200000000090 = 0x200000ff1000;
*(uint64_t*)0x200000000098 = 0x200000ff5000;
*(uint64_t*)0x2000000000a0 = 0x200000ff8000;
*(uint64_t*)0x2000000000a8 = 0x200000ff8000;
*(uint64_t*)0x2000000000b0 = 0x200000ffd000;
*(uint64_t*)0x2000000000b8 = 0x200000ffb000;
*(uint64_t*)0x2000000000c0 = 0x200000ff5000;
*(uint64_t*)0x2000000000c8 = 0x200000ff3000;
*(uint64_t*)0x2000000000d0 = 0x200000ffa000;
*(uint64_t*)0x2000000000d8 = 0;
*(uint32_t*)0x2000000000e0 = 0;
*(uint32_t*)0x2000000000e4 = -1;
syscall(__NR_prctl, /*option=*/0x23ul, /*opt=*/0xeul, /*arg=*/0x200000000080ul, /*len=*/0x68ul, 0);
// sendmsg$NFT_BATCH arguments: [
// fd: sock_nl_netfilter (resource)
// msg: ptr[in, msghdr_netlink[nft_batch_msg]] {
// msghdr_netlink[nft_batch_msg] {
// addr: nil
// addrlen: len = 0x0 (4 bytes)
// pad = 0x0 (4 bytes)
// vec: nil
// vlen: const = 0x1 (8 bytes)
// ctrl: const = 0x0 (8 bytes)
// ctrllen: const = 0x0 (8 bytes)
// f: send_flags = 0x0 (4 bytes)
// pad = 0x0 (4 bytes)
// }
// }
// f: send_flags = 0x24004045 (8 bytes)
// ]
*(uint64_t*)0x200000000080 = 0;
*(uint32_t*)0x200000000088 = 0;
*(uint64_t*)0x200000000090 = 0;
*(uint64_t*)0x200000000098 = 1;
*(uint64_t*)0x2000000000a0 = 0;
*(uint64_t*)0x2000000000a8 = 0;
*(uint32_t*)0x2000000000b0 = 0;
syscall(__NR_sendmsg, /*fd=*/(intptr_t)-1, /*msg=*/0x200000000080ul, /*f=MSG_ZEROCOPY|MSG_FASTOPEN|MSG_OOB|MSG_NOSIGNAL|MSG_DONTWAIT|MSG_DONTROUTE*/0x24004045ul);
// io_uring_setup arguments: [
// entries: int32 = 0x523 (4 bytes)
// params: ptr[inout, io_uring_params] {
// io_uring_params {
// sq_entries: int32 = 0x0 (4 bytes)
// cq_entries: int32 = 0x3cb1 (4 bytes)
// flags: io_uring_setup_flags = 0x1c080 (4 bytes)
// sq_thread_cpu: int32 = 0xa (4 bytes)
// sq_thread_idle: int32 = 0x20002f7 (4 bytes)
// features: int32 = 0x0 (4 bytes)
// wq_fd: fd_io_uring (resource)
// resv: buffer: {00 00 00 00 00 00 00 00 00 00 00 00} (length 0xc)
// sq_off: io_sqring_offsets {
// head: int32 = 0x0 (4 bytes)
// tail: int32 = 0x0 (4 bytes)
// ring_mask: int32 = 0x0 (4 bytes)
// ring_entries: int32 = 0x0 (4 bytes)
// flags: int32 = 0x0 (4 bytes)
// dropped: int32 = 0x0 (4 bytes)
// array: int32 = 0x0 (4 bytes)
// resv1: int32 = 0x0 (4 bytes)
// user_addr: int64 = 0x0 (8 bytes)
// }
// cq_off: io_cqring_offsets {
// head: int32 = 0x0 (4 bytes)
// tail: int32 = 0x0 (4 bytes)
// ring_mask: int32 = 0x0 (4 bytes)
// ring_entries: int32 = 0x0 (4 bytes)
// overflow: int32 = 0x0 (4 bytes)
// cqes: int32 = 0x0 (4 bytes)
// flags: int32 = 0x0 (4 bytes)
// resv1: int32 = 0x0 (4 bytes)
// user_addr: int64 = 0x0 (8 bytes)
// }
// }
// }
// ]
// returns fd_io_uring
*(uint32_t*)0x200000000044 = 0x3cb1;
*(uint32_t*)0x200000000048 = 0x1c080;
*(uint32_t*)0x20000000004c = 0xa;
*(uint32_t*)0x200000000050 = 0x20002f7;
*(uint32_t*)0x200000000058 = -1;
memset((void*)0x20000000005c, 0, 12);
res = syscall(__NR_io_uring_setup, /*entries=*/0x523, /*params=*/0x200000000040ul);
if (res != -1)
r[0] = res;
// syz_open_dev$vbi arguments: [
// dev: ptr[in, buffer] {
// buffer: {2f 64 65 76 2f 76 62 69 23 00} (length 0xa)
// }
// id: proc = 0x3 (8 bytes)
// flags: const = 0x2 (8 bytes)
// ]
// returns fd_video
memcpy((void*)0x200000000000, "/dev/vbi#\000", 10);
syz_open_dev(/*dev=*/0x200000000000, /*id=*/3, /*flags=*/2);
// sendmsg$nl_route_sched arguments: [
// fd: sock_nl_route (resource)
// msg: ptr[in, msghdr_netlink[netlink_msg_route_sched]] {
// msghdr_netlink[netlink_msg_route_sched] {
// addr: nil
// addrlen: len = 0x0 (4 bytes)
// pad = 0x0 (4 bytes)
// vec: ptr[in, iovec[in, netlink_msg_route_sched]] {
// iovec[in, netlink_msg_route_sched] {
// addr: ptr[in, netlink_msg_route_sched] {
// union netlink_msg_route_sched {
// newtfilter: netlink_msg_t[const[RTM_NEWTFILTER, int16], tcmsg[AF_UNSPEC], filter_policy] {
// len: len = 0x1230 (4 bytes)
// type: const = 0x2c (2 bytes)
// flags: netlink_msg_flags = 0x4 (2 bytes)
// seq: int32 = 0x70bd2d (4 bytes)
// pid: int32 = 0x25dfdbfd (4 bytes)
// payload: tcmsg[AF_UNSPEC] {
// family: const = 0x0 (1 bytes)
// tcm__pad1: const = 0x0 (1 bytes)
// tcm__pad2: const = 0x0 (2 bytes)
// ifindex: ifindex (resource)
// tcm_handle: tcm_handle {
// minor: tcm_handle_offsets = 0x4 (2 bytes)
// major: tcm_handle_offsets = 0xe (2 bytes)
// }
// tcm_parent: tcm_handle {
// minor: tcm_handle_offsets = 0xffe4 (2 bytes)
// major: tcm_handle_offsets = 0xffe0 (2 bytes)
// }
// tcm_info: tcm_handle {
// minor: tcm_handle_offsets = 0xe (2 bytes)
// major: tcm_handle_offsets = 0x5 (2 bytes)
// }
// }
// attrs: array[filter_policy] {
// union filter_policy {
// TCA_RATE: nlattr_t[const[TCA_RATE, int16], tc_estimator] {
// nla_len: offsetof = 0x6 (2 bytes)
// nla_type: const = 0x5 (2 bytes)
// payload: tc_estimator {
// interval: int8 = 0x8f (1 bytes)
// ewma_log: int8 = 0x0 (1 bytes)
// }
// size: buffer: {} (length 0x0)
// pad = 0x0 (2 bytes)
// }
// }
// union filter_policy {
// filter_kind_options: union filter_kind_options {
// f_basic: tca_kind_options_t["basic", array[basic_policy]] {
// TCA_KIND: nlattr_t[const[TCA_KIND, int16], string["basic"]] {
// nla_len: offsetof = 0xa (2 bytes)
// nla_type: const = 0x1 (2 bytes)
// payload: buffer: {62 61 73 69 63 00} (length 0x6)
// size: buffer: {} (length 0x0)
// pad = 0x0 (2 bytes)
// }
// TCA_OPTIONS: nlattr_t[const[TCA_OPTIONS, int16], array[basic_policy]] {
// nla_len: offsetof = 0x11f8 (2 bytes)
// nla_type: const = 0x2 (2 bytes)
// payload: array[basic_policy] {
// union basic_policy {
// TCA_BASIC_ACT: nlattr_t[const[TCA_BASIC_ACT, int16], array[tca_actions]] {
// nla_len: offsetof = 0x128 (2 bytes)
// nla_type: const = 0x3 (2 bytes)
// payload: array[tca_actions] {
// union tca_actions {
// m_pedit: nlattr_tt[int16:14[0:TCA_ACT_MAX_PRIO], 0, 0, tcf_action_policy["pedit", pedit_policy]] {
// nla_len: offsetof = 0x124 (2 bytes)
// nla_type: int16 = 0xa (1 bytes)
// NLA_F_NET_BYTEORDER: const = 0x0 (0 bytes)
// NLA_F_NESTED: const = 0x0 (1 bytes)
// payload: tcf_action_policy["pedit", pedit_policy] {
// TCA_ACT_KIND: nlattr_t[const[TCA_ACT_KIND, int16], string["pedit"]] {
// nla_len: offsetof = 0xa (2 bytes)
// nla_type: const = 0x1 (2 bytes)
// payload: buffer: {70 65 64 69 74 00} (length 0x6)
// size: buffer: {} (length 0x0)
// pad = 0x0 (2 bytes)
// }
// TCA_ACT_OPTIONS: nlattr_tt[const[TCA_ACT_OPTIONS, int16:14], 0, 1, array[pedit_policy]] {
// nla_len: offsetof = 0x4 (2 bytes)
// nla_type: const = 0x2 (1 bytes)
// NLA_F_NET_BYTEORDER: const = 0x0 (0 bytes)
// NLA_F_NESTED: const = 0x1 (1 bytes)
// payload: array[pedit_policy] {
// }
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_COOKIE: nlattr_t[const[TCA_ACT_COOKIE, int16], array[int8]] {
// nla_len: offsetof = 0xf5 (2 bytes)
// nla_type: const = 0x6 (2 bytes)
// payload: buffer: {c4 1d 0b 25 b0 62 85 aa 07 97 b1 9a 7c 9f 5d f9 d2 80 a5 44 e3 41 cd 7f a8 57 a7 da 8b 8a c0 b1 b1 66 91 93 66 3e 1c e0 3b fe 2e 5c ae fa 26 e8 20 95 04 0c ab 3d 89 24 06 19 70 87 cb 53 98 4c ec ab 77 79 7a f8 08 4a 9c 30 54 5d 5d fd f8 48 b1 43 61 85 be 3c fa 66 13 ce 55 8d 16 3f 4b f7 27 7d d1 00 ba df 44 8b 3f 59 ee 61 f1 fe 34 2a 2c da 8c 22 e0 7d c7 39 ce 51 19 e0 d7 12 fe c2 98 b5 eb 1f 7b a6 6a 68 d8 35 42 26 56 b0 ff c9 a1 9d eb 53 33 d8 4a 7d d0 5e 0a c4 d5 ed 45 8b a6 15 90 f7 cd 2e a7 65 b2 6e ae 8d 45 80 58 96 b4 d0 3e d9 5d a8 04 fc 92 d1 b4 5e 41 f7 49 20 ea 4d 50 aa c5 ed 89 8d 4e 1c 43 a0 dc 80 db 3c 0a ab 1e 59 06 47 3c 15 ba 6e b6 57 6b fb 1a 0e da 96 1d 15 0c ef e1 2b 70 7e bf ec 98 a5 86 f4 db} (length 0xf1)
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_FLAGS: nlattr_t[const[TCA_ACT_FLAGS, int16], nla_bitfield32[tcf_action_policy_flags]] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x7 (2 bytes)
// payload: nla_bitfield32[tcf_action_policy_flags] {
// value: tcf_action_policy_flags = 0x0 (4 bytes)
// selector: tcf_action_policy_flags = 0x0 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_HW_STATS: nlattr_t[const[TCA_ACT_HW_STATS, int16], nla_bitfield32[tcf_action_policy_hw_stats]] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x8 (2 bytes)
// payload: nla_bitfield32[tcf_action_policy_hw_stats] {
// value: tcf_action_policy_hw_stats = 0x2 (4 bytes)
// selector: tcf_action_policy_hw_stats = 0x3 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// size: buffer: {} (length 0x0)
// }
// }
// }
// size: buffer: {} (length 0x0)
// }
// }
// union basic_policy {
// TCA_BASIC_CLASSID: nlattr_t[const[TCA_BASIC_CLASSID, int16], tcm_handle] {
// nla_len: offsetof = 0x8 (2 bytes)
// nla_type: const = 0x1 (2 bytes)
// payload: tcm_handle {
// minor: tcm_handle_offsets = 0xe (2 bytes)
// major: tcm_handle_offsets = 0xe (2 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// union basic_policy {
// TCA_BASIC_CLASSID: nlattr_t[const[TCA_BASIC_CLASSID, int16], tcm_handle] {
// nla_len: offsetof = 0x8 (2 bytes)
// nla_type: const = 0x1 (2 bytes)
// payload: tcm_handle {
// minor: tcm_handle_offsets = 0x10 (2 bytes)
// major: tcm_handle_offsets = 0x6 (2 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// union basic_policy {
// TCA_BASIC_CLASSID: nlattr_t[const[TCA_BASIC_CLASSID, int16], tcm_handle] {
// nla_len: offsetof = 0x8 (2 bytes)
// nla_type: const = 0x1 (2 bytes)
// payload: tcm_handle {
// minor: tcm_handle_offsets = 0x8 (2 bytes)
// major: tcm_handle_offsets = 0xfff2 (2 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// union basic_policy {
// TCA_BASIC_ACT: nlattr_t[const[TCA_BASIC_ACT, int16], array[tca_actions]] {
// nla_len: offsetof = 0x10b4 (2 bytes)
// nla_type: const = 0x3 (2 bytes)
// payload: array[tca_actions] {
// union tca_actions {
// m_police: nlattr_tt[int16:14[0:TCA_ACT_MAX_PRIO], 0, 0, tcf_action_policy["police", array[police_policy]]] {
// nla_len: offsetof = 0x1054 (2 bytes)
// nla_type: int16 = 0x16 (1 bytes)
// NLA_F_NET_BYTEORDER: const = 0x0 (0 bytes)
// NLA_F_NESTED: const = 0x0 (1 bytes)
// payload: tcf_action_policy["police", array[police_policy]] {
// TCA_ACT_KIND: nlattr_t[const[TCA_ACT_KIND, int16], string["police"]] {
// nla_len: offsetof = 0xb (2 bytes)
// nla_type: const = 0x1 (2 bytes)
// payload: buffer: {70 6f 6c 69 63 65 00} (length 0x7)
// size: buffer: {} (length 0x0)
// pad = 0x0 (1 bytes)
// }
// TCA_ACT_OPTIONS: nlattr_tt[const[TCA_ACT_OPTIONS, int16:14], 0, 1, array[array[police_policy]]] {
// nla_len: offsetof = 0x1028 (2 bytes)
// nla_type: const = 0x2 (1 bytes)
// NLA_F_NET_BYTEORDER: const = 0x0 (0 bytes)
// NLA_F_NESTED: const = 0x1 (1 bytes)
// payload: array[array[police_policy]] {
// array[police_policy] {
// union police_policy {
// TCA_POLICE_PEAKRATE: nlattr_t[const[TCA_POLICE_PEAKRATE, int16], array[int32, 256]] {
// nla_len: offsetof = 0x404 (2 bytes)
// nla_type: const = 0x3 (2 bytes)
// payload: array[int32] {
// int32 = 0x81 (4 bytes)
// int32 = 0x1ff (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x80000001 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xfffffffa (4 bytes)
// int32 = 0x5f7 (4 bytes)
// int32 = 0xbebc (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x798a (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xe08c (4 bytes)
// int32 = 0x3964 (4 bytes)
// int32 = 0xf3 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x102 (4 bytes)
// int32 = 0xbff (4 bytes)
// int32 = 0x838 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x80000000 (4 bytes)
// int32 = 0x7fffffff (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xad6c (4 bytes)
// int32 = 0xa6f4 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x9f9 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x7fff (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xaf75 (4 bytes)
// int32 = 0xfffff179 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x89 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x10001 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x87 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x7ca (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x10001 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xdfbd (4 bytes)
// int32 = 0x6d1b (4 bytes)
// int32 = 0xf4dc (4 bytes)
// int32 = 0xf8000000 (4 bytes)
// int32 = 0xbfb (4 bytes)
// int32 = 0x200 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xfffffff7 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x80 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4d (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x7ff (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0x401 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x1000 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x80 (4 bytes)
// int32 = 0x1ff (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xc1 (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x38 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0xffffff80 (4 bytes)
// int32 = 0x9df (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x1ff (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x200 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x2ee9 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x80 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x80 (4 bytes)
// int32 = 0x2ecc8490 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xa7 (4 bytes)
// int32 = 0x24d (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x18 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xd85 (4 bytes)
// int32 = 0xd4 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xc64a (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xabd (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xdd7 (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x80 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xe (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xc (4 bytes)
// int32 = 0xa4 (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0x24 (4 bytes)
// int32 = 0xa9a (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x2ba (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x854 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xe7 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x80000000 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x86 (4 bytes)
// int32 = 0x81 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x800 (4 bytes)
// int32 = 0xfffffffd (4 bytes)
// int32 = 0x9c1 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0xfffffffc (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xc (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xd (4 bytes)
// int32 = 0xb (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// union police_policy {
// TCA_POLICE_RATE64: nlattr_t[const[TCA_POLICE_RATE64, int16], int64] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x8 (2 bytes)
// payload: int64 = 0x5 (8 bytes)
// size: buffer: {} (length 0x0)
// }
// }
// union police_policy {
// TCA_POLICE_PEAKRATE: nlattr_t[const[TCA_POLICE_PEAKRATE, int16], array[int32, 256]] {
// nla_len: offsetof = 0x404 (2 bytes)
// nla_type: const = 0x3 (2 bytes)
// payload: array[int32] {
// int32 = 0x3 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xc6c (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x7ff (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x1000000 (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0x9f4f5d67 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x7ff (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x32 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x30000000 (4 bytes)
// int32 = 0xdd (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x400 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x101 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xd (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x39c0 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x94b (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x777 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x800 (4 bytes)
// int32 = 0x1000 (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0x9e (4 bytes)
// int32 = 0xcc (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xffffff37 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x7ff (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xfffffffc (4 bytes)
// int32 = 0x101 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xf3 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x7a36 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x40 (4 bytes)
// int32 = 0xd10 (4 bytes)
// int32 = 0x455e (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x40000 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x18bc169 (4 bytes)
// int32 = 0x10 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xb66 (4 bytes)
// int32 = 0x100 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x3d (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x81 (4 bytes)
// int32 = 0x81 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xc (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x7fffffff (4 bytes)
// int32 = 0x52acd031 (4 bytes)
// int32 = 0xf938 (4 bytes)
// int32 = 0xc8 (4 bytes)
// int32 = 0x1b (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x80000001 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x41 (4 bytes)
// int32 = 0x401 (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x100007 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0xd17 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x400 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x80000000 (4 bytes)
// int32 = 0x400 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0xfffffffd (4 bytes)
// int32 = 0xc6 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x25 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x400 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x81 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x200000a (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0xd (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x83 (4 bytes)
// int32 = 0x1ff (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0x87 (4 bytes)
// int32 = 0x800 (4 bytes)
// int32 = 0xdba (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xe1d (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xfffffffa (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x9ca (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xc (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xfffffb9b (4 bytes)
// int32 = 0xd (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x800 (4 bytes)
// int32 = 0xfffffff7 (4 bytes)
// int32 = 0x7ff (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x80000001 (4 bytes)
// int32 = 0xc9 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xe47 (4 bytes)
// int32 = 0x1ff (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x49 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xfffffa1f (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x18000 (4 bytes)
// int32 = 0x4d0 (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x5cd (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// union police_policy {
// TCA_POLICE_AVRATE: nlattr_t[const[TCA_POLICE_AVRATE, int16], int32] {
// nla_len: offsetof = 0x8 (2 bytes)
// nla_type: const = 0x4 (2 bytes)
// payload: int32 = 0x80 (4 bytes)
// size: buffer: {} (length 0x0)
// }
// }
// }
// array[police_policy] {
// union police_policy {
// TCA_POLICE_RATE: nlattr_t[const[TCA_POLICE_RATE, int16], array[int32, 256]] {
// nla_len: offsetof = 0x404 (2 bytes)
// nla_type: const = 0x2 (2 bytes)
// payload: array[int32] {
// int32 = 0x6 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x80000000 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x200 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x7fffffff (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x101 (4 bytes)
// int32 = 0xffffff51 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x401 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xd5c6 (4 bytes)
// int32 = 0x400 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x9c3 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xfffffffa (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xd9 (4 bytes)
// int32 = 0xef (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0xffff (4 bytes)
// int32 = 0xfffffffb (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0xfffffffd (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xffff (4 bytes)
// int32 = 0x800 (4 bytes)
// int32 = 0xfffffff8 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x67 (4 bytes)
// int32 = 0xfd0 (4 bytes)
// int32 = 0xffffffbe (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x101 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xffff (4 bytes)
// int32 = 0xfffffff7 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xa2 (4 bytes)
// int32 = 0x1336df01 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x81 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x40 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x80000001 (4 bytes)
// int32 = 0xc0d7 (4 bytes)
// int32 = 0xf9 (4 bytes)
// int32 = 0x59 (4 bytes)
// int32 = 0x1000 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x400 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0xff6d (4 bytes)
// int32 = 0x1ff (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0x90000 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x8cca (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xaa (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x40 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xfffffff5 (4 bytes)
// int32 = 0x95c (4 bytes)
// int32 = 0xf6 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x7fffffff (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x1000 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xffff7fff (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x71 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xb4 (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x7791070f (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4eb8 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xe2 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xffffff01 (4 bytes)
// int32 = 0xfffffffe (4 bytes)
// int32 = 0xc (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x40 (4 bytes)
// int32 = 0x400 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x38 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xb25 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x73c0 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x9000000 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x57b (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0x3fb2 (4 bytes)
// int32 = 0xce (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0xb315 (4 bytes)
// int32 = 0xfffffff2 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0xfffffff8 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0xfffffffd (4 bytes)
// int32 = 0x100 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x101 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x100 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xffff8000 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x1000 (4 bytes)
// int32 = 0x7282 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x8c (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xe (4 bytes)
// int32 = 0x81 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x1c (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x81 (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0xbc (4 bytes)
// int32 = 0x1ff (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x1000 (4 bytes)
// int32 = 0x9 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// union police_policy {
// TCA_POLICE_PEAKRATE: nlattr_t[const[TCA_POLICE_PEAKRATE, int16], array[int32, 256]] {
// nla_len: offsetof = 0x404 (2 bytes)
// nla_type: const = 0x3 (2 bytes)
// payload: array[int32] {
// int32 = 0x8cf (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x59c (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xfffffffc (4 bytes)
// int32 = 0x5f2c (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x100 (4 bytes)
// int32 = 0x35b (4 bytes)
// int32 = 0xbe (4 bytes)
// int32 = 0x7d (4 bytes)
// int32 = 0xab99 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x101 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xf76 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0xd (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xab45 (4 bytes)
// int32 = 0x8244 (4 bytes)
// int32 = 0x60000 (4 bytes)
// int32 = 0xe2a (4 bytes)
// int32 = 0xae8 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x20076355 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x10 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0xd (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x7ff (4 bytes)
// int32 = 0x200 (4 bytes)
// int32 = 0xcb (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x80 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x45e (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x1f (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x80000001 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x800 (4 bytes)
// int32 = 0xfffffffc (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x81 (4 bytes)
// int32 = 0x6e3833b8 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x5520 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xe1 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xffffff8e (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x200 (4 bytes)
// int32 = 0x57 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xb91 (4 bytes)
// int32 = 0xfffffffa (4 bytes)
// int32 = 0xf6 (4 bytes)
// int32 = 0x10 (4 bytes)
// int32 = 0xd (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xffffff44 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x19d (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x1e0 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x10001 (4 bytes)
// int32 = 0xf1 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xd0 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0xffff (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x4b (4 bytes)
// int32 = 0x6168 (4 bytes)
// int32 = 0xd (4 bytes)
// int32 = 0x1ff (4 bytes)
// int32 = 0x80000000 (4 bytes)
// int32 = 0x10001 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0xc (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xd75 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0xb1 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xa7b (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xfffffff7 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xfffffffd (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0xe (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xc1b (4 bytes)
// int32 = 0x401 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x5a (4 bytes)
// int32 = 0xffff (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x152f (4 bytes)
// int32 = 0xfffffff4 (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x1cf (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4a87 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xfffffff8 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x3b452a9 (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0x1400000 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x100 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x40 (4 bytes)
// int32 = 0x10 (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xfffffffb (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xa87 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xab2b (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x6ec6 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xc9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x723bdbde (4 bytes)
// int32 = 0x757f157a (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x200 (4 bytes)
// int32 = 0x40 (4 bytes)
// int32 = 0x69 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x84 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x1000 (4 bytes)
// int32 = 0x6f (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x5a4 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x80000000 (4 bytes)
// int32 = 0x7fff (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0xe528 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x0 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// }
// }
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_COOKIE: nlattr_t[const[TCA_ACT_COOKIE, int16], array[int8]] {
// nla_len: offsetof = 0x4 (2 bytes)
// nla_type: const = 0x6 (2 bytes)
// payload: buffer: {} (length 0x0)
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_FLAGS: nlattr_t[const[TCA_ACT_FLAGS, int16], nla_bitfield32[tcf_action_policy_flags]] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x7 (2 bytes)
// payload: nla_bitfield32[tcf_action_policy_flags] {
// value: tcf_action_policy_flags = 0x1 (4 bytes)
// selector: tcf_action_policy_flags = 0x0 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_HW_STATS: nlattr_t[const[TCA_ACT_HW_STATS, int16], nla_bitfield32[tcf_action_policy_hw_stats]] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x8 (2 bytes)
// payload: nla_bitfield32[tcf_action_policy_hw_stats] {
// value: tcf_action_policy_hw_stats = 0x0 (4 bytes)
// selector: tcf_action_policy_hw_stats = 0x2 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// size: buffer: {} (length 0x0)
// }
// }
// union tca_actions {
// m_ct: nlattr_tt[int16:14[0:TCA_ACT_MAX_PRIO], 0, 0, tcf_action_policy["ct", ct_policy]] {
// nla_len: offsetof = 0x2c (2 bytes)
// nla_type: int16 = 0x1 (1 bytes)
// NLA_F_NET_BYTEORDER: const = 0x0 (0 bytes)
// NLA_F_NESTED: const = 0x0 (1 bytes)
// payload: tcf_action_policy["ct", ct_policy] {
// TCA_ACT_KIND: nlattr_t[const[TCA_ACT_KIND, int16], string["ct"]] {
// nla_len: offsetof = 0x7 (2 bytes)
// nla_type: const = 0x1 (2 bytes)
// payload: buffer: {63 74 00} (length 0x3)
// size: buffer: {} (length 0x0)
// pad = 0x0 (1 bytes)
// }
// TCA_ACT_OPTIONS: nlattr_tt[const[TCA_ACT_OPTIONS, int16:14], 0, 1, array[ct_policy]] {
// nla_len: offsetof = 0x4 (2 bytes)
// nla_type: const = 0x2 (1 bytes)
// NLA_F_NET_BYTEORDER: const = 0x0 (0 bytes)
// NLA_F_NESTED: const = 0x1 (1 bytes)
// payload: array[ct_policy] {
// }
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_COOKIE: nlattr_t[const[TCA_ACT_COOKIE, int16], array[int8]] {
// nla_len: offsetof = 0x4 (2 bytes)
// nla_type: const = 0x6 (2 bytes)
// payload: buffer: {} (length 0x0)
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_FLAGS: nlattr_t[const[TCA_ACT_FLAGS, int16], nla_bitfield32[tcf_action_policy_flags]] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x7 (2 bytes)
// payload: nla_bitfield32[tcf_action_policy_flags] {
// value: tcf_action_policy_flags = 0x1 (4 bytes)
// selector: tcf_action_policy_flags = 0x0 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_HW_STATS: nlattr_t[const[TCA_ACT_HW_STATS, int16], nla_bitfield32[tcf_action_policy_hw_stats]] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x8 (2 bytes)
// payload: nla_bitfield32[tcf_action_policy_hw_stats] {
// value: tcf_action_policy_hw_stats = 0x2 (4 bytes)
// selector: tcf_action_policy_hw_stats = 0x1 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// size: buffer: {} (length 0x0)
// }
// }
// union tca_actions {
// m_gact: nlattr_tt[int16:14[0:TCA_ACT_MAX_PRIO], 0, 0, tcf_action_policy["gact", gact_policy]] {
// nla_len: offsetof = 0x30 (2 bytes)
// nla_type: int16 = 0x1 (1 bytes)
// NLA_F_NET_BYTEORDER: const = 0x0 (0 bytes)
// NLA_F_NESTED: const = 0x0 (1 bytes)
// payload: tcf_action_policy["gact", gact_policy] {
// TCA_ACT_KIND: nlattr_t[const[TCA_ACT_KIND, int16], string["gact"]] {
// nla_len: offsetof = 0x9 (2 bytes)
// nla_type: const = 0x1 (2 bytes)
// payload: buffer: {67 61 63 74 00} (length 0x5)
// size: buffer: {} (length 0x0)
// pad = 0x0 (3 bytes)
// }
// TCA_ACT_OPTIONS: nlattr_tt[const[TCA_ACT_OPTIONS, int16:14], 0, 1, array[gact_policy]] {
// nla_len: offsetof = 0x4 (2 bytes)
// nla_type: const = 0x2 (1 bytes)
// NLA_F_NET_BYTEORDER: const = 0x0 (0 bytes)
// NLA_F_NESTED: const = 0x1 (1 bytes)
// payload: array[gact_policy] {
// }
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_COOKIE: nlattr_t[const[TCA_ACT_COOKIE, int16], array[int8]] {
// nla_len: offsetof = 0x4 (2 bytes)
// nla_type: const = 0x6 (2 bytes)
// payload: buffer: {} (length 0x0)
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_FLAGS: nlattr_t[const[TCA_ACT_FLAGS, int16], nla_bitfield32[tcf_action_policy_flags]] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x7 (2 bytes)
// payload: nla_bitfield32[tcf_action_policy_flags] {
// value: tcf_action_policy_flags = 0x1 (4 bytes)
// selector: tcf_action_policy_flags = 0x0 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_HW_STATS: nlattr_t[const[TCA_ACT_HW_STATS, int16], nla_bitfield32[tcf_action_policy_hw_stats]] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x8 (2 bytes)
// payload: nla_bitfield32[tcf_action_policy_hw_stats] {
// value: tcf_action_policy_hw_stats = 0x1 (4 bytes)
// selector: tcf_action_policy_hw_stats = 0x0 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// size: buffer: {} (length 0x0)
// }
// }
// }
// size: buffer: {} (length 0x0)
// }
// }
// }
// size: buffer: {} (length 0x0)
// }
// }
// }
// }
// }
// }
// }
// }
// len: len = 0x1230 (8 bytes)
// }
// }
// vlen: const = 0x1 (8 bytes)
// ctrl: const = 0x0 (8 bytes)
// ctrllen: const = 0x0 (8 bytes)
// f: send_flags = 0x1 (4 bytes)
// pad = 0x0 (4 bytes)
// }
// }
// f: send_flags = 0x4041080 (8 bytes)
// ]
*(uint64_t*)0x200000006040 = 0;
*(uint32_t*)0x200000006048 = 0;
*(uint64_t*)0x200000006050 = 0x200000000140;
*(uint64_t*)0x200000000140 = 0x200000006080;
*(uint32_t*)0x200000006080 = 0x1230;
*(uint16_t*)0x200000006084 = 0x2c;
*(uint16_t*)0x200000006086 = 4;
*(uint32_t*)0x200000006088 = 0x70bd2d;
*(uint32_t*)0x20000000608c = 0x25dfdbfd;
*(uint8_t*)0x200000006090 = 0;
*(uint8_t*)0x200000006091 = 0;
*(uint16_t*)0x200000006092 = 0;
*(uint32_t*)0x200000006094 = 0;
*(uint16_t*)0x200000006098 = 4;
*(uint16_t*)0x20000000609a = 0xe;
*(uint16_t*)0x20000000609c = 0xffe4;
*(uint16_t*)0x20000000609e = 0xffe0;
*(uint16_t*)0x2000000060a0 = 0xe;
*(uint16_t*)0x2000000060a2 = 5;
*(uint16_t*)0x2000000060a4 = 6;
*(uint16_t*)0x2000000060a6 = 5;
*(uint8_t*)0x2000000060a8 = 0x8f;
*(uint8_t*)0x2000000060a9 = 0;
*(uint16_t*)0x2000000060ac = 0xa;
*(uint16_t*)0x2000000060ae = 1;
memcpy((void*)0x2000000060b0, "basic\000", 6);
*(uint16_t*)0x2000000060b8 = 0x11f8;
*(uint16_t*)0x2000000060ba = 2;
*(uint16_t*)0x2000000060bc = 0x128;
*(uint16_t*)0x2000000060be = 3;
*(uint16_t*)0x2000000060c0 = 0x124;
STORE_BY_BITMASK(uint16_t, , 0x2000000060c2, 0xa, 0, 14);
STORE_BY_BITMASK(uint16_t, , 0x2000000060c3, 0, 6, 1);
STORE_BY_BITMASK(uint16_t, , 0x2000000060c3, 0, 7, 1);
*(uint16_t*)0x2000000060c4 = 0xa;
*(uint16_t*)0x2000000060c6 = 1;
memcpy((void*)0x2000000060c8, "pedit\000", 6);
*(uint16_t*)0x2000000060d0 = 4;
STORE_BY_BITMASK(uint16_t, , 0x2000000060d2, 2, 0, 14);
STORE_BY_BITMASK(uint16_t, , 0x2000000060d3, 0, 6, 1);
STORE_BY_BITMASK(uint16_t, , 0x2000000060d3, 1, 7, 1);
*(uint16_t*)0x2000000060d4 = 0xf5;
*(uint16_t*)0x2000000060d6 = 6;
memcpy((void*)0x2000000060d8, "... [truncated large byte array] ...", 241);
*(uint16_t*)0x2000000061cc = 0xc;
*(uint16_t*)0x2000000061ce = 7;
*(uint32_t*)0x2000000061d0 = 0;
*(uint32_t*)0x2000000061d4 = 0;
*(uint16_t*)0x2000000061d8 = 0xc;
*(uint16_t*)0x2000000061da = 8;
*(uint32_t*)0x2000000061dc = 2;
*(uint32_t*)0x2000000061e0 = 3;
*(uint16_t*)0x2000000061e4 = 8;
*(uint16_t*)0x2000000061e6 = 1;
*(uint16_t*)0x2000000061e8 = 0xe;
*(uint16_t*)0x2000000061ea = 0xe;
*(uint16_t*)0x2000000061ec = 8;
*(uint16_t*)0x2000000061ee = 1;
*(uint16_t*)0x2000000061f0 = 0x10;
*(uint16_t*)0x2000000061f2 = 6;
*(uint16_t*)0x2000000061f4 = 8;
*(uint16_t*)0x2000000061f6 = 1;
*(uint16_t*)0x2000000061f8 = 8;
*(uint16_t*)0x2000000061fa = 0xfff2;
*(uint16_t*)0x2000000061fc = 0x10b4;
*(uint16_t*)0x2000000061fe = 3;
*(uint16_t*)0x200000006200 = 0x1054;
STORE_BY_BITMASK(uint16_t, , 0x200000006202, 0x16, 0, 14);
STORE_BY_BITMASK(uint16_t, , 0x200000006203, 0, 6, 1);
STORE_BY_BITMASK(uint16_t, , 0x200000006203, 0, 7, 1);
*(uint16_t*)0x200000006204 = 0xb;
*(uint16_t*)0x200000006206 = 1;
memcpy((void*)0x200000006208, "police\000", 7);
*(uint16_t*)0x200000006210 = 0x1028;
STORE_BY_BITMASK(uint16_t, , 0x200000006212, 2, 0, 14);
STORE_BY_BITMASK(uint16_t, , 0x200000006213, 0, 6, 1);
STORE_BY_BITMASK(uint16_t, , 0x200000006213, 1, 7, 1);
*(uint16_t*)0x200000006214 = 0x404;
*(uint16_t*)0x200000006216 = 3;
*(uint32_t*)0x200000006218 = 0x81;
*(uint32_t*)0x20000000621c = 0x1ff;
*(uint32_t*)0x200000006220 = 0x10000;
*(uint32_t*)0x200000006224 = 5;
*(uint32_t*)0x200000006228 = 0x80000001;
*(uint32_t*)0x20000000622c = 5;
*(uint32_t*)0x200000006230 = 0xfffffffa;
*(uint32_t*)0x200000006234 = 0x5f7;
*(uint32_t*)0x200000006238 = 0xbebc;
*(uint32_t*)0x20000000623c = 2;
*(uint32_t*)0x200000006240 = 7;
*(uint32_t*)0x200000006244 = 7;
*(uint32_t*)0x200000006248 = 7;
*(uint32_t*)0x20000000624c = 0x798a;
*(uint32_t*)0x200000006250 = 0xff;
*(uint32_t*)0x200000006254 = 5;
*(uint32_t*)0x200000006258 = 0xa;
*(uint32_t*)0x20000000625c = 7;
*(uint32_t*)0x200000006260 = 3;
*(uint32_t*)0x200000006264 = 7;
*(uint32_t*)0x200000006268 = 0xff;
*(uint32_t*)0x20000000626c = 2;
*(uint32_t*)0x200000006270 = 2;
*(uint32_t*)0x200000006274 = 7;
*(uint32_t*)0x200000006278 = 5;
*(uint32_t*)0x20000000627c = 6;
*(uint32_t*)0x200000006280 = 2;
*(uint32_t*)0x200000006284 = 8;
*(uint32_t*)0x200000006288 = 5;
*(uint32_t*)0x20000000628c = 0xe08c;
*(uint32_t*)0x200000006290 = 0x3964;
*(uint32_t*)0x200000006294 = 0xf3;
*(uint32_t*)0x200000006298 = 7;
*(uint32_t*)0x20000000629c = 6;
*(uint32_t*)0x2000000062a0 = 7;
*(uint32_t*)0x2000000062a4 = 5;
*(uint32_t*)0x2000000062a8 = 6;
*(uint32_t*)0x2000000062ac = 0xb;
*(uint32_t*)0x2000000062b0 = 0;
*(uint32_t*)0x2000000062b4 = 0;
*(uint32_t*)0x2000000062b8 = 0x102;
*(uint32_t*)0x2000000062bc = 0xbff;
*(uint32_t*)0x2000000062c0 = 0x838;
*(uint32_t*)0x2000000062c4 = 2;
*(uint32_t*)0x2000000062c8 = 0;
*(uint32_t*)0x2000000062cc = 9;
*(uint32_t*)0x2000000062d0 = 3;
*(uint32_t*)0x2000000062d4 = 0x80000000;
*(uint32_t*)0x2000000062d8 = 0x7fffffff;
*(uint32_t*)0x2000000062dc = 0;
*(uint32_t*)0x2000000062e0 = 2;
*(uint32_t*)0x2000000062e4 = 4;
*(uint32_t*)0x2000000062e8 = 0xad6c;
*(uint32_t*)0x2000000062ec = 0xa6f4;
*(uint32_t*)0x2000000062f0 = 6;
*(uint32_t*)0x2000000062f4 = 0x9f9;
*(uint32_t*)0x2000000062f8 = 7;
*(uint32_t*)0x2000000062fc = 4;
*(uint32_t*)0x200000006300 = 3;
*(uint32_t*)0x200000006304 = 6;
*(uint32_t*)0x200000006308 = 0x7fff;
*(uint32_t*)0x20000000630c = 5;
*(uint32_t*)0x200000006310 = 0x8000;
*(uint32_t*)0x200000006314 = 9;
*(uint32_t*)0x200000006318 = 0;
*(uint32_t*)0x20000000631c = 2;
*(uint32_t*)0x200000006320 = 8;
*(uint32_t*)0x200000006324 = 0x7f;
*(uint32_t*)0x200000006328 = 3;
*(uint32_t*)0x20000000632c = 1;
*(uint32_t*)0x200000006330 = 6;
*(uint32_t*)0x200000006334 = 0xaf75;
*(uint32_t*)0x200000006338 = 0xfffff179;
*(uint32_t*)0x20000000633c = 8;
*(uint32_t*)0x200000006340 = 0;
*(uint32_t*)0x200000006344 = 0x89;
*(uint32_t*)0x200000006348 = 7;
*(uint32_t*)0x20000000634c = 0x8001;
*(uint32_t*)0x200000006350 = 0x10001;
*(uint32_t*)0x200000006354 = 8;
*(uint32_t*)0x200000006358 = 6;
*(uint32_t*)0x20000000635c = 0x87;
*(uint32_t*)0x200000006360 = 7;
*(uint32_t*)0x200000006364 = 1;
*(uint32_t*)0x200000006368 = 0x7ca;
*(uint32_t*)0x20000000636c = 0xff;
*(uint32_t*)0x200000006370 = 0x10001;
*(uint32_t*)0x200000006374 = 5;
*(uint32_t*)0x200000006378 = 0xdfbd;
*(uint32_t*)0x20000000637c = 0x6d1b;
*(uint32_t*)0x200000006380 = 0xf4dc;
*(uint32_t*)0x200000006384 = 0xf8000000;
*(uint32_t*)0x200000006388 = 0xbfb;
*(uint32_t*)0x20000000638c = 0x200;
*(uint32_t*)0x200000006390 = 4;
*(uint32_t*)0x200000006394 = 0;
*(uint32_t*)0x200000006398 = 0xfffffff7;
*(uint32_t*)0x20000000639c = 6;
*(uint32_t*)0x2000000063a0 = 9;
*(uint32_t*)0x2000000063a4 = 0x80;
*(uint32_t*)0x2000000063a8 = 0;
*(uint32_t*)0x2000000063ac = 7;
*(uint32_t*)0x2000000063b0 = 9;
*(uint32_t*)0x2000000063b4 = 0x4d;
*(uint32_t*)0x2000000063b8 = 3;
*(uint32_t*)0x2000000063bc = 5;
*(uint32_t*)0x2000000063c0 = 9;
*(uint32_t*)0x2000000063c4 = 0x7ff;
*(uint32_t*)0x2000000063c8 = 1;
*(uint32_t*)0x2000000063cc = 7;
*(uint32_t*)0x2000000063d0 = 0;
*(uint32_t*)0x2000000063d4 = 2;
*(uint32_t*)0x2000000063d8 = 0xf;
*(uint32_t*)0x2000000063dc = 0x401;
*(uint32_t*)0x2000000063e0 = 2;
*(uint32_t*)0x2000000063e4 = 0x1000;
*(uint32_t*)0x2000000063e8 = 4;
*(uint32_t*)0x2000000063ec = -1;
*(uint32_t*)0x2000000063f0 = 7;
*(uint32_t*)0x2000000063f4 = 5;
*(uint32_t*)0x2000000063f8 = 0x80;
*(uint32_t*)0x2000000063fc = 0x1ff;
*(uint32_t*)0x200000006400 = 0xf;
*(uint32_t*)0x200000006404 = 9;
*(uint32_t*)0x200000006408 = 0;
*(uint32_t*)0x20000000640c = 6;
*(uint32_t*)0x200000006410 = 0xc1;
*(uint32_t*)0x200000006414 = 0xa;
*(uint32_t*)0x200000006418 = 2;
*(uint32_t*)0x20000000641c = 5;
*(uint32_t*)0x200000006420 = 0x38;
*(uint32_t*)0x200000006424 = 0xff;
*(uint32_t*)0x200000006428 = 0xffffff80;
*(uint32_t*)0x20000000642c = 0x9df;
*(uint32_t*)0x200000006430 = 6;
*(uint32_t*)0x200000006434 = 2;
*(uint32_t*)0x200000006438 = 0x1ff;
*(uint32_t*)0x20000000643c = 0;
*(uint32_t*)0x200000006440 = 8;
*(uint32_t*)0x200000006444 = 0xb;
*(uint32_t*)0x200000006448 = 0x200;
*(uint32_t*)0x20000000644c = 8;
*(uint32_t*)0x200000006450 = 1;
*(uint32_t*)0x200000006454 = 2;
*(uint32_t*)0x200000006458 = 2;
*(uint32_t*)0x20000000645c = 0x2ee9;
*(uint32_t*)0x200000006460 = 1;
*(uint32_t*)0x200000006464 = 5;
*(uint32_t*)0x200000006468 = 0;
*(uint32_t*)0x20000000646c = 0x80;
*(uint32_t*)0x200000006470 = 3;
*(uint32_t*)0x200000006474 = 0x80;
*(uint32_t*)0x200000006478 = 0x2ecc8490;
*(uint32_t*)0x20000000647c = 9;
*(uint32_t*)0x200000006480 = 0xa7;
*(uint32_t*)0x200000006484 = 0x24d;
*(uint32_t*)0x200000006488 = 0xa;
*(uint32_t*)0x20000000648c = 0;
*(uint32_t*)0x200000006490 = 0xfff;
*(uint32_t*)0x200000006494 = 0x18;
*(uint32_t*)0x200000006498 = 8;
*(uint32_t*)0x20000000649c = 0xa;
*(uint32_t*)0x2000000064a0 = 3;
*(uint32_t*)0x2000000064a4 = 0xd85;
*(uint32_t*)0x2000000064a8 = 0xd4;
*(uint32_t*)0x2000000064ac = 9;
*(uint32_t*)0x2000000064b0 = 0xc64a;
*(uint32_t*)0x2000000064b4 = 9;
*(uint32_t*)0x2000000064b8 = 0;
*(uint32_t*)0x2000000064bc = 0;
*(uint32_t*)0x2000000064c0 = 0;
*(uint32_t*)0x2000000064c4 = 0xfff;
*(uint32_t*)0x2000000064c8 = 7;
*(uint32_t*)0x2000000064cc = 6;
*(uint32_t*)0x2000000064d0 = 0xabd;
*(uint32_t*)0x2000000064d4 = 3;
*(uint32_t*)0x2000000064d8 = 0x8000;
*(uint32_t*)0x2000000064dc = 3;
*(uint32_t*)0x2000000064e0 = 4;
*(uint32_t*)0x2000000064e4 = 1;
*(uint32_t*)0x2000000064e8 = 7;
*(uint32_t*)0x2000000064ec = 9;
*(uint32_t*)0x2000000064f0 = 0xdd7;
*(uint32_t*)0x2000000064f4 = 0xfff;
*(uint32_t*)0x2000000064f8 = 5;
*(uint32_t*)0x2000000064fc = 3;
*(uint32_t*)0x200000006500 = 7;
*(uint32_t*)0x200000006504 = 9;
*(uint32_t*)0x200000006508 = 9;
*(uint32_t*)0x20000000650c = 0xb;
*(uint32_t*)0x200000006510 = 4;
*(uint32_t*)0x200000006514 = 0x80;
*(uint32_t*)0x200000006518 = 4;
*(uint32_t*)0x20000000651c = 3;
*(uint32_t*)0x200000006520 = 6;
*(uint32_t*)0x200000006524 = 0x10000;
*(uint32_t*)0x200000006528 = 1;
*(uint32_t*)0x20000000652c = 0xb;
*(uint32_t*)0x200000006530 = 6;
*(uint32_t*)0x200000006534 = 0xe;
*(uint32_t*)0x200000006538 = 1;
*(uint32_t*)0x20000000653c = 0xfff;
*(uint32_t*)0x200000006540 = 0;
*(uint32_t*)0x200000006544 = 0xff;
*(uint32_t*)0x200000006548 = 0;
*(uint32_t*)0x20000000654c = 0xc;
*(uint32_t*)0x200000006550 = 0xa4;
*(uint32_t*)0x200000006554 = 0x7f;
*(uint32_t*)0x200000006558 = 0x24;
*(uint32_t*)0x20000000655c = 0xa9a;
*(uint32_t*)0x200000006560 = 8;
*(uint32_t*)0x200000006564 = 5;
*(uint32_t*)0x200000006568 = 0x8001;
*(uint32_t*)0x20000000656c = 0x2ba;
*(uint32_t*)0x200000006570 = 0x8001;
*(uint32_t*)0x200000006574 = 0x854;
*(uint32_t*)0x200000006578 = 4;
*(uint32_t*)0x20000000657c = 0xe7;
*(uint32_t*)0x200000006580 = 2;
*(uint32_t*)0x200000006584 = 3;
*(uint32_t*)0x200000006588 = 2;
*(uint32_t*)0x20000000658c = 5;
*(uint32_t*)0x200000006590 = 5;
*(uint32_t*)0x200000006594 = 2;
*(uint32_t*)0x200000006598 = 9;
*(uint32_t*)0x20000000659c = 0x3ff;
*(uint32_t*)0x2000000065a0 = 1;
*(uint32_t*)0x2000000065a4 = -1;
*(uint32_t*)0x2000000065a8 = 8;
*(uint32_t*)0x2000000065ac = 0xfff;
*(uint32_t*)0x2000000065b0 = 9;
*(uint32_t*)0x2000000065b4 = 2;
*(uint32_t*)0x2000000065b8 = 3;
*(uint32_t*)0x2000000065bc = 0;
*(uint32_t*)0x2000000065c0 = 0x80000000;
*(uint32_t*)0x2000000065c4 = 8;
*(uint32_t*)0x2000000065c8 = 0xfff;
*(uint32_t*)0x2000000065cc = 0;
*(uint32_t*)0x2000000065d0 = 0x86;
*(uint32_t*)0x2000000065d4 = 0x81;
*(uint32_t*)0x2000000065d8 = 9;
*(uint32_t*)0x2000000065dc = 9;
*(uint32_t*)0x2000000065e0 = 0x800;
*(uint32_t*)0x2000000065e4 = 0xfffffffd;
*(uint32_t*)0x2000000065e8 = 0x9c1;
*(uint32_t*)0x2000000065ec = 2;
*(uint32_t*)0x2000000065f0 = 0xfffffffc;
*(uint32_t*)0x2000000065f4 = 8;
*(uint32_t*)0x2000000065f8 = 0xc;
*(uint32_t*)0x2000000065fc = 2;
*(uint32_t*)0x200000006600 = 0;
*(uint32_t*)0x200000006604 = 3;
*(uint32_t*)0x200000006608 = 7;
*(uint32_t*)0x20000000660c = 5;
*(uint32_t*)0x200000006610 = 0xd;
*(uint32_t*)0x200000006614 = 0xb;
*(uint16_t*)0x200000006618 = 0xc;
*(uint16_t*)0x20000000661a = 8;
*(uint64_t*)0x20000000661c = 5;
*(uint16_t*)0x200000006624 = 0x404;
*(uint16_t*)0x200000006626 = 3;
*(uint32_t*)0x200000006628 = 3;
*(uint32_t*)0x20000000662c = 4;
*(uint32_t*)0x200000006630 = 0xc6c;
*(uint32_t*)0x200000006634 = 9;
*(uint32_t*)0x200000006638 = 0xb;
*(uint32_t*)0x20000000663c = 2;
*(uint32_t*)0x200000006640 = 3;
*(uint32_t*)0x200000006644 = 1;
*(uint32_t*)0x200000006648 = 8;
*(uint32_t*)0x20000000664c = 1;
*(uint32_t*)0x200000006650 = 0;
*(uint32_t*)0x200000006654 = 0x7ff;
*(uint32_t*)0x200000006658 = 1;
*(uint32_t*)0x20000000665c = 0x8001;
*(uint32_t*)0x200000006660 = 5;
*(uint32_t*)0x200000006664 = 0x7f;
*(uint32_t*)0x200000006668 = 8;
*(uint32_t*)0x20000000666c = 6;
*(uint32_t*)0x200000006670 = 7;
*(uint32_t*)0x200000006674 = -1;
*(uint32_t*)0x200000006678 = 2;
*(uint32_t*)0x20000000667c = 0xf;
*(uint32_t*)0x200000006680 = 4;
*(uint32_t*)0x200000006684 = -1;
*(uint32_t*)0x200000006688 = 1;
*(uint32_t*)0x20000000668c = 0x1000000;
*(uint32_t*)0x200000006690 = 0xf;
*(uint32_t*)0x200000006694 = 2;
*(uint32_t*)0x200000006698 = 4;
*(uint32_t*)0x20000000669c = 5;
*(uint32_t*)0x2000000066a0 = 3;
*(uint32_t*)0x2000000066a4 = 0x8000;
*(uint32_t*)0x2000000066a8 = 0x9f4f5d67;
*(uint32_t*)0x2000000066ac = 9;
*(uint32_t*)0x2000000066b0 = 9;
*(uint32_t*)0x2000000066b4 = 0;
*(uint32_t*)0x2000000066b8 = 7;
*(uint32_t*)0x2000000066bc = 8;
*(uint32_t*)0x2000000066c0 = 8;
*(uint32_t*)0x2000000066c4 = 0x7ff;
*(uint32_t*)0x2000000066c8 = 2;
*(uint32_t*)0x2000000066cc = 0x32;
*(uint32_t*)0x2000000066d0 = 3;
*(uint32_t*)0x2000000066d4 = 8;
*(uint32_t*)0x2000000066d8 = 0x30000000;
*(uint32_t*)0x2000000066dc = 0xdd;
*(uint32_t*)0x2000000066e0 = 0;
*(uint32_t*)0x2000000066e4 = 1;
*(uint32_t*)0x2000000066e8 = 0x400;
*(uint32_t*)0x2000000066ec = 3;
*(uint32_t*)0x2000000066f0 = 8;
*(uint32_t*)0x2000000066f4 = 0x101;
*(uint32_t*)0x2000000066f8 = -1;
*(uint32_t*)0x2000000066fc = 9;
*(uint32_t*)0x200000006700 = 3;
*(uint32_t*)0x200000006704 = 0xa;
*(uint32_t*)0x200000006708 = 6;
*(uint32_t*)0x20000000670c = 0xd;
*(uint32_t*)0x200000006710 = 2;
*(uint32_t*)0x200000006714 = 7;
*(uint32_t*)0x200000006718 = 3;
*(uint32_t*)0x20000000671c = 9;
*(uint32_t*)0x200000006720 = 0x39c0;
*(uint32_t*)0x200000006724 = 3;
*(uint32_t*)0x200000006728 = 4;
*(uint32_t*)0x20000000672c = 0x94b;
*(uint32_t*)0x200000006730 = 5;
*(uint32_t*)0x200000006734 = 1;
*(uint32_t*)0x200000006738 = 0x777;
*(uint32_t*)0x20000000673c = 2;
*(uint32_t*)0x200000006740 = 9;
*(uint32_t*)0x200000006744 = 0x800;
*(uint32_t*)0x200000006748 = 0x1000;
*(uint32_t*)0x20000000674c = 0xa;
*(uint32_t*)0x200000006750 = 0x9e;
*(uint32_t*)0x200000006754 = 0xcc;
*(uint32_t*)0x200000006758 = 8;
*(uint32_t*)0x20000000675c = 0;
*(uint32_t*)0x200000006760 = 0xffffff37;
*(uint32_t*)0x200000006764 = 9;
*(uint32_t*)0x200000006768 = 7;
*(uint32_t*)0x20000000676c = 8;
*(uint32_t*)0x200000006770 = 0x7ff;
*(uint32_t*)0x200000006774 = 7;
*(uint32_t*)0x200000006778 = -1;
*(uint32_t*)0x20000000677c = 8;
*(uint32_t*)0x200000006780 = 0xfffffffc;
*(uint32_t*)0x200000006784 = 0x101;
*(uint32_t*)0x200000006788 = 8;
*(uint32_t*)0x20000000678c = 9;
*(uint32_t*)0x200000006790 = 4;
*(uint32_t*)0x200000006794 = 9;
*(uint32_t*)0x200000006798 = 4;
*(uint32_t*)0x20000000679c = 9;
*(uint32_t*)0x2000000067a0 = 7;
*(uint32_t*)0x2000000067a4 = 4;
*(uint32_t*)0x2000000067a8 = 0xf3;
*(uint32_t*)0x2000000067ac = 1;
*(uint32_t*)0x2000000067b0 = 0x10000;
*(uint32_t*)0x2000000067b4 = 0x10000;
*(uint32_t*)0x2000000067b8 = 8;
*(uint32_t*)0x2000000067bc = 0x7a36;
*(uint32_t*)0x2000000067c0 = 7;
*(uint32_t*)0x2000000067c4 = 0x40;
*(uint32_t*)0x2000000067c8 = 0xd10;
*(uint32_t*)0x2000000067cc = 0x455e;
*(uint32_t*)0x2000000067d0 = 4;
*(uint32_t*)0x2000000067d4 = 4;
*(uint32_t*)0x2000000067d8 = 5;
*(uint32_t*)0x2000000067dc = 0xff;
*(uint32_t*)0x2000000067e0 = 2;
*(uint32_t*)0x2000000067e4 = 6;
*(uint32_t*)0x2000000067e8 = 0x40000;
*(uint32_t*)0x2000000067ec = -1;
*(uint32_t*)0x2000000067f0 = 0x18bc169;
*(uint32_t*)0x2000000067f4 = 0x10;
*(uint32_t*)0x2000000067f8 = 4;
*(uint32_t*)0x2000000067fc = 0xb66;
*(uint32_t*)0x200000006800 = 0x100;
*(uint32_t*)0x200000006804 = 5;
*(uint32_t*)0x200000006808 = 0x3d;
*(uint32_t*)0x20000000680c = 5;
*(uint32_t*)0x200000006810 = 0;
*(uint32_t*)0x200000006814 = 0x81;
*(uint32_t*)0x200000006818 = 0x81;
*(uint32_t*)0x20000000681c = 2;
*(uint32_t*)0x200000006820 = 0x8001;
*(uint32_t*)0x200000006824 = 4;
*(uint32_t*)0x200000006828 = 7;
*(uint32_t*)0x20000000682c = 9;
*(uint32_t*)0x200000006830 = 3;
*(uint32_t*)0x200000006834 = 0xc;
*(uint32_t*)0x200000006838 = 1;
*(uint32_t*)0x20000000683c = 0;
*(uint32_t*)0x200000006840 = 6;
*(uint32_t*)0x200000006844 = 0x7fffffff;
*(uint32_t*)0x200000006848 = 0x52acd031;
*(uint32_t*)0x20000000684c = 0xf938;
*(uint32_t*)0x200000006850 = 0xc8;
*(uint32_t*)0x200000006854 = 0x1b;
*(uint32_t*)0x200000006858 = 3;
*(uint32_t*)0x20000000685c = 0x80000001;
*(uint32_t*)0x200000006860 = 9;
*(uint32_t*)0x200000006864 = 6;
*(uint32_t*)0x200000006868 = 2;
*(uint32_t*)0x20000000686c = 8;
*(uint32_t*)0x200000006870 = 0x41;
*(uint32_t*)0x200000006874 = 0x401;
*(uint32_t*)0x200000006878 = 0xfff;
*(uint32_t*)0x20000000687c = 7;
*(uint32_t*)0x200000006880 = 0x100007;
*(uint32_t*)0x200000006884 = 1;
*(uint32_t*)0x200000006888 = 0xd17;
*(uint32_t*)0x20000000688c = 7;
*(uint32_t*)0x200000006890 = 0x400;
*(uint32_t*)0x200000006894 = 0;
*(uint32_t*)0x200000006898 = 4;
*(uint32_t*)0x20000000689c = 0x80000000;
*(uint32_t*)0x2000000068a0 = 0x400;
*(uint32_t*)0x2000000068a4 = 1;
*(uint32_t*)0x2000000068a8 = 0xfffffffd;
*(uint32_t*)0x2000000068ac = 0xc6;
*(uint32_t*)0x2000000068b0 = 9;
*(uint32_t*)0x2000000068b4 = 8;
*(uint32_t*)0x2000000068b8 = 7;
*(uint32_t*)0x2000000068bc = 0x25;
*(uint32_t*)0x2000000068c0 = 2;
*(uint32_t*)0x2000000068c4 = 0x400;
*(uint32_t*)0x2000000068c8 = 4;
*(uint32_t*)0x2000000068cc = 0xb;
*(uint32_t*)0x2000000068d0 = 3;
*(uint32_t*)0x2000000068d4 = 1;
*(uint32_t*)0x2000000068d8 = 6;
*(uint32_t*)0x2000000068dc = 0;
*(uint32_t*)0x2000000068e0 = 0x81;
*(uint32_t*)0x2000000068e4 = 1;
*(uint32_t*)0x2000000068e8 = 0;
*(uint32_t*)0x2000000068ec = 0x200000a;
*(uint32_t*)0x2000000068f0 = 3;
*(uint32_t*)0x2000000068f4 = 3;
*(uint32_t*)0x2000000068f8 = 7;
*(uint32_t*)0x2000000068fc = 0x8000;
*(uint32_t*)0x200000006900 = 0xd;
*(uint32_t*)0x200000006904 = 8;
*(uint32_t*)0x200000006908 = 3;
*(uint32_t*)0x20000000690c = 0xb;
*(uint32_t*)0x200000006910 = 9;
*(uint32_t*)0x200000006914 = 0xff;
*(uint32_t*)0x200000006918 = 0;
*(uint32_t*)0x20000000691c = 0;
*(uint32_t*)0x200000006920 = 3;
*(uint32_t*)0x200000006924 = 0x83;
*(uint32_t*)0x200000006928 = 0x1ff;
*(uint32_t*)0x20000000692c = 1;
*(uint32_t*)0x200000006930 = 4;
*(uint32_t*)0x200000006934 = 0xa;
*(uint32_t*)0x200000006938 = 0x87;
*(uint32_t*)0x20000000693c = 0x800;
*(uint32_t*)0x200000006940 = 0xdba;
*(uint32_t*)0x200000006944 = 0;
*(uint32_t*)0x200000006948 = 0xe1d;
*(uint32_t*)0x20000000694c = 0x7f;
*(uint32_t*)0x200000006950 = 7;
*(uint32_t*)0x200000006954 = 0x8001;
*(uint32_t*)0x200000006958 = 9;
*(uint32_t*)0x20000000695c = 9;
*(uint32_t*)0x200000006960 = 0xfffffffa;
*(uint32_t*)0x200000006964 = 8;
*(uint32_t*)0x200000006968 = 4;
*(uint32_t*)0x20000000696c = 5;
*(uint32_t*)0x200000006970 = 0xff;
*(uint32_t*)0x200000006974 = 7;
*(uint32_t*)0x200000006978 = 9;
*(uint32_t*)0x20000000697c = 0x9ca;
*(uint32_t*)0x200000006980 = 0;
*(uint32_t*)0x200000006984 = 0xc;
*(uint32_t*)0x200000006988 = 9;
*(uint32_t*)0x20000000698c = 0xfffffb9b;
*(uint32_t*)0x200000006990 = 0xd;
*(uint32_t*)0x200000006994 = 0xfff;
*(uint32_t*)0x200000006998 = 9;
*(uint32_t*)0x20000000699c = 2;
*(uint32_t*)0x2000000069a0 = 0x800;
*(uint32_t*)0x2000000069a4 = 0xfffffff7;
*(uint32_t*)0x2000000069a8 = 0x7ff;
*(uint32_t*)0x2000000069ac = 5;
*(uint32_t*)0x2000000069b0 = 5;
*(uint32_t*)0x2000000069b4 = 0x8001;
*(uint32_t*)0x2000000069b8 = 1;
*(uint32_t*)0x2000000069bc = 0x80000001;
*(uint32_t*)0x2000000069c0 = 0xc9;
*(uint32_t*)0x2000000069c4 = 2;
*(uint32_t*)0x2000000069c8 = 1;
*(uint32_t*)0x2000000069cc = 0x8001;
*(uint32_t*)0x2000000069d0 = 5;
*(uint32_t*)0x2000000069d4 = 9;
*(uint32_t*)0x2000000069d8 = 3;
*(uint32_t*)0x2000000069dc = 8;
*(uint32_t*)0x2000000069e0 = 0xe47;
*(uint32_t*)0x2000000069e4 = 0x1ff;
*(uint32_t*)0x2000000069e8 = 3;
*(uint32_t*)0x2000000069ec = 2;
*(uint32_t*)0x2000000069f0 = 0x49;
*(uint32_t*)0x2000000069f4 = 7;
*(uint32_t*)0x2000000069f8 = 0xfffffa1f;
*(uint32_t*)0x2000000069fc = 1;
*(uint32_t*)0x200000006a00 = 0x7f;
*(uint32_t*)0x200000006a04 = 4;
*(uint32_t*)0x200000006a08 = 0x3ff;
*(uint32_t*)0x200000006a0c = 3;
*(uint32_t*)0x200000006a10 = 0x18000;
*(uint32_t*)0x200000006a14 = 0x4d0;
*(uint32_t*)0x200000006a18 = 0x8000;
*(uint32_t*)0x200000006a1c = 6;
*(uint32_t*)0x200000006a20 = 2;
*(uint32_t*)0x200000006a24 = 0x5cd;
*(uint16_t*)0x200000006a28 = 8;
*(uint16_t*)0x200000006a2a = 4;
*(uint32_t*)0x200000006a2c = 0x80;
*(uint16_t*)0x200000006a30 = 0x404;
*(uint16_t*)0x200000006a32 = 2;
*(uint32_t*)0x200000006a34 = 6;
*(uint32_t*)0x200000006a38 = 0;
*(uint32_t*)0x200000006a3c = 0x80000000;
*(uint32_t*)0x200000006a40 = 4;
*(uint32_t*)0x200000006a44 = 7;
*(uint32_t*)0x200000006a48 = 3;
*(uint32_t*)0x200000006a4c = 0x200;
*(uint32_t*)0x200000006a50 = 4;
*(uint32_t*)0x200000006a54 = 0;
*(uint32_t*)0x200000006a58 = 5;
*(uint32_t*)0x200000006a5c = 0x7fffffff;
*(uint32_t*)0x200000006a60 = 9;
*(uint32_t*)0x200000006a64 = 4;
*(uint32_t*)0x200000006a68 = 0x101;
*(uint32_t*)0x200000006a6c = 0xffffff51;
*(uint32_t*)0x200000006a70 = 5;
*(uint32_t*)0x200000006a74 = 2;
*(uint32_t*)0x200000006a78 = 0x401;
*(uint32_t*)0x200000006a7c = 3;
*(uint32_t*)0x200000006a80 = 0xd5c6;
*(uint32_t*)0x200000006a84 = 0x400;
*(uint32_t*)0x200000006a88 = 9;
*(uint32_t*)0x200000006a8c = 0x9c3;
*(uint32_t*)0x200000006a90 = 0;
*(uint32_t*)0x200000006a94 = 0xb;
*(uint32_t*)0x200000006a98 = 0;
*(uint32_t*)0x200000006a9c = 0xfffffffa;
*(uint32_t*)0x200000006aa0 = 3;
*(uint32_t*)0x200000006aa4 = 0;
*(uint32_t*)0x200000006aa8 = 5;
*(uint32_t*)0x200000006aac = 0xd9;
*(uint32_t*)0x200000006ab0 = 0xef;
*(uint32_t*)0x200000006ab4 = 7;
*(uint32_t*)0x200000006ab8 = -1;
*(uint32_t*)0x200000006abc = 7;
*(uint32_t*)0x200000006ac0 = 1;
*(uint32_t*)0x200000006ac4 = 0xffff;
*(uint32_t*)0x200000006ac8 = 0xfffffffb;
*(uint32_t*)0x200000006acc = 9;
*(uint32_t*)0x200000006ad0 = 8;
*(uint32_t*)0x200000006ad4 = 3;
*(uint32_t*)0x200000006ad8 = 0;
*(uint32_t*)0x200000006adc = 3;
*(uint32_t*)0x200000006ae0 = 4;
*(uint32_t*)0x200000006ae4 = 2;
*(uint32_t*)0x200000006ae8 = 0xfffffffd;
*(uint32_t*)0x200000006aec = 7;
*(uint32_t*)0x200000006af0 = 9;
*(uint32_t*)0x200000006af4 = 0xffff;
*(uint32_t*)0x200000006af8 = 0x800;
*(uint32_t*)0x200000006afc = 0xfffffff8;
*(uint32_t*)0x200000006b00 = 0;
*(uint32_t*)0x200000006b04 = 0xb;
*(uint32_t*)0x200000006b08 = 6;
*(uint32_t*)0x200000006b0c = 0x67;
*(uint32_t*)0x200000006b10 = 0xfd0;
*(uint32_t*)0x200000006b14 = 0xffffffbe;
*(uint32_t*)0x200000006b18 = 2;
*(uint32_t*)0x200000006b1c = 1;
*(uint32_t*)0x200000006b20 = 2;
*(uint32_t*)0x200000006b24 = 4;
*(uint32_t*)0x200000006b28 = 5;
*(uint32_t*)0x200000006b2c = 1;
*(uint32_t*)0x200000006b30 = 0;
*(uint32_t*)0x200000006b34 = 0xff;
*(uint32_t*)0x200000006b38 = 0x101;
*(uint32_t*)0x200000006b3c = 1;
*(uint32_t*)0x200000006b40 = 0;
*(uint32_t*)0x200000006b44 = 1;
*(uint32_t*)0x200000006b48 = 0;
*(uint32_t*)0x200000006b4c = 0xffff;
*(uint32_t*)0x200000006b50 = 0xfffffff7;
*(uint32_t*)0x200000006b54 = 8;
*(uint32_t*)0x200000006b58 = 9;
*(uint32_t*)0x200000006b5c = 0xa2;
*(uint32_t*)0x200000006b60 = 0x1336df01;
*(uint32_t*)0x200000006b64 = -1;
*(uint32_t*)0x200000006b68 = 0x81;
*(uint32_t*)0x200000006b6c = 9;
*(uint32_t*)0x200000006b70 = 3;
*(uint32_t*)0x200000006b74 = 0x40;
*(uint32_t*)0x200000006b78 = 0;
*(uint32_t*)0x200000006b7c = 0xf;
*(uint32_t*)0x200000006b80 = 0x3ff;
*(uint32_t*)0x200000006b84 = 1;
*(uint32_t*)0x200000006b88 = 0x80000001;
*(uint32_t*)0x200000006b8c = 0xc0d7;
*(uint32_t*)0x200000006b90 = 0xf9;
*(uint32_t*)0x200000006b94 = 0x59;
*(uint32_t*)0x200000006b98 = 0x1000;
*(uint32_t*)0x200000006b9c = 0;
*(uint32_t*)0x200000006ba0 = 0;
*(uint32_t*)0x200000006ba4 = 0x400;
*(uint32_t*)0x200000006ba8 = 6;
*(uint32_t*)0x200000006bac = 9;
*(uint32_t*)0x200000006bb0 = 0x8001;
*(uint32_t*)0x200000006bb4 = 0xff6d;
*(uint32_t*)0x200000006bb8 = 0x1ff;
*(uint32_t*)0x200000006bbc = 6;
*(uint32_t*)0x200000006bc0 = 0x7f;
*(uint32_t*)0x200000006bc4 = 0x90000;
*(uint32_t*)0x200000006bc8 = 8;
*(uint32_t*)0x200000006bcc = 0xf;
*(uint32_t*)0x200000006bd0 = 9;
*(uint32_t*)0x200000006bd4 = 3;
*(uint32_t*)0x200000006bd8 = 0x8cca;
*(uint32_t*)0x200000006bdc = 0x8000;
*(uint32_t*)0x200000006be0 = -1;
*(uint32_t*)0x200000006be4 = 0;
*(uint32_t*)0x200000006be8 = 5;
*(uint32_t*)0x200000006bec = 0x10000;
*(uint32_t*)0x200000006bf0 = 9;
*(uint32_t*)0x200000006bf4 = 1;
*(uint32_t*)0x200000006bf8 = 7;
*(uint32_t*)0x200000006bfc = 3;
*(uint32_t*)0x200000006c00 = 8;
*(uint32_t*)0x200000006c04 = 0xaa;
*(uint32_t*)0x200000006c08 = 8;
*(uint32_t*)0x200000006c0c = 4;
*(uint32_t*)0x200000006c10 = 3;
*(uint32_t*)0x200000006c14 = 1;
*(uint32_t*)0x200000006c18 = 0x40;
*(uint32_t*)0x200000006c1c = -1;
*(uint32_t*)0x200000006c20 = 7;
*(uint32_t*)0x200000006c24 = 4;
*(uint32_t*)0x200000006c28 = 0xfffffff5;
*(uint32_t*)0x200000006c2c = 0x95c;
*(uint32_t*)0x200000006c30 = 0xf6;
*(uint32_t*)0x200000006c34 = 4;
*(uint32_t*)0x200000006c38 = 2;
*(uint32_t*)0x200000006c3c = 0x7fffffff;
*(uint32_t*)0x200000006c40 = 9;
*(uint32_t*)0x200000006c44 = 4;
*(uint32_t*)0x200000006c48 = 0x1000;
*(uint32_t*)0x200000006c4c = 1;
*(uint32_t*)0x200000006c50 = 7;
*(uint32_t*)0x200000006c54 = 0xffff7fff;
*(uint32_t*)0x200000006c58 = 9;
*(uint32_t*)0x200000006c5c = 0x71;
*(uint32_t*)0x200000006c60 = 0xff;
*(uint32_t*)0x200000006c64 = 0;
*(uint32_t*)0x200000006c68 = 0;
*(uint32_t*)0x200000006c6c = 5;
*(uint32_t*)0x200000006c70 = 0xb4;
*(uint32_t*)0x200000006c74 = 0x3ff;
*(uint32_t*)0x200000006c78 = 1;
*(uint32_t*)0x200000006c7c = 6;
*(uint32_t*)0x200000006c80 = 9;
*(uint32_t*)0x200000006c84 = 6;
*(uint32_t*)0x200000006c88 = 3;
*(uint32_t*)0x200000006c8c = 0x7791070f;
*(uint32_t*)0x200000006c90 = 9;
*(uint32_t*)0x200000006c94 = 0x4eb8;
*(uint32_t*)0x200000006c98 = 7;
*(uint32_t*)0x200000006c9c = 0xe2;
*(uint32_t*)0x200000006ca0 = 9;
*(uint32_t*)0x200000006ca4 = 9;
*(uint32_t*)0x200000006ca8 = 3;
*(uint32_t*)0x200000006cac = 1;
*(uint32_t*)0x200000006cb0 = 5;
*(uint32_t*)0x200000006cb4 = 8;
*(uint32_t*)0x200000006cb8 = 1;
*(uint32_t*)0x200000006cbc = 8;
*(uint32_t*)0x200000006cc0 = 5;
*(uint32_t*)0x200000006cc4 = 6;
*(uint32_t*)0x200000006cc8 = 5;
*(uint32_t*)0x200000006ccc = 5;
*(uint32_t*)0x200000006cd0 = 0xffffff01;
*(uint32_t*)0x200000006cd4 = 0xfffffffe;
*(uint32_t*)0x200000006cd8 = 0xc;
*(uint32_t*)0x200000006cdc = 4;
*(uint32_t*)0x200000006ce0 = 0x40;
*(uint32_t*)0x200000006ce4 = 0x400;
*(uint32_t*)0x200000006ce8 = 3;
*(uint32_t*)0x200000006cec = 7;
*(uint32_t*)0x200000006cf0 = 9;
*(uint32_t*)0x200000006cf4 = 0;
*(uint32_t*)0x200000006cf8 = 0x38;
*(uint32_t*)0x200000006cfc = 5;
*(uint32_t*)0x200000006d00 = 0xb25;
*(uint32_t*)0x200000006d04 = 5;
*(uint32_t*)0x200000006d08 = 0x73c0;
*(uint32_t*)0x200000006d0c = 4;
*(uint32_t*)0x200000006d10 = 0x9000000;
*(uint32_t*)0x200000006d14 = 6;
*(uint32_t*)0x200000006d18 = 5;
*(uint32_t*)0x200000006d1c = 0x57b;
*(uint32_t*)0x200000006d20 = 0xa;
*(uint32_t*)0x200000006d24 = 0x7f;
*(uint32_t*)0x200000006d28 = 0x3fb2;
*(uint32_t*)0x200000006d2c = 0xce;
*(uint32_t*)0x200000006d30 = 0x8000;
*(uint32_t*)0x200000006d34 = 0xb315;
*(uint32_t*)0x200000006d38 = 0xfffffff2;
*(uint32_t*)0x200000006d3c = 2;
*(uint32_t*)0x200000006d40 = 3;
*(uint32_t*)0x200000006d44 = 5;
*(uint32_t*)0x200000006d48 = 1;
*(uint32_t*)0x200000006d4c = -1;
*(uint32_t*)0x200000006d50 = 3;
*(uint32_t*)0x200000006d54 = 5;
*(uint32_t*)0x200000006d58 = 5;
*(uint32_t*)0x200000006d5c = 6;
*(uint32_t*)0x200000006d60 = 0x8001;
*(uint32_t*)0x200000006d64 = 0xfffffff8;
*(uint32_t*)0x200000006d68 = 4;
*(uint32_t*)0x200000006d6c = 0xf;
*(uint32_t*)0x200000006d70 = 0xfffffffd;
*(uint32_t*)0x200000006d74 = 0x100;
*(uint32_t*)0x200000006d78 = 2;
*(uint32_t*)0x200000006d7c = 0x101;
*(uint32_t*)0x200000006d80 = 8;
*(uint32_t*)0x200000006d84 = 9;
*(uint32_t*)0x200000006d88 = 5;
*(uint32_t*)0x200000006d8c = 1;
*(uint32_t*)0x200000006d90 = 3;
*(uint32_t*)0x200000006d94 = 4;
*(uint32_t*)0x200000006d98 = 0x3ff;
*(uint32_t*)0x200000006d9c = 4;
*(uint32_t*)0x200000006da0 = 0x100;
*(uint32_t*)0x200000006da4 = 4;
*(uint32_t*)0x200000006da8 = 6;
*(uint32_t*)0x200000006dac = 0xffff8000;
*(uint32_t*)0x200000006db0 = 2;
*(uint32_t*)0x200000006db4 = 0xb;
*(uint32_t*)0x200000006db8 = 0x1000;
*(uint32_t*)0x200000006dbc = 0x7282;
*(uint32_t*)0x200000006dc0 = 9;
*(uint32_t*)0x200000006dc4 = 0x8c;
*(uint32_t*)0x200000006dc8 = 7;
*(uint32_t*)0x200000006dcc = 0xe;
*(uint32_t*)0x200000006dd0 = 0x81;
*(uint32_t*)0x200000006dd4 = 9;
*(uint32_t*)0x200000006dd8 = 2;
*(uint32_t*)0x200000006ddc = 5;
*(uint32_t*)0x200000006de0 = 6;
*(uint32_t*)0x200000006de4 = 1;
*(uint32_t*)0x200000006de8 = 0x10000;
*(uint32_t*)0x200000006dec = 0xff;
*(uint32_t*)0x200000006df0 = 0x1c;
*(uint32_t*)0x200000006df4 = 1;
*(uint32_t*)0x200000006df8 = 6;
*(uint32_t*)0x200000006dfc = 0x8000;
*(uint32_t*)0x200000006e00 = 5;
*(uint32_t*)0x200000006e04 = 8;
*(uint32_t*)0x200000006e08 = 6;
*(uint32_t*)0x200000006e0c = 0x81;
*(uint32_t*)0x200000006e10 = 0xa;
*(uint32_t*)0x200000006e14 = 0xf;
*(uint32_t*)0x200000006e18 = 0xbc;
*(uint32_t*)0x200000006e1c = 0x1ff;
*(uint32_t*)0x200000006e20 = 9;
*(uint32_t*)0x200000006e24 = 3;
*(uint32_t*)0x200000006e28 = 5;
*(uint32_t*)0x200000006e2c = 0x1000;
*(uint32_t*)0x200000006e30 = 9;
*(uint16_t*)0x200000006e34 = 0x404;
*(uint16_t*)0x200000006e36 = 3;
*(uint32_t*)0x200000006e38 = 0x8cf;
*(uint32_t*)0x200000006e3c = 0x3ff;
*(uint32_t*)0x200000006e40 = 4;
*(uint32_t*)0x200000006e44 = 0x59c;
*(uint32_t*)0x200000006e48 = 3;
*(uint32_t*)0x200000006e4c = 0xfffffffc;
*(uint32_t*)0x200000006e50 = 0x5f2c;
*(uint32_t*)0x200000006e54 = 3;
*(uint32_t*)0x200000006e58 = 0x100;
*(uint32_t*)0x200000006e5c = 0x35b;
*(uint32_t*)0x200000006e60 = 0xbe;
*(uint32_t*)0x200000006e64 = 0x7d;
*(uint32_t*)0x200000006e68 = 0xab99;
*(uint32_t*)0x200000006e6c = 4;
*(uint32_t*)0x200000006e70 = 0x101;
*(uint32_t*)0x200000006e74 = 0;
*(uint32_t*)0x200000006e78 = 0xf76;
*(uint32_t*)0x200000006e7c = 0x8001;
*(uint32_t*)0x200000006e80 = 4;
*(uint32_t*)0x200000006e84 = 0x3ff;
*(uint32_t*)0x200000006e88 = 0xd;
*(uint32_t*)0x200000006e8c = 7;
*(uint32_t*)0x200000006e90 = 6;
*(uint32_t*)0x200000006e94 = 8;
*(uint32_t*)0x200000006e98 = 7;
*(uint32_t*)0x200000006e9c = 7;
*(uint32_t*)0x200000006ea0 = 4;
*(uint32_t*)0x200000006ea4 = 6;
*(uint32_t*)0x200000006ea8 = 0;
*(uint32_t*)0x200000006eac = 0xab45;
*(uint32_t*)0x200000006eb0 = 0x8244;
*(uint32_t*)0x200000006eb4 = 0x60000;
*(uint32_t*)0x200000006eb8 = 0xe2a;
*(uint32_t*)0x200000006ebc = 0xae8;
*(uint32_t*)0x200000006ec0 = 1;
*(uint32_t*)0x200000006ec4 = 0x20076355;
*(uint32_t*)0x200000006ec8 = 3;
*(uint32_t*)0x200000006ecc = 2;
*(uint32_t*)0x200000006ed0 = 0x10;
*(uint32_t*)0x200000006ed4 = 4;
*(uint32_t*)0x200000006ed8 = 0xa;
*(uint32_t*)0x200000006edc = 0xd;
*(uint32_t*)0x200000006ee0 = 9;
*(uint32_t*)0x200000006ee4 = 5;
*(uint32_t*)0x200000006ee8 = 1;
*(uint32_t*)0x200000006eec = 0x7ff;
*(uint32_t*)0x200000006ef0 = 0x200;
*(uint32_t*)0x200000006ef4 = 0xcb;
*(uint32_t*)0x200000006ef8 = 2;
*(uint32_t*)0x200000006efc = 7;
*(uint32_t*)0x200000006f00 = 0x80;
*(uint32_t*)0x200000006f04 = 5;
*(uint32_t*)0x200000006f08 = 4;
*(uint32_t*)0x200000006f0c = 1;
*(uint32_t*)0x200000006f10 = 0x45e;
*(uint32_t*)0x200000006f14 = 8;
*(uint32_t*)0x200000006f18 = 0x1f;
*(uint32_t*)0x200000006f1c = 4;
*(uint32_t*)0x200000006f20 = 7;
*(uint32_t*)0x200000006f24 = 0x80000001;
*(uint32_t*)0x200000006f28 = 5;
*(uint32_t*)0x200000006f2c = 0;
*(uint32_t*)0x200000006f30 = 4;
*(uint32_t*)0x200000006f34 = 0x800;
*(uint32_t*)0x200000006f38 = 0xfffffffc;
*(uint32_t*)0x200000006f3c = 7;
*(uint32_t*)0x200000006f40 = 0x81;
*(uint32_t*)0x200000006f44 = 0x6e3833b8;
*(uint32_t*)0x200000006f48 = 9;
*(uint32_t*)0x200000006f4c = 0x5520;
*(uint32_t*)0x200000006f50 = 0;
*(uint32_t*)0x200000006f54 = 0;
*(uint32_t*)0x200000006f58 = 0xe1;
*(uint32_t*)0x200000006f5c = 4;
*(uint32_t*)0x200000006f60 = 0xffffff8e;
*(uint32_t*)0x200000006f64 = 6;
*(uint32_t*)0x200000006f68 = 1;
*(uint32_t*)0x200000006f6c = 9;
*(uint32_t*)0x200000006f70 = 0x200;
*(uint32_t*)0x200000006f74 = 0x57;
*(uint32_t*)0x200000006f78 = 5;
*(uint32_t*)0x200000006f7c = 5;
*(uint32_t*)0x200000006f80 = 0xf;
*(uint32_t*)0x200000006f84 = 0;
*(uint32_t*)0x200000006f88 = 1;
*(uint32_t*)0x200000006f8c = 0;
*(uint32_t*)0x200000006f90 = 0xb91;
*(uint32_t*)0x200000006f94 = 0xfffffffa;
*(uint32_t*)0x200000006f98 = 0xf6;
*(uint32_t*)0x200000006f9c = 0x10;
*(uint32_t*)0x200000006fa0 = 0xd;
*(uint32_t*)0x200000006fa4 = 3;
*(uint32_t*)0x200000006fa8 = 1;
*(uint32_t*)0x200000006fac = 5;
*(uint32_t*)0x200000006fb0 = 9;
*(uint32_t*)0x200000006fb4 = 4;
*(uint32_t*)0x200000006fb8 = 5;
*(uint32_t*)0x200000006fbc = 0xffffff44;
*(uint32_t*)0x200000006fc0 = 3;
*(uint32_t*)0x200000006fc4 = 4;
*(uint32_t*)0x200000006fc8 = 4;
*(uint32_t*)0x200000006fcc = 0x19d;
*(uint32_t*)0x200000006fd0 = 4;
*(uint32_t*)0x200000006fd4 = 1;
*(uint32_t*)0x200000006fd8 = 0x1e0;
*(uint32_t*)0x200000006fdc = 3;
*(uint32_t*)0x200000006fe0 = 3;
*(uint32_t*)0x200000006fe4 = 6;
*(uint32_t*)0x200000006fe8 = 9;
*(uint32_t*)0x200000006fec = 0x10001;
*(uint32_t*)0x200000006ff0 = 0xf1;
*(uint32_t*)0x200000006ff4 = 9;
*(uint32_t*)0x200000006ff8 = 5;
*(uint32_t*)0x200000006ffc = 3;
*(uint32_t*)0x200000007000 = 2;
*(uint32_t*)0x200000007004 = 7;
*(uint32_t*)0x200000007008 = 0xd0;
*(uint32_t*)0x20000000700c = 5;
*(uint32_t*)0x200000007010 = 2;
*(uint32_t*)0x200000007014 = 0xffff;
*(uint32_t*)0x200000007018 = 8;
*(uint32_t*)0x20000000701c = 5;
*(uint32_t*)0x200000007020 = 0x4b;
*(uint32_t*)0x200000007024 = 0x6168;
*(uint32_t*)0x200000007028 = 0xd;
*(uint32_t*)0x20000000702c = 0x1ff;
*(uint32_t*)0x200000007030 = 0x80000000;
*(uint32_t*)0x200000007034 = 0x10001;
*(uint32_t*)0x200000007038 = 9;
*(uint32_t*)0x20000000703c = 3;
*(uint32_t*)0x200000007040 = 0xff;
*(uint32_t*)0x200000007044 = 2;
*(uint32_t*)0x200000007048 = 0xc;
*(uint32_t*)0x20000000704c = 9;
*(uint32_t*)0x200000007050 = 0xd75;
*(uint32_t*)0x200000007054 = 5;
*(uint32_t*)0x200000007058 = 9;
*(uint32_t*)0x20000000705c = 3;
*(uint32_t*)0x200000007060 = 6;
*(uint32_t*)0x200000007064 = 1;
*(uint32_t*)0x200000007068 = 0xb1;
*(uint32_t*)0x20000000706c = 6;
*(uint32_t*)0x200000007070 = 3;
*(uint32_t*)0x200000007074 = 0xa7b;
*(uint32_t*)0x200000007078 = 7;
*(uint32_t*)0x20000000707c = 0;
*(uint32_t*)0x200000007080 = 6;
*(uint32_t*)0x200000007084 = 0xfffffff7;
*(uint32_t*)0x200000007088 = 6;
*(uint32_t*)0x20000000708c = 0;
*(uint32_t*)0x200000007090 = 0xfffffffd;
*(uint32_t*)0x200000007094 = 5;
*(uint32_t*)0x200000007098 = 0;
*(uint32_t*)0x20000000709c = 0x7f;
*(uint32_t*)0x2000000070a0 = 0xe;
*(uint32_t*)0x2000000070a4 = 8;
*(uint32_t*)0x2000000070a8 = 2;
*(uint32_t*)0x2000000070ac = 1;
*(uint32_t*)0x2000000070b0 = 8;
*(uint32_t*)0x2000000070b4 = 0xc1b;
*(uint32_t*)0x2000000070b8 = 0x401;
*(uint32_t*)0x2000000070bc = 7;
*(uint32_t*)0x2000000070c0 = 9;
*(uint32_t*)0x2000000070c4 = 0x5a;
*(uint32_t*)0x2000000070c8 = 0xffff;
*(uint32_t*)0x2000000070cc = 0x10000;
*(uint32_t*)0x2000000070d0 = 9;
*(uint32_t*)0x2000000070d4 = 8;
*(uint32_t*)0x2000000070d8 = 0x152f;
*(uint32_t*)0x2000000070dc = 0xfffffff4;
*(uint32_t*)0x2000000070e0 = 0xfff;
*(uint32_t*)0x2000000070e4 = 9;
*(uint32_t*)0x2000000070e8 = 6;
*(uint32_t*)0x2000000070ec = 5;
*(uint32_t*)0x2000000070f0 = 9;
*(uint32_t*)0x2000000070f4 = 0x1cf;
*(uint32_t*)0x2000000070f8 = 0x10000;
*(uint32_t*)0x2000000070fc = 6;
*(uint32_t*)0x200000007100 = 9;
*(uint32_t*)0x200000007104 = 0x4a87;
*(uint32_t*)0x200000007108 = 6;
*(uint32_t*)0x20000000710c = 6;
*(uint32_t*)0x200000007110 = 0xfffffff8;
*(uint32_t*)0x200000007114 = 5;
*(uint32_t*)0x200000007118 = 9;
*(uint32_t*)0x20000000711c = 7;
*(uint32_t*)0x200000007120 = 4;
*(uint32_t*)0x200000007124 = 0x3b452a9;
*(uint32_t*)0x200000007128 = 0xf;
*(uint32_t*)0x20000000712c = 0x1400000;
*(uint32_t*)0x200000007130 = 6;
*(uint32_t*)0x200000007134 = 5;
*(uint32_t*)0x200000007138 = 0x100;
*(uint32_t*)0x20000000713c = 6;
*(uint32_t*)0x200000007140 = 5;
*(uint32_t*)0x200000007144 = 0x40;
*(uint32_t*)0x200000007148 = 0x10;
*(uint32_t*)0x20000000714c = 0x3ff;
*(uint32_t*)0x200000007150 = 1;
*(uint32_t*)0x200000007154 = 3;
*(uint32_t*)0x200000007158 = 0xfffffffb;
*(uint32_t*)0x20000000715c = 4;
*(uint32_t*)0x200000007160 = 7;
*(uint32_t*)0x200000007164 = 0xa87;
*(uint32_t*)0x200000007168 = 7;
*(uint32_t*)0x20000000716c = 5;
*(uint32_t*)0x200000007170 = 0x3ff;
*(uint32_t*)0x200000007174 = 0x8000;
*(uint32_t*)0x200000007178 = 0x10000;
*(uint32_t*)0x20000000717c = 5;
*(uint32_t*)0x200000007180 = 5;
*(uint32_t*)0x200000007184 = 0xab2b;
*(uint32_t*)0x200000007188 = 2;
*(uint32_t*)0x20000000718c = 3;
*(uint32_t*)0x200000007190 = 7;
*(uint32_t*)0x200000007194 = 0x6ec6;
*(uint32_t*)0x200000007198 = 4;
*(uint32_t*)0x20000000719c = 8;
*(uint32_t*)0x2000000071a0 = 0xc9;
*(uint32_t*)0x2000000071a4 = 3;
*(uint32_t*)0x2000000071a8 = 0x723bdbde;
*(uint32_t*)0x2000000071ac = 0x757f157a;
*(uint32_t*)0x2000000071b0 = 9;
*(uint32_t*)0x2000000071b4 = 0x3ff;
*(uint32_t*)0x2000000071b8 = 2;
*(uint32_t*)0x2000000071bc = 9;
*(uint32_t*)0x2000000071c0 = 2;
*(uint32_t*)0x2000000071c4 = 9;
*(uint32_t*)0x2000000071c8 = 0x200;
*(uint32_t*)0x2000000071cc = 0x40;
*(uint32_t*)0x2000000071d0 = 0x69;
*(uint32_t*)0x2000000071d4 = 0;
*(uint32_t*)0x2000000071d8 = 0x84;
*(uint32_t*)0x2000000071dc = 9;
*(uint32_t*)0x2000000071e0 = 4;
*(uint32_t*)0x2000000071e4 = 5;
*(uint32_t*)0x2000000071e8 = 7;
*(uint32_t*)0x2000000071ec = 0x1000;
*(uint32_t*)0x2000000071f0 = 0x6f;
*(uint32_t*)0x2000000071f4 = 0xb;
*(uint32_t*)0x2000000071f8 = 0x5a4;
*(uint32_t*)0x2000000071fc = 5;
*(uint32_t*)0x200000007200 = 3;
*(uint32_t*)0x200000007204 = 6;
*(uint32_t*)0x200000007208 = 0x80000000;
*(uint32_t*)0x20000000720c = 0x7fff;
*(uint32_t*)0x200000007210 = 8;
*(uint32_t*)0x200000007214 = 4;
*(uint32_t*)0x200000007218 = 0xb;
*(uint32_t*)0x20000000721c = 0x7f;
*(uint32_t*)0x200000007220 = 0xe528;
*(uint32_t*)0x200000007224 = 2;
*(uint32_t*)0x200000007228 = 2;
*(uint32_t*)0x20000000722c = -1;
*(uint32_t*)0x200000007230 = 3;
*(uint32_t*)0x200000007234 = 0;
*(uint16_t*)0x200000007238 = 4;
*(uint16_t*)0x20000000723a = 6;
*(uint16_t*)0x20000000723c = 0xc;
*(uint16_t*)0x20000000723e = 7;
*(uint32_t*)0x200000007240 = 1;
*(uint32_t*)0x200000007244 = 0;
*(uint16_t*)0x200000007248 = 0xc;
*(uint16_t*)0x20000000724a = 8;
*(uint32_t*)0x20000000724c = 0;
*(uint32_t*)0x200000007250 = 2;
*(uint16_t*)0x200000007254 = 0x2c;
STORE_BY_BITMASK(uint16_t, , 0x200000007256, 1, 0, 14);
STORE_BY_BITMASK(uint16_t, , 0x200000007257, 0, 6, 1);
STORE_BY_BITMASK(uint16_t, , 0x200000007257, 0, 7, 1);
*(uint16_t*)0x200000007258 = 7;
*(uint16_t*)0x20000000725a = 1;
memcpy((void*)0x20000000725c, "ct\000", 3);
*(uint16_t*)0x200000007260 = 4;
STORE_BY_BITMASK(uint16_t, , 0x200000007262, 2, 0, 14);
STORE_BY_BITMASK(uint16_t, , 0x200000007263, 0, 6, 1);
STORE_BY_BITMASK(uint16_t, , 0x200000007263, 1, 7, 1);
*(uint16_t*)0x200000007264 = 4;
*(uint16_t*)0x200000007266 = 6;
*(uint16_t*)0x200000007268 = 0xc;
*(uint16_t*)0x20000000726a = 7;
*(uint32_t*)0x20000000726c = 1;
*(uint32_t*)0x200000007270 = 0;
*(uint16_t*)0x200000007274 = 0xc;
*(uint16_t*)0x200000007276 = 8;
*(uint32_t*)0x200000007278 = 2;
*(uint32_t*)0x20000000727c = 1;
*(uint16_t*)0x200000007280 = 0x30;
STORE_BY_BITMASK(uint16_t, , 0x200000007282, 1, 0, 14);
STORE_BY_BITMASK(uint16_t, , 0x200000007283, 0, 6, 1);
STORE_BY_BITMASK(uint16_t, , 0x200000007283, 0, 7, 1);
*(uint16_t*)0x200000007284 = 9;
*(uint16_t*)0x200000007286 = 1;
memcpy((void*)0x200000007288, "gact\000", 5);
*(uint16_t*)0x200000007290 = 4;
STORE_BY_BITMASK(uint16_t, , 0x200000007292, 2, 0, 14);
STORE_BY_BITMASK(uint16_t, , 0x200000007293, 0, 6, 1);
STORE_BY_BITMASK(uint16_t, , 0x200000007293, 1, 7, 1);
*(uint16_t*)0x200000007294 = 4;
*(uint16_t*)0x200000007296 = 6;
*(uint16_t*)0x200000007298 = 0xc;
*(uint16_t*)0x20000000729a = 7;
*(uint32_t*)0x20000000729c = 1;
*(uint32_t*)0x2000000072a0 = 0;
*(uint16_t*)0x2000000072a4 = 0xc;
*(uint16_t*)0x2000000072a6 = 8;
*(uint32_t*)0x2000000072a8 = 1;
*(uint32_t*)0x2000000072ac = 0;
*(uint64_t*)0x200000000148 = 0x1230;
*(uint64_t*)0x200000006058 = 1;
*(uint64_t*)0x200000006060 = 0;
*(uint64_t*)0x200000006068 = 0;
*(uint32_t*)0x200000006070 = 1;
syscall(__NR_sendmsg, /*fd=*/(intptr_t)-1, /*msg=*/0x200000006040ul, /*f=MSG_ZEROCOPY|MSG_BATCH|MSG_EOR|0x1000*/0x4041080ul);
// io_uring_enter arguments: [
// fd: fd_io_uring (resource)
// to_submit: int32 = 0x1203 (4 bytes)
// min_complete: int32 = 0x109c (4 bytes)
// flags: io_uring_enter_flags = 0x16 (8 bytes)
// sigmask: nil
// size: len = 0xffffffffffffff02 (8 bytes)
// ]
syscall(__NR_io_uring_enter, /*fd=*/r[0], /*to_submit=*/0x1203, /*min_complete=*/0x109c, /*flags=IORING_ENTER_REGISTERED_RING|IORING_ENTER_SQ_WAIT|IORING_ENTER_SQ_WAKEUP*/0x16ul, /*sigmask=*/0ul, /*size=*/0xffffffffffffff02ul);
return 0;
}
]
|
| 2/1 |
2026/06/12 21:59 |
action |
kernel-checkouter |
0m
Results: map[KernelSrc:/app/workdir/cache/src/0f08c49221a3b0088d8c68735c5e1edc423bb064]
|
| 3/1 |
2026/06/12 21:59 |
action |
kernel-builder |
11m
Results: map[KernelObj:/app/workdir/cache/build/eb4dde66330727b16e3c04fa2f7b3c20753ad05c]
|
| 4/1 |
2026/06/12 22:10 |
action |
codesearch-prepare |
9m
Results: map[Index:codesearch-index]
|
| 5/1 |
2026/06/12 22:20 |
agent |
expert |
28m
Model:
Results: map[DenialOfService:true Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:false RemoteTrigger:false Unprivileged:true UserNamespace:true VMGuestTrigger:false VMHostTrigger:false]
Instruction: You are an experienced Linux kernel security engineer. Your task is to analyze given kernel bug report
and determine its security impact based on the following dimensions.
Use the provided tools to examine the source code, check for capability checks (e.g., capable(), ns_capable()),
and understand the nature of the bug. Analyze the given kernel build and configuration.
You can check the kernel config by grepping ".config" file; you can check kernel cmdline by grepping
".config" file for "CONFIG_CMDLINE=". Assume sysctl parameters have default values.
But analyze for the corresponding production build w/o debugging tools enabled (like KASAN, KMSAN, UBSAN).
Try different strategies when analyzing the bug:
- think of ways in which the vulnerable code is unreachable
- or the other way around: try to come up with different ideas of how an unprivileged user can reach the bug
If still unsure err on the side of the bug being non-exploitable/not-accessible.
In the final reply, provide a reasoning for your assessment.
Analysis dimensions:
* Exploitable:
Determine if the bug can result in memory corruption or elevated privileges.
Memory safety issues are almost always exploitable (KASAN or UBSAN reports for use-after-free, out-of-bounds;
refcounting issues, corrupted lists, etc). When kernel is crashing on a completely wild pointer access
(e.g. user-space address, or non-canonical address, but not on NULL or address corresponding to KASAN shadow
for NULL address), including both data accesses and control transfers, that also usually implies possibility
of exploitation. Such reports usually say "unable to handle kernel paging request".
Uses of uninitialized values detected by KMSAN may be exploitable b/c attacker frequently can affect uninit
values with spraying techniques. However, for these exploitability depends on how exactly the uninit value
is used in the code, and what it affects.
Think of what happens after the bug is triggered. Some bugs cause kernel panic and halt execution,
they are harder to exploit. For example, BUG reports halts the kernel. However, WARNING reports don't halt
execution in production builds. Debug bug detection tools (like KASAN, KMSAN, KCSAN, UBSAN) are also not enabled
in production builds, so attacker can freely exploit these bugs w/o being detected by these tools.
If you see an integer overflow, think how the overflowed value used later (if it's used as allocation size,
or an array index). If you see an out-of-bounds read, think if it's followed by an out-of-bounds write as well.
Some KCSAN data-races may be exploitable by skilled attackers as well. Think what data structures got corrupted
as the result of data races and how. However, note that kernel has lots of "benign" data races that don't lead
to any runtime misbehavior at all.
* Denial Of Service:
Determine if the bug can result in denial-of-service. Most bugs can, since they cause system crash,
hangs, deadlocks, or resource leaks. This is mostly applicable to WARNING bugs that won't cause system crash
in production. For these think what will be consequences of the violation of the kernel assumptions flagged
by the WARNING. In some cases the unexpected condition is also properly handled by the normal control flow
(e.g. with "if (WARN_ON(...))"), these won't cause denial-of-service. If the condition is not handled,
then it may or may not cause denial-of-service.
* Accessible From Unprivileged Processes:
Determine if the bug can be reached from a typical (non-root) user process that does NOT have any special capabilities
(like CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_NET_RAW, CAP_PERFMON) or access to device nodes restricted to root.
Assume that unprivileged_bpf_disabled=1, that is eBPF loading is not accessible. However, cBPF (classical BPF)
is still accessible to non-root processes.
Assume that user namespaces are not accessible, that is, the process cannot get the mentioned capabilities even
within a new user namespace (checked by ns_capable() function in the kernel sources).
* Accessible From User Namespaces:
Determine if the bug can be reached within a user-namespace where the process has all capabilities
(including CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_NET_RAW, CAP_PERFMON). Such capabilities are checked with ns_capable()
function in the kernel sources.
* VM Guest Trigger:
Determine if the bug can be triggered from the context of a typical KVM guest (e.g., set up by a QEMU VMM).
Consider accesses to standard Linux host paravirtualized features (virtio-blk, virtio-net, etc.),
and handling of VM exits in the KVM code.
* VM Host Trigger in The Confidential Computing Context:
Determine if the bug can be triggered in a confidential computing guest kernel from the context of a KVM host.
Consider access to standard Linux guest paravirtualized features (virtio-blk, virtio-net, etc.).
* Ethernet Network Trigger:
Determine if the bug can be triggered by processing ingress network Ethernet traffic, either directly (network stack)
or via drivers exposed to network data.
* Other Remote Trigger:
Determine if the bug can be triggered by processing remote traffic other than Ethernet (Wifi, Bluetooth, NFC, etc).
* Peripheral Trigger:
Determine if the bug can be triggered via an untrusted peripheral device that can be physically plugged
into a system, such as a USB device or a niche hardware driver handling external hardware inputs.
This is particularly important for mobile and desktop environments where users can plug in unknown devices.
* Malicious Filesystem Trigger:
Determine if the bug can be triggered by the kernel mounting and parsing a malicious filesystem image.
This is highly critical for Desktop and Mobile environments where external media or downloaded images
might be auto-mounted.
Don't make assumptions about the kernel source code (it may be different from what you assume it is).
Extensively use the provided code access tools (codesearch-*, git-*, grepper, etc)
to examine the actual source code, and confirm any assumptions.
Prefer calling several tools at the same time to save round-trips.
Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.
Prompt:
The kernel bug report is:
BUG: memory leak
unreferenced object 0xffff88810ac98000 (size 176):
comm "syz.0.19", pid 5920, jiffies 4294944647
hex dump (first 32 bytes):
00 00 00 00 1b 00 0e 04 60 7e a7 85 ff ff ff ff ........`~......
70 15 3e 06 81 88 ff ff 80 61 3c 2b 81 88 ff ff p.>......a<+....
backtrace (crc df7849cb):
kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4575 [inline]
slab_alloc_node mm/slub.c:4899 [inline]
kmem_cache_alloc_noprof+0x36c/0x480 mm/slub.c:4906
alloc_empty_file+0x57/0x180 fs/file_table.c:262
path_openat+0x44/0x1e20 fs/namei.c:4844
do_file_open+0x121/0x200 fs/namei.c:4887
do_sys_openat2+0xa5/0x140 fs/open.c:1364
do_sys_open fs/open.c:1370 [inline]
__do_sys_openat fs/open.c:1386 [inline]
__se_sys_openat fs/open.c:1381 [inline]
__x64_sys_openat+0x82/0xf0 fs/open.c:1381
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xf8/0x610 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
connection error: failed to recv *flatrpc.ExecutorMessageRawT: EOF
It is reproducible with the followint program.
Keep in mind that it may lack the precise threading, sandboxing, and some arguments of a working reproducer.
But it should give an idea of the involved syscalls.
// autogenerated by syzkaller (https://github.com/google/syzkaller)
#define _GNU_SOURCE
#include <endian.h>
#include <fcntl.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mount.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>
#ifndef __NR_io_uring_enter
#define __NR_io_uring_enter 426
#endif
#ifndef __NR_io_uring_setup
#define __NR_io_uring_setup 425
#endif
#define BITMASK(bf_off,bf_len) (((1ull << (bf_len)) - 1) << (bf_off))
#define STORE_BY_BITMASK(type,htobe,addr,val,bf_off,bf_len) *(type*)(addr) = htobe((htobe(*(type*)(addr)) & ~BITMASK((bf_off), (bf_len))) | (((type)(val) << (bf_off)) & BITMASK((bf_off), (bf_len))))
static long syz_open_dev(volatile long a0, volatile long a1, volatile long a2)
{
if (a0 == 0xc || a0 == 0xb) {
char buf[128];
sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block", (uint8_t)a1, (uint8_t)a2);
return open(buf, O_RDWR, 0);
} else {
unsigned long nb = a1;
char buf[1024];
char* hash;
strncpy(buf, (char*)a0, sizeof(buf) - 1);
buf[sizeof(buf) - 1] = 0;
while ((hash = strchr(buf, '#'))) {
*hash = '0' + (char)(nb % 10);
nb /= 10;
}
return open(buf, a2 & ~O_CREAT, 0);
}
}
uint64_t r[1] = {0xffffffffffffffff};
int main(void)
{
syscall(__NR_mmap, /*addr=*/0x1ffffffff000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
syscall(__NR_mmap, /*addr=*/0x200000000000ul, /*len=*/0x1000000ul, /*prot=PROT_WRITE|PROT_READ|PROT_EXEC*/7ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
syscall(__NR_mmap, /*addr=*/0x200001000000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
const char* reason;
(void)reason;
intptr_t res = 0;
if (write(1, "executing program\n", sizeof("executing program\n") - 1)) {}
// socket$nl_generic arguments: [
// domain: const = 0x10 (8 bytes)
// type: const = 0x3 (8 bytes)
// proto: const = 0x10 (4 bytes)
// ]
// returns sock_nl_generic
syscall(__NR_socket, /*domain=*/0x10ul, /*type=*/3ul, /*proto=*/0x10);
// socket arguments: [
// domain: socket_domain = 0x2 (8 bytes)
// type: socket_type = 0x3 (8 bytes)
// proto: int32 = 0x67 (4 bytes)
// ]
// returns sock
syscall(__NR_socket, /*domain=AF_INET*/2ul, /*type=SOCK_RAW*/3ul, /*proto=*/0x67);
// prctl$PR_SET_MM_MAP arguments: [
// option: const = 0x23 (8 bytes)
// opt: const = 0xe (8 bytes)
// arg: ptr[in, prctl_mm_map] {
// prctl_mm_map {
// start_code: VMA[0x1000]
// end_code: VMA[0xf000]
// start_data: VMA[0x2000]
// end_data: VMA[0x3000]
// start_brk: VMA[0x4000]
// brk: VMA[0x3000]
// start_stack: VMA[0x3000]
// arg_start: VMA[0x3000]
// arg_end: VMA[0x1000]
// env_start: VMA[0x3000]
// env_end: VMA[0x2000]
// auxv: nil
// auxv_size: bytesize = 0x0 (4 bytes)
// exe_fd: fd (resource)
// }
// }
// len: bytesize = 0x68 (8 bytes)
// ]
*(uint64_t*)0x200000000080 = 0x200000ff7000;
*(uint64_t*)0x200000000088 = 0x200000ff1000;
*(uint64_t*)0x200000000090 = 0x200000ff1000;
*(uint64_t*)0x200000000098 = 0x200000ff5000;
*(uint64_t*)0x2000000000a0 = 0x200000ff8000;
*(uint64_t*)0x2000000000a8 = 0x200000ff8000;
*(uint64_t*)0x2000000000b0 = 0x200000ffd000;
*(uint64_t*)0x2000000000b8 = 0x200000ffb000;
*(uint64_t*)0x2000000000c0 = 0x200000ff5000;
*(uint64_t*)0x2000000000c8 = 0x200000ff3000;
*(uint64_t*)0x2000000000d0 = 0x200000ffa000;
*(uint64_t*)0x2000000000d8 = 0;
*(uint32_t*)0x2000000000e0 = 0;
*(uint32_t*)0x2000000000e4 = -1;
syscall(__NR_prctl, /*option=*/0x23ul, /*opt=*/0xeul, /*arg=*/0x200000000080ul, /*len=*/0x68ul, 0);
// sendmsg$NFT_BATCH arguments: [
// fd: sock_nl_netfilter (resource)
// msg: ptr[in, msghdr_netlink[nft_batch_msg]] {
// msghdr_netlink[nft_batch_msg] {
// addr: nil
// addrlen: len = 0x0 (4 bytes)
// pad = 0x0 (4 bytes)
// vec: nil
// vlen: const = 0x1 (8 bytes)
// ctrl: const = 0x0 (8 bytes)
// ctrllen: const = 0x0 (8 bytes)
// f: send_flags = 0x0 (4 bytes)
// pad = 0x0 (4 bytes)
// }
// }
// f: send_flags = 0x24004045 (8 bytes)
// ]
*(uint64_t*)0x200000000080 = 0;
*(uint32_t*)0x200000000088 = 0;
*(uint64_t*)0x200000000090 = 0;
*(uint64_t*)0x200000000098 = 1;
*(uint64_t*)0x2000000000a0 = 0;
*(uint64_t*)0x2000000000a8 = 0;
*(uint32_t*)0x2000000000b0 = 0;
syscall(__NR_sendmsg, /*fd=*/(intptr_t)-1, /*msg=*/0x200000000080ul, /*f=MSG_ZEROCOPY|MSG_FASTOPEN|MSG_OOB|MSG_NOSIGNAL|MSG_DONTWAIT|MSG_DONTROUTE*/0x24004045ul);
// io_uring_setup arguments: [
// entries: int32 = 0x523 (4 bytes)
// params: ptr[inout, io_uring_params] {
// io_uring_params {
// sq_entries: int32 = 0x0 (4 bytes)
// cq_entries: int32 = 0x3cb1 (4 bytes)
// flags: io_uring_setup_flags = 0x1c080 (4 bytes)
// sq_thread_cpu: int32 = 0xa (4 bytes)
// sq_thread_idle: int32 = 0x20002f7 (4 bytes)
// features: int32 = 0x0 (4 bytes)
// wq_fd: fd_io_uring (resource)
// resv: buffer: {00 00 00 00 00 00 00 00 00 00 00 00} (length 0xc)
// sq_off: io_sqring_offsets {
// head: int32 = 0x0 (4 bytes)
// tail: int32 = 0x0 (4 bytes)
// ring_mask: int32 = 0x0 (4 bytes)
// ring_entries: int32 = 0x0 (4 bytes)
// flags: int32 = 0x0 (4 bytes)
// dropped: int32 = 0x0 (4 bytes)
// array: int32 = 0x0 (4 bytes)
// resv1: int32 = 0x0 (4 bytes)
// user_addr: int64 = 0x0 (8 bytes)
// }
// cq_off: io_cqring_offsets {
// head: int32 = 0x0 (4 bytes)
// tail: int32 = 0x0 (4 bytes)
// ring_mask: int32 = 0x0 (4 bytes)
// ring_entries: int32 = 0x0 (4 bytes)
// overflow: int32 = 0x0 (4 bytes)
// cqes: int32 = 0x0 (4 bytes)
// flags: int32 = 0x0 (4 bytes)
// resv1: int32 = 0x0 (4 bytes)
// user_addr: int64 = 0x0 (8 bytes)
// }
// }
// }
// ]
// returns fd_io_uring
*(uint32_t*)0x200000000044 = 0x3cb1;
*(uint32_t*)0x200000000048 = 0x1c080;
*(uint32_t*)0x20000000004c = 0xa;
*(uint32_t*)0x200000000050 = 0x20002f7;
*(uint32_t*)0x200000000058 = -1;
memset((void*)0x20000000005c, 0, 12);
res = syscall(__NR_io_uring_setup, /*entries=*/0x523, /*params=*/0x200000000040ul);
if (res != -1)
r[0] = res;
// syz_open_dev$vbi arguments: [
// dev: ptr[in, buffer] {
// buffer: {2f 64 65 76 2f 76 62 69 23 00} (length 0xa)
// }
// id: proc = 0x3 (8 bytes)
// flags: const = 0x2 (8 bytes)
// ]
// returns fd_video
memcpy((void*)0x200000000000, "/dev/vbi#\000", 10);
syz_open_dev(/*dev=*/0x200000000000, /*id=*/3, /*flags=*/2);
// sendmsg$nl_route_sched arguments: [
// fd: sock_nl_route (resource)
// msg: ptr[in, msghdr_netlink[netlink_msg_route_sched]] {
// msghdr_netlink[netlink_msg_route_sched] {
// addr: nil
// addrlen: len = 0x0 (4 bytes)
// pad = 0x0 (4 bytes)
// vec: ptr[in, iovec[in, netlink_msg_route_sched]] {
// iovec[in, netlink_msg_route_sched] {
// addr: ptr[in, netlink_msg_route_sched] {
// union netlink_msg_route_sched {
// newtfilter: netlink_msg_t[const[RTM_NEWTFILTER, int16], tcmsg[AF_UNSPEC], filter_policy] {
// len: len = 0x1230 (4 bytes)
// type: const = 0x2c (2 bytes)
// flags: netlink_msg_flags = 0x4 (2 bytes)
// seq: int32 = 0x70bd2d (4 bytes)
// pid: int32 = 0x25dfdbfd (4 bytes)
// payload: tcmsg[AF_UNSPEC] {
// family: const = 0x0 (1 bytes)
// tcm__pad1: const = 0x0 (1 bytes)
// tcm__pad2: const = 0x0 (2 bytes)
// ifindex: ifindex (resource)
// tcm_handle: tcm_handle {
// minor: tcm_handle_offsets = 0x4 (2 bytes)
// major: tcm_handle_offsets = 0xe (2 bytes)
// }
// tcm_parent: tcm_handle {
// minor: tcm_handle_offsets = 0xffe4 (2 bytes)
// major: tcm_handle_offsets = 0xffe0 (2 bytes)
// }
// tcm_info: tcm_handle {
// minor: tcm_handle_offsets = 0xe (2 bytes)
// major: tcm_handle_offsets = 0x5 (2 bytes)
// }
// }
// attrs: array[filter_policy] {
// union filter_policy {
// TCA_RATE: nlattr_t[const[TCA_RATE, int16], tc_estimator] {
// nla_len: offsetof = 0x6 (2 bytes)
// nla_type: const = 0x5 (2 bytes)
// payload: tc_estimator {
// interval: int8 = 0x8f (1 bytes)
// ewma_log: int8 = 0x0 (1 bytes)
// }
// size: buffer: {} (length 0x0)
// pad = 0x0 (2 bytes)
// }
// }
// union filter_policy {
// filter_kind_options: union filter_kind_options {
// f_basic: tca_kind_options_t["basic", array[basic_policy]] {
// TCA_KIND: nlattr_t[const[TCA_KIND, int16], string["basic"]] {
// nla_len: offsetof = 0xa (2 bytes)
// nla_type: const = 0x1 (2 bytes)
// payload: buffer: {62 61 73 69 63 00} (length 0x6)
// size: buffer: {} (length 0x0)
// pad = 0x0 (2 bytes)
// }
// TCA_OPTIONS: nlattr_t[const[TCA_OPTIONS, int16], array[basic_policy]] {
// nla_len: offsetof = 0x11f8 (2 bytes)
// nla_type: const = 0x2 (2 bytes)
// payload: array[basic_policy] {
// union basic_policy {
// TCA_BASIC_ACT: nlattr_t[const[TCA_BASIC_ACT, int16], array[tca_actions]] {
// nla_len: offsetof = 0x128 (2 bytes)
// nla_type: const = 0x3 (2 bytes)
// payload: array[tca_actions] {
// union tca_actions {
// m_pedit: nlattr_tt[int16:14[0:TCA_ACT_MAX_PRIO], 0, 0, tcf_action_policy["pedit", pedit_policy]] {
// nla_len: offsetof = 0x124 (2 bytes)
// nla_type: int16 = 0xa (1 bytes)
// NLA_F_NET_BYTEORDER: const = 0x0 (0 bytes)
// NLA_F_NESTED: const = 0x0 (1 bytes)
// payload: tcf_action_policy["pedit", pedit_policy] {
// TCA_ACT_KIND: nlattr_t[const[TCA_ACT_KIND, int16], string["pedit"]] {
// nla_len: offsetof = 0xa (2 bytes)
// nla_type: const = 0x1 (2 bytes)
// payload: buffer: {70 65 64 69 74 00} (length 0x6)
// size: buffer: {} (length 0x0)
// pad = 0x0 (2 bytes)
// }
// TCA_ACT_OPTIONS: nlattr_tt[const[TCA_ACT_OPTIONS, int16:14], 0, 1, array[pedit_policy]] {
// nla_len: offsetof = 0x4 (2 bytes)
// nla_type: const = 0x2 (1 bytes)
// NLA_F_NET_BYTEORDER: const = 0x0 (0 bytes)
// NLA_F_NESTED: const = 0x1 (1 bytes)
// payload: array[pedit_policy] {
// }
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_COOKIE: nlattr_t[const[TCA_ACT_COOKIE, int16], array[int8]] {
// nla_len: offsetof = 0xf5 (2 bytes)
// nla_type: const = 0x6 (2 bytes)
// payload: buffer: {c4 1d 0b 25 b0 62 85 aa 07 97 b1 9a 7c 9f 5d f9 d2 80 a5 44 e3 41 cd 7f a8 57 a7 da 8b 8a c0 b1 b1 66 91 93 66 3e 1c e0 3b fe 2e 5c ae fa 26 e8 20 95 04 0c ab 3d 89 24 06 19 70 87 cb 53 98 4c ec ab 77 79 7a f8 08 4a 9c 30 54 5d 5d fd f8 48 b1 43 61 85 be 3c fa 66 13 ce 55 8d 16 3f 4b f7 27 7d d1 00 ba df 44 8b 3f 59 ee 61 f1 fe 34 2a 2c da 8c 22 e0 7d c7 39 ce 51 19 e0 d7 12 fe c2 98 b5 eb 1f 7b a6 6a 68 d8 35 42 26 56 b0 ff c9 a1 9d eb 53 33 d8 4a 7d d0 5e 0a c4 d5 ed 45 8b a6 15 90 f7 cd 2e a7 65 b2 6e ae 8d 45 80 58 96 b4 d0 3e d9 5d a8 04 fc 92 d1 b4 5e 41 f7 49 20 ea 4d 50 aa c5 ed 89 8d 4e 1c 43 a0 dc 80 db 3c 0a ab 1e 59 06 47 3c 15 ba 6e b6 57 6b fb 1a 0e da 96 1d 15 0c ef e1 2b 70 7e bf ec 98 a5 86 f4 db} (length 0xf1)
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_FLAGS: nlattr_t[const[TCA_ACT_FLAGS, int16], nla_bitfield32[tcf_action_policy_flags]] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x7 (2 bytes)
// payload: nla_bitfield32[tcf_action_policy_flags] {
// value: tcf_action_policy_flags = 0x0 (4 bytes)
// selector: tcf_action_policy_flags = 0x0 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_HW_STATS: nlattr_t[const[TCA_ACT_HW_STATS, int16], nla_bitfield32[tcf_action_policy_hw_stats]] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x8 (2 bytes)
// payload: nla_bitfield32[tcf_action_policy_hw_stats] {
// value: tcf_action_policy_hw_stats = 0x2 (4 bytes)
// selector: tcf_action_policy_hw_stats = 0x3 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// size: buffer: {} (length 0x0)
// }
// }
// }
// size: buffer: {} (length 0x0)
// }
// }
// union basic_policy {
// TCA_BASIC_CLASSID: nlattr_t[const[TCA_BASIC_CLASSID, int16], tcm_handle] {
// nla_len: offsetof = 0x8 (2 bytes)
// nla_type: const = 0x1 (2 bytes)
// payload: tcm_handle {
// minor: tcm_handle_offsets = 0xe (2 bytes)
// major: tcm_handle_offsets = 0xe (2 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// union basic_policy {
// TCA_BASIC_CLASSID: nlattr_t[const[TCA_BASIC_CLASSID, int16], tcm_handle] {
// nla_len: offsetof = 0x8 (2 bytes)
// nla_type: const = 0x1 (2 bytes)
// payload: tcm_handle {
// minor: tcm_handle_offsets = 0x10 (2 bytes)
// major: tcm_handle_offsets = 0x6 (2 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// union basic_policy {
// TCA_BASIC_CLASSID: nlattr_t[const[TCA_BASIC_CLASSID, int16], tcm_handle] {
// nla_len: offsetof = 0x8 (2 bytes)
// nla_type: const = 0x1 (2 bytes)
// payload: tcm_handle {
// minor: tcm_handle_offsets = 0x8 (2 bytes)
// major: tcm_handle_offsets = 0xfff2 (2 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// union basic_policy {
// TCA_BASIC_ACT: nlattr_t[const[TCA_BASIC_ACT, int16], array[tca_actions]] {
// nla_len: offsetof = 0x10b4 (2 bytes)
// nla_type: const = 0x3 (2 bytes)
// payload: array[tca_actions] {
// union tca_actions {
// m_police: nlattr_tt[int16:14[0:TCA_ACT_MAX_PRIO], 0, 0, tcf_action_policy["police", array[police_policy]]] {
// nla_len: offsetof = 0x1054 (2 bytes)
// nla_type: int16 = 0x16 (1 bytes)
// NLA_F_NET_BYTEORDER: const = 0x0 (0 bytes)
// NLA_F_NESTED: const = 0x0 (1 bytes)
// payload: tcf_action_policy["police", array[police_policy]] {
// TCA_ACT_KIND: nlattr_t[const[TCA_ACT_KIND, int16], string["police"]] {
// nla_len: offsetof = 0xb (2 bytes)
// nla_type: const = 0x1 (2 bytes)
// payload: buffer: {70 6f 6c 69 63 65 00} (length 0x7)
// size: buffer: {} (length 0x0)
// pad = 0x0 (1 bytes)
// }
// TCA_ACT_OPTIONS: nlattr_tt[const[TCA_ACT_OPTIONS, int16:14], 0, 1, array[array[police_policy]]] {
// nla_len: offsetof = 0x1028 (2 bytes)
// nla_type: const = 0x2 (1 bytes)
// NLA_F_NET_BYTEORDER: const = 0x0 (0 bytes)
// NLA_F_NESTED: const = 0x1 (1 bytes)
// payload: array[array[police_policy]] {
// array[police_policy] {
// union police_policy {
// TCA_POLICE_PEAKRATE: nlattr_t[const[TCA_POLICE_PEAKRATE, int16], array[int32, 256]] {
// nla_len: offsetof = 0x404 (2 bytes)
// nla_type: const = 0x3 (2 bytes)
// payload: array[int32] {
// int32 = 0x81 (4 bytes)
// int32 = 0x1ff (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x80000001 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xfffffffa (4 bytes)
// int32 = 0x5f7 (4 bytes)
// int32 = 0xbebc (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x798a (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xe08c (4 bytes)
// int32 = 0x3964 (4 bytes)
// int32 = 0xf3 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x102 (4 bytes)
// int32 = 0xbff (4 bytes)
// int32 = 0x838 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x80000000 (4 bytes)
// int32 = 0x7fffffff (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xad6c (4 bytes)
// int32 = 0xa6f4 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x9f9 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x7fff (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xaf75 (4 bytes)
// int32 = 0xfffff179 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x89 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x10001 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x87 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x7ca (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x10001 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xdfbd (4 bytes)
// int32 = 0x6d1b (4 bytes)
// int32 = 0xf4dc (4 bytes)
// int32 = 0xf8000000 (4 bytes)
// int32 = 0xbfb (4 bytes)
// int32 = 0x200 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xfffffff7 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x80 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4d (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x7ff (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0x401 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x1000 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x80 (4 bytes)
// int32 = 0x1ff (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xc1 (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x38 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0xffffff80 (4 bytes)
// int32 = 0x9df (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x1ff (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x200 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x2ee9 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x80 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x80 (4 bytes)
// int32 = 0x2ecc8490 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xa7 (4 bytes)
// int32 = 0x24d (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x18 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xd85 (4 bytes)
// int32 = 0xd4 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xc64a (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xabd (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xdd7 (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x80 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xe (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xc (4 bytes)
// int32 = 0xa4 (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0x24 (4 bytes)
// int32 = 0xa9a (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x2ba (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x854 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xe7 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x80000000 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x86 (4 bytes)
// int32 = 0x81 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x800 (4 bytes)
// int32 = 0xfffffffd (4 bytes)
// int32 = 0x9c1 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0xfffffffc (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xc (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xd (4 bytes)
// int32 = 0xb (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// union police_policy {
// TCA_POLICE_RATE64: nlattr_t[const[TCA_POLICE_RATE64, int16], int64] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x8 (2 bytes)
// payload: int64 = 0x5 (8 bytes)
// size: buffer: {} (length 0x0)
// }
// }
// union police_policy {
// TCA_POLICE_PEAKRATE: nlattr_t[const[TCA_POLICE_PEAKRATE, int16], array[int32, 256]] {
// nla_len: offsetof = 0x404 (2 bytes)
// nla_type: const = 0x3 (2 bytes)
// payload: array[int32] {
// int32 = 0x3 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xc6c (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x7ff (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x1000000 (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0x9f4f5d67 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x7ff (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x32 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x30000000 (4 bytes)
// int32 = 0xdd (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x400 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x101 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xd (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x39c0 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x94b (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x777 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x800 (4 bytes)
// int32 = 0x1000 (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0x9e (4 bytes)
// int32 = 0xcc (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xffffff37 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x7ff (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xfffffffc (4 bytes)
// int32 = 0x101 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xf3 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x7a36 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x40 (4 bytes)
// int32 = 0xd10 (4 bytes)
// int32 = 0x455e (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x40000 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x18bc169 (4 bytes)
// int32 = 0x10 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xb66 (4 bytes)
// int32 = 0x100 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x3d (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x81 (4 bytes)
// int32 = 0x81 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xc (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x7fffffff (4 bytes)
// int32 = 0x52acd031 (4 bytes)
// int32 = 0xf938 (4 bytes)
// int32 = 0xc8 (4 bytes)
// int32 = 0x1b (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x80000001 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x41 (4 bytes)
// int32 = 0x401 (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x100007 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0xd17 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x400 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x80000000 (4 bytes)
// int32 = 0x400 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0xfffffffd (4 bytes)
// int32 = 0xc6 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x25 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x400 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x81 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x200000a (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0xd (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x83 (4 bytes)
// int32 = 0x1ff (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0x87 (4 bytes)
// int32 = 0x800 (4 bytes)
// int32 = 0xdba (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xe1d (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xfffffffa (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x9ca (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xc (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xfffffb9b (4 bytes)
// int32 = 0xd (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x800 (4 bytes)
// int32 = 0xfffffff7 (4 bytes)
// int32 = 0x7ff (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x80000001 (4 bytes)
// int32 = 0xc9 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xe47 (4 bytes)
// int32 = 0x1ff (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x49 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xfffffa1f (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x18000 (4 bytes)
// int32 = 0x4d0 (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x5cd (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// union police_policy {
// TCA_POLICE_AVRATE: nlattr_t[const[TCA_POLICE_AVRATE, int16], int32] {
// nla_len: offsetof = 0x8 (2 bytes)
// nla_type: const = 0x4 (2 bytes)
// payload: int32 = 0x80 (4 bytes)
// size: buffer: {} (length 0x0)
// }
// }
// }
// array[police_policy] {
// union police_policy {
// TCA_POLICE_RATE: nlattr_t[const[TCA_POLICE_RATE, int16], array[int32, 256]] {
// nla_len: offsetof = 0x404 (2 bytes)
// nla_type: const = 0x2 (2 bytes)
// payload: array[int32] {
// int32 = 0x6 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x80000000 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x200 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x7fffffff (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x101 (4 bytes)
// int32 = 0xffffff51 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x401 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xd5c6 (4 bytes)
// int32 = 0x400 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x9c3 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xfffffffa (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xd9 (4 bytes)
// int32 = 0xef (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0xffff (4 bytes)
// int32 = 0xfffffffb (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0xfffffffd (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xffff (4 bytes)
// int32 = 0x800 (4 bytes)
// int32 = 0xfffffff8 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x67 (4 bytes)
// int32 = 0xfd0 (4 bytes)
// int32 = 0xffffffbe (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x101 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xffff (4 bytes)
// int32 = 0xfffffff7 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xa2 (4 bytes)
// int32 = 0x1336df01 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x81 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x40 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x80000001 (4 bytes)
// int32 = 0xc0d7 (4 bytes)
// int32 = 0xf9 (4 bytes)
// int32 = 0x59 (4 bytes)
// int32 = 0x1000 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x400 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0xff6d (4 bytes)
// int32 = 0x1ff (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0x90000 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x8cca (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xaa (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x40 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xfffffff5 (4 bytes)
// int32 = 0x95c (4 bytes)
// int32 = 0xf6 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x7fffffff (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x1000 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xffff7fff (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x71 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xb4 (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x7791070f (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4eb8 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xe2 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xffffff01 (4 bytes)
// int32 = 0xfffffffe (4 bytes)
// int32 = 0xc (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x40 (4 bytes)
// int32 = 0x400 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x38 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xb25 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x73c0 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x9000000 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x57b (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0x3fb2 (4 bytes)
// int32 = 0xce (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0xb315 (4 bytes)
// int32 = 0xfffffff2 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0xfffffff8 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0xfffffffd (4 bytes)
// int32 = 0x100 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x101 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x100 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xffff8000 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x1000 (4 bytes)
// int32 = 0x7282 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x8c (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xe (4 bytes)
// int32 = 0x81 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x1c (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x81 (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0xbc (4 bytes)
// int32 = 0x1ff (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x1000 (4 bytes)
// int32 = 0x9 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// union police_policy {
// TCA_POLICE_PEAKRATE: nlattr_t[const[TCA_POLICE_PEAKRATE, int16], array[int32, 256]] {
// nla_len: offsetof = 0x404 (2 bytes)
// nla_type: const = 0x3 (2 bytes)
// payload: array[int32] {
// int32 = 0x8cf (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x59c (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xfffffffc (4 bytes)
// int32 = 0x5f2c (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x100 (4 bytes)
// int32 = 0x35b (4 bytes)
// int32 = 0xbe (4 bytes)
// int32 = 0x7d (4 bytes)
// int32 = 0xab99 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x101 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xf76 (4 bytes)
// int32 = 0x8001 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0xd (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xab45 (4 bytes)
// int32 = 0x8244 (4 bytes)
// int32 = 0x60000 (4 bytes)
// int32 = 0xe2a (4 bytes)
// int32 = 0xae8 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x20076355 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x10 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xa (4 bytes)
// int32 = 0xd (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x7ff (4 bytes)
// int32 = 0x200 (4 bytes)
// int32 = 0xcb (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x80 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x45e (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x1f (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x80000001 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x800 (4 bytes)
// int32 = 0xfffffffc (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x81 (4 bytes)
// int32 = 0x6e3833b8 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x5520 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xe1 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xffffff8e (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x200 (4 bytes)
// int32 = 0x57 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xb91 (4 bytes)
// int32 = 0xfffffffa (4 bytes)
// int32 = 0xf6 (4 bytes)
// int32 = 0x10 (4 bytes)
// int32 = 0xd (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xffffff44 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x19d (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x1e0 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x10001 (4 bytes)
// int32 = 0xf1 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xd0 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0xffff (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x4b (4 bytes)
// int32 = 0x6168 (4 bytes)
// int32 = 0xd (4 bytes)
// int32 = 0x1ff (4 bytes)
// int32 = 0x80000000 (4 bytes)
// int32 = 0x10001 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xff (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0xc (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0xd75 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0xb1 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xa7b (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xfffffff7 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0xfffffffd (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0xe (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xc1b (4 bytes)
// int32 = 0x401 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x5a (4 bytes)
// int32 = 0xffff (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x152f (4 bytes)
// int32 = 0xfffffff4 (4 bytes)
// int32 = 0xfff (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x1cf (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4a87 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0xfffffff8 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x3b452a9 (4 bytes)
// int32 = 0xf (4 bytes)
// int32 = 0x1400000 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x100 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x40 (4 bytes)
// int32 = 0x10 (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x1 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0xfffffffb (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0xa87 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x8000 (4 bytes)
// int32 = 0x10000 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0xab2b (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x6ec6 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0xc9 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x723bdbde (4 bytes)
// int32 = 0x757f157a (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x3ff (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x200 (4 bytes)
// int32 = 0x40 (4 bytes)
// int32 = 0x69 (4 bytes)
// int32 = 0x0 (4 bytes)
// int32 = 0x84 (4 bytes)
// int32 = 0x9 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x7 (4 bytes)
// int32 = 0x1000 (4 bytes)
// int32 = 0x6f (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x5a4 (4 bytes)
// int32 = 0x5 (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x6 (4 bytes)
// int32 = 0x80000000 (4 bytes)
// int32 = 0x7fff (4 bytes)
// int32 = 0x8 (4 bytes)
// int32 = 0x4 (4 bytes)
// int32 = 0xb (4 bytes)
// int32 = 0x7f (4 bytes)
// int32 = 0xe528 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0x2 (4 bytes)
// int32 = 0xffffffff (4 bytes)
// int32 = 0x3 (4 bytes)
// int32 = 0x0 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// }
// }
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_COOKIE: nlattr_t[const[TCA_ACT_COOKIE, int16], array[int8]] {
// nla_len: offsetof = 0x4 (2 bytes)
// nla_type: const = 0x6 (2 bytes)
// payload: buffer: {} (length 0x0)
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_FLAGS: nlattr_t[const[TCA_ACT_FLAGS, int16], nla_bitfield32[tcf_action_policy_flags]] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x7 (2 bytes)
// payload: nla_bitfield32[tcf_action_policy_flags] {
// value: tcf_action_policy_flags = 0x1 (4 bytes)
// selector: tcf_action_policy_flags = 0x0 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_HW_STATS: nlattr_t[const[TCA_ACT_HW_STATS, int16], nla_bitfield32[tcf_action_policy_hw_stats]] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x8 (2 bytes)
// payload: nla_bitfield32[tcf_action_policy_hw_stats] {
// value: tcf_action_policy_hw_stats = 0x0 (4 bytes)
// selector: tcf_action_policy_hw_stats = 0x2 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// size: buffer: {} (length 0x0)
// }
// }
// union tca_actions {
// m_ct: nlattr_tt[int16:14[0:TCA_ACT_MAX_PRIO], 0, 0, tcf_action_policy["ct", ct_policy]] {
// nla_len: offsetof = 0x2c (2 bytes)
// nla_type: int16 = 0x1 (1 bytes)
// NLA_F_NET_BYTEORDER: const = 0x0 (0 bytes)
// NLA_F_NESTED: const = 0x0 (1 bytes)
// payload: tcf_action_policy["ct", ct_policy] {
// TCA_ACT_KIND: nlattr_t[const[TCA_ACT_KIND, int16], string["ct"]] {
// nla_len: offsetof = 0x7 (2 bytes)
// nla_type: const = 0x1 (2 bytes)
// payload: buffer: {63 74 00} (length 0x3)
// size: buffer: {} (length 0x0)
// pad = 0x0 (1 bytes)
// }
// TCA_ACT_OPTIONS: nlattr_tt[const[TCA_ACT_OPTIONS, int16:14], 0, 1, array[ct_policy]] {
// nla_len: offsetof = 0x4 (2 bytes)
// nla_type: const = 0x2 (1 bytes)
// NLA_F_NET_BYTEORDER: const = 0x0 (0 bytes)
// NLA_F_NESTED: const = 0x1 (1 bytes)
// payload: array[ct_policy] {
// }
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_COOKIE: nlattr_t[const[TCA_ACT_COOKIE, int16], array[int8]] {
// nla_len: offsetof = 0x4 (2 bytes)
// nla_type: const = 0x6 (2 bytes)
// payload: buffer: {} (length 0x0)
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_FLAGS: nlattr_t[const[TCA_ACT_FLAGS, int16], nla_bitfield32[tcf_action_policy_flags]] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x7 (2 bytes)
// payload: nla_bitfield32[tcf_action_policy_flags] {
// value: tcf_action_policy_flags = 0x1 (4 bytes)
// selector: tcf_action_policy_flags = 0x0 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_HW_STATS: nlattr_t[const[TCA_ACT_HW_STATS, int16], nla_bitfield32[tcf_action_policy_hw_stats]] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x8 (2 bytes)
// payload: nla_bitfield32[tcf_action_policy_hw_stats] {
// value: tcf_action_policy_hw_stats = 0x2 (4 bytes)
// selector: tcf_action_policy_hw_stats = 0x1 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// size: buffer: {} (length 0x0)
// }
// }
// union tca_actions {
// m_gact: nlattr_tt[int16:14[0:TCA_ACT_MAX_PRIO], 0, 0, tcf_action_policy["gact", gact_policy]] {
// nla_len: offsetof = 0x30 (2 bytes)
// nla_type: int16 = 0x1 (1 bytes)
// NLA_F_NET_BYTEORDER: const = 0x0 (0 bytes)
// NLA_F_NESTED: const = 0x0 (1 bytes)
// payload: tcf_action_policy["gact", gact_policy] {
// TCA_ACT_KIND: nlattr_t[const[TCA_ACT_KIND, int16], string["gact"]] {
// nla_len: offsetof = 0x9 (2 bytes)
// nla_type: const = 0x1 (2 bytes)
// payload: buffer: {67 61 63 74 00} (length 0x5)
// size: buffer: {} (length 0x0)
// pad = 0x0 (3 bytes)
// }
// TCA_ACT_OPTIONS: nlattr_tt[const[TCA_ACT_OPTIONS, int16:14], 0, 1, array[gact_policy]] {
// nla_len: offsetof = 0x4 (2 bytes)
// nla_type: const = 0x2 (1 bytes)
// NLA_F_NET_BYTEORDER: const = 0x0 (0 bytes)
// NLA_F_NESTED: const = 0x1 (1 bytes)
// payload: array[gact_policy] {
// }
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_COOKIE: nlattr_t[const[TCA_ACT_COOKIE, int16], array[int8]] {
// nla_len: offsetof = 0x4 (2 bytes)
// nla_type: const = 0x6 (2 bytes)
// payload: buffer: {} (length 0x0)
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_FLAGS: nlattr_t[const[TCA_ACT_FLAGS, int16], nla_bitfield32[tcf_action_policy_flags]] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x7 (2 bytes)
// payload: nla_bitfield32[tcf_action_policy_flags] {
// value: tcf_action_policy_flags = 0x1 (4 bytes)
// selector: tcf_action_policy_flags = 0x0 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// TCA_ACT_HW_STATS: nlattr_t[const[TCA_ACT_HW_STATS, int16], nla_bitfield32[tcf_action_policy_hw_stats]] {
// nla_len: offsetof = 0xc (2 bytes)
// nla_type: const = 0x8 (2 bytes)
// payload: nla_bitfield32[tcf_action_policy_hw_stats] {
// value: tcf_action_policy_hw_stats = 0x1 (4 bytes)
// selector: tcf_action_policy_hw_stats = 0x0 (4 bytes)
// }
// size: buffer: {} (length 0x0)
// }
// }
// size: buffer: {} (length 0x0)
// }
// }
// }
// size: buffer: {} (length 0x0)
// }
// }
// }
// size: buffer: {} (length 0x0)
// }
// }
// }
// }
// }
// }
// }
// }
// len: len = 0x1230 (8 bytes)
// }
// }
// vlen: const = 0x1 (8 bytes)
// ctrl: const = 0x0 (8 bytes)
// ctrllen: const = 0x0 (8 bytes)
// f: send_flags = 0x1 (4 bytes)
// pad = 0x0 (4 bytes)
// }
// }
// f: send_flags = 0x4041080 (8 bytes)
// ]
*(uint64_t*)0x200000006040 = 0;
*(uint32_t*)0x200000006048 = 0;
*(uint64_t*)0x200000006050 = 0x200000000140;
*(uint64_t*)0x200000000140 = 0x200000006080;
*(uint32_t*)0x200000006080 = 0x1230;
*(uint16_t*)0x200000006084 = 0x2c;
*(uint16_t*)0x200000006086 = 4;
*(uint32_t*)0x200000006088 = 0x70bd2d;
*(uint32_t*)0x20000000608c = 0x25dfdbfd;
*(uint8_t*)0x200000006090 = 0;
*(uint8_t*)0x200000006091 = 0;
*(uint16_t*)0x200000006092 = 0;
*(uint32_t*)0x200000006094 = 0;
*(uint16_t*)0x200000006098 = 4;
*(uint16_t*)0x20000000609a = 0xe;
*(uint16_t*)0x20000000609c = 0xffe4;
*(uint16_t*)0x20000000609e = 0xffe0;
*(uint16_t*)0x2000000060a0 = 0xe;
*(uint16_t*)0x2000000060a2 = 5;
*(uint16_t*)0x2000000060a4 = 6;
*(uint16_t*)0x2000000060a6 = 5;
*(uint8_t*)0x2000000060a8 = 0x8f;
*(uint8_t*)0x2000000060a9 = 0;
*(uint16_t*)0x2000000060ac = 0xa;
*(uint16_t*)0x2000000060ae = 1;
memcpy((void*)0x2000000060b0, "basic\000", 6);
*(uint16_t*)0x2000000060b8 = 0x11f8;
*(uint16_t*)0x2000000060ba = 2;
*(uint16_t*)0x2000000060bc = 0x128;
*(uint16_t*)0x2000000060be = 3;
*(uint16_t*)0x2000000060c0 = 0x124;
STORE_BY_BITMASK(uint16_t, , 0x2000000060c2, 0xa, 0, 14);
STORE_BY_BITMASK(uint16_t, , 0x2000000060c3, 0, 6, 1);
STORE_BY_BITMASK(uint16_t, , 0x2000000060c3, 0, 7, 1);
*(uint16_t*)0x2000000060c4 = 0xa;
*(uint16_t*)0x2000000060c6 = 1;
memcpy((void*)0x2000000060c8, "pedit\000", 6);
*(uint16_t*)0x2000000060d0 = 4;
STORE_BY_BITMASK(uint16_t, , 0x2000000060d2, 2, 0, 14);
STORE_BY_BITMASK(uint16_t, , 0x2000000060d3, 0, 6, 1);
STORE_BY_BITMASK(uint16_t, , 0x2000000060d3, 1, 7, 1);
*(uint16_t*)0x2000000060d4 = 0xf5;
*(uint16_t*)0x2000000060d6 = 6;
memcpy((void*)0x2000000060d8, "... [truncated large byte array] ...", 241);
*(uint16_t*)0x2000000061cc = 0xc;
*(uint16_t*)0x2000000061ce = 7;
*(uint32_t*)0x2000000061d0 = 0;
*(uint32_t*)0x2000000061d4 = 0;
*(uint16_t*)0x2000000061d8 = 0xc;
*(uint16_t*)0x2000000061da = 8;
*(uint32_t*)0x2000000061dc = 2;
*(uint32_t*)0x2000000061e0 = 3;
*(uint16_t*)0x2000000061e4 = 8;
*(uint16_t*)0x2000000061e6 = 1;
*(uint16_t*)0x2000000061e8 = 0xe;
*(uint16_t*)0x2000000061ea = 0xe;
*(uint16_t*)0x2000000061ec = 8;
*(uint16_t*)0x2000000061ee = 1;
*(uint16_t*)0x2000000061f0 = 0x10;
*(uint16_t*)0x2000000061f2 = 6;
*(uint16_t*)0x2000000061f4 = 8;
*(uint16_t*)0x2000000061f6 = 1;
*(uint16_t*)0x2000000061f8 = 8;
*(uint16_t*)0x2000000061fa = 0xfff2;
*(uint16_t*)0x2000000061fc = 0x10b4;
*(uint16_t*)0x2000000061fe = 3;
*(uint16_t*)0x200000006200 = 0x1054;
STORE_BY_BITMASK(uint16_t, , 0x200000006202, 0x16, 0, 14);
STORE_BY_BITMASK(uint16_t, , 0x200000006203, 0, 6, 1);
STORE_BY_BITMASK(uint16_t, , 0x200000006203, 0, 7, 1);
*(uint16_t*)0x200000006204 = 0xb;
*(uint16_t*)0x200000006206 = 1;
memcpy((void*)0x200000006208, "police\000", 7);
*(uint16_t*)0x200000006210 = 0x1028;
STORE_BY_BITMASK(uint16_t, , 0x200000006212, 2, 0, 14);
STORE_BY_BITMASK(uint16_t, , 0x200000006213, 0, 6, 1);
STORE_BY_BITMASK(uint16_t, , 0x200000006213, 1, 7, 1);
*(uint16_t*)0x200000006214 = 0x404;
*(uint16_t*)0x200000006216 = 3;
*(uint32_t*)0x200000006218 = 0x81;
*(uint32_t*)0x20000000621c = 0x1ff;
*(uint32_t*)0x200000006220 = 0x10000;
*(uint32_t*)0x200000006224 = 5;
*(uint32_t*)0x200000006228 = 0x80000001;
*(uint32_t*)0x20000000622c = 5;
*(uint32_t*)0x200000006230 = 0xfffffffa;
*(uint32_t*)0x200000006234 = 0x5f7;
*(uint32_t*)0x200000006238 = 0xbebc;
*(uint32_t*)0x20000000623c = 2;
*(uint32_t*)0x200000006240 = 7;
*(uint32_t*)0x200000006244 = 7;
*(uint32_t*)0x200000006248 = 7;
*(uint32_t*)0x20000000624c = 0x798a;
*(uint32_t*)0x200000006250 = 0xff;
*(uint32_t*)0x200000006254 = 5;
*(uint32_t*)0x200000006258 = 0xa;
*(uint32_t*)0x20000000625c = 7;
*(uint32_t*)0x200000006260 = 3;
*(uint32_t*)0x200000006264 = 7;
*(uint32_t*)0x200000006268 = 0xff;
*(uint32_t*)0x20000000626c = 2;
*(uint32_t*)0x200000006270 = 2;
*(uint32_t*)0x200000006274 = 7;
*(uint32_t*)0x200000006278 = 5;
*(uint32_t*)0x20000000627c = 6;
*(uint32_t*)0x200000006280 = 2;
*(uint32_t*)0x200000006284 = 8;
*(uint32_t*)0x200000006288 = 5;
*(uint32_t*)0x20000000628c = 0xe08c;
*(uint32_t*)0x200000006290 = 0x3964;
*(uint32_t*)0x200000006294 = 0xf3;
*(uint32_t*)0x200000006298 = 7;
*(uint32_t*)0x20000000629c = 6;
*(uint32_t*)0x2000000062a0 = 7;
*(uint32_t*)0x2000000062a4 = 5;
*(uint32_t*)0x2000000062a8 = 6;
*(uint32_t*)0x2000000062ac = 0xb;
*(uint32_t*)0x2000000062b0 = 0;
*(uint32_t*)0x2000000062b4 = 0;
*(uint32_t*)0x2000000062b8 = 0x102;
*(uint32_t*)0x2000000062bc = 0xbff;
*(uint32_t*)0x2000000062c0 = 0x838;
*(uint32_t*)0x2000000062c4 = 2;
*(uint32_t*)0x2000000062c8 = 0;
*(uint32_t*)0x2000000062cc = 9;
*(uint32_t*)0x2000000062d0 = 3;
*(uint32_t*)0x2000000062d4 = 0x80000000;
*(uint32_t*)0x2000000062d8 = 0x7fffffff;
*(uint32_t*)0x2000000062dc = 0;
*(uint32_t*)0x2000000062e0 = 2;
*(uint32_t*)0x2000000062e4 = 4;
*(uint32_t*)0x2000000062e8 = 0xad6c;
*(uint32_t*)0x2000000062ec = 0xa6f4;
*(uint32_t*)0x2000000062f0 = 6;
*(uint32_t*)0x2000000062f4 = 0x9f9;
*(uint32_t*)0x2000000062f8 = 7;
*(uint32_t*)0x2000000062fc = 4;
*(uint32_t*)0x200000006300 = 3;
*(uint32_t*)0x200000006304 = 6;
*(uint32_t*)0x200000006308 = 0x7fff;
*(uint32_t*)0x20000000630c = 5;
*(uint32_t*)0x200000006310 = 0x8000;
*(uint32_t*)0x200000006314 = 9;
*(uint32_t*)0x200000006318 = 0;
*(uint32_t*)0x20000000631c = 2;
*(uint32_t*)0x200000006320 = 8;
*(uint32_t*)0x200000006324 = 0x7f;
*(uint32_t*)0x200000006328 = 3;
*(uint32_t*)0x20000000632c = 1;
*(uint32_t*)0x200000006330 = 6;
*(uint32_t*)0x200000006334 = 0xaf75;
*(uint32_t*)0x200000006338 = 0xfffff179;
*(uint32_t*)0x20000000633c = 8;
*(uint32_t*)0x200000006340 = 0;
*(uint32_t*)0x200000006344 = 0x89;
*(uint32_t*)0x200000006348 = 7;
*(uint32_t*)0x20000000634c = 0x8001;
*(uint32_t*)0x200000006350 = 0x10001;
*(uint32_t*)0x200000006354 = 8;
*(uint32_t*)0x200000006358 = 6;
*(uint32_t*)0x20000000635c = 0x87;
*(uint32_t*)0x200000006360 = 7;
*(uint32_t*)0x200000006364 = 1;
*(uint32_t*)0x200000006368 = 0x7ca;
*(uint32_t*)0x20000000636c = 0xff;
*(uint32_t*)0x200000006370 = 0x10001;
*(uint32_t*)0x200000006374 = 5;
*(uint32_t*)0x200000006378 = 0xdfbd;
*(uint32_t*)0x20000000637c = 0x6d1b;
*(uint32_t*)0x200000006380 = 0xf4dc;
*(uint32_t*)0x200000006384 = 0xf8000000;
*(uint32_t*)0x200000006388 = 0xbfb;
*(uint32_t*)0x20000000638c = 0x200;
*(uint32_t*)0x200000006390 = 4;
*(uint32_t*)0x200000006394 = 0;
*(uint32_t*)0x200000006398 = 0xfffffff7;
*(uint32_t*)0x20000000639c = 6;
*(uint32_t*)0x2000000063a0 = 9;
*(uint32_t*)0x2000000063a4 = 0x80;
*(uint32_t*)0x2000000063a8 = 0;
*(uint32_t*)0x2000000063ac = 7;
*(uint32_t*)0x2000000063b0 = 9;
*(uint32_t*)0x2000000063b4 = 0x4d;
*(uint32_t*)0x2000000063b8 = 3;
*(uint32_t*)0x2000000063bc = 5;
*(uint32_t*)0x2000000063c0 = 9;
*(uint32_t*)0x2000000063c4 = 0x7ff;
*(uint32_t*)0x2000000063c8 = 1;
*(uint32_t*)0x2000000063cc = 7;
*(uint32_t*)0x2000000063d0 = 0;
*(uint32_t*)0x2000000063d4 = 2;
*(uint32_t*)0x2000000063d8 = 0xf;
*(uint32_t*)0x2000000063dc = 0x401;
*(uint32_t*)0x2000000063e0 = 2;
*(uint32_t*)0x2000000063e4 = 0x1000;
*(uint32_t*)0x2000000063e8 = 4;
*(uint32_t*)0x2000000063ec = -1;
*(uint32_t*)0x2000000063f0 = 7;
*(uint32_t*)0x2000000063f4 = 5;
*(uint32_t*)0x2000000063f8 = 0x80;
*(uint32_t*)0x2000000063fc = 0x1ff;
*(uint32_t*)0x200000006400 = 0xf;
*(uint32_t*)0x200000006404 = 9;
*(uint32_t*)0x200000006408 = 0;
*(uint32_t*)0x20000000640c = 6;
*(uint32_t*)0x200000006410 = 0xc1;
*(uint32_t*)0x200000006414 = 0xa;
*(uint32_t*)0x200000006418 = 2;
*(uint32_t*)0x20000000641c = 5;
*(uint32_t*)0x200000006420 = 0x38;
*(uint32_t*)0x200000006424 = 0xff;
*(uint32_t*)0x200000006428 = 0xffffff80;
*(uint32_t*)0x20000000642c = 0x9df;
*(uint32_t*)0x200000006430 = 6;
*(uint32_t*)0x200000006434 = 2;
*(uint32_t*)0x200000006438 = 0x1ff;
*(uint32_t*)0x20000000643c = 0;
*(uint32_t*)0x200000006440 = 8;
*(uint32_t*)0x200000006444 = 0xb;
*(uint32_t*)0x200000006448 = 0x200;
*(uint32_t*)0x20000000644c = 8;
*(uint32_t*)0x200000006450 = 1;
*(uint32_t*)0x200000006454 = 2;
*(uint32_t*)0x200000006458 = 2;
*(uint32_t*)0x20000000645c = 0x2ee9;
*(uint32_t*)0x200000006460 = 1;
*(uint32_t*)0x200000006464 = 5;
*(uint32_t*)0x200000006468 = 0;
*(uint32_t*)0x20000000646c = 0x80;
*(uint32_t*)0x200000006470 = 3;
*(uint32_t*)0x200000006474 = 0x80;
*(uint32_t*)0x200000006478 = 0x2ecc8490;
*(uint32_t*)0x20000000647c = 9;
*(uint32_t*)0x200000006480 = 0xa7;
*(uint32_t*)0x200000006484 = 0x24d;
*(uint32_t*)0x200000006488 = 0xa;
*(uint32_t*)0x20000000648c = 0;
*(uint32_t*)0x200000006490 = 0xfff;
*(uint32_t*)0x200000006494 = 0x18;
*(uint32_t*)0x200000006498 = 8;
*(uint32_t*)0x20000000649c = 0xa;
*(uint32_t*)0x2000000064a0 = 3;
*(uint32_t*)0x2000000064a4 = 0xd85;
*(uint32_t*)0x2000000064a8 = 0xd4;
*(uint32_t*)0x2000000064ac = 9;
*(uint32_t*)0x2000000064b0 = 0xc64a;
*(uint32_t*)0x2000000064b4 = 9;
*(uint32_t*)0x2000000064b8 = 0;
*(uint32_t*)0x2000000064bc = 0;
*(uint32_t*)0x2000000064c0 = 0;
*(uint32_t*)0x2000000064c4 = 0xfff;
*(uint32_t*)0x2000000064c8 = 7;
*(uint32_t*)0x2000000064cc = 6;
*(uint32_t*)0x2000000064d0 = 0xabd;
*(uint32_t*)0x2000000064d4 = 3;
*(uint32_t*)0x2000000064d8 = 0x8000;
*(uint32_t*)0x2000000064dc = 3;
*(uint32_t*)0x2000000064e0 = 4;
*(uint32_t*)0x2000000064e4 = 1;
*(uint32_t*)0x2000000064e8 = 7;
*(uint32_t*)0x2000000064ec = 9;
*(uint32_t*)0x2000000064f0 = 0xdd7;
*(uint32_t*)0x2000000064f4 = 0xfff;
*(uint32_t*)0x2000000064f8 = 5;
*(uint32_t*)0x2000000064fc = 3;
*(uint32_t*)0x200000006500 = 7;
*(uint32_t*)0x200000006504 = 9;
*(uint32_t*)0x200000006508 = 9;
*(uint32_t*)0x20000000650c = 0xb;
*(uint32_t*)0x200000006510 = 4;
*(uint32_t*)0x200000006514 = 0x80;
*(uint32_t*)0x200000006518 = 4;
*(uint32_t*)0x20000000651c = 3;
*(uint32_t*)0x200000006520 = 6;
*(uint32_t*)0x200000006524 = 0x10000;
*(uint32_t*)0x200000006528 = 1;
*(uint32_t*)0x20000000652c = 0xb;
*(uint32_t*)0x200000006530 = 6;
*(uint32_t*)0x200000006534 = 0xe;
*(uint32_t*)0x200000006538 = 1;
*(uint32_t*)0x20000000653c = 0xfff;
*(uint32_t*)0x200000006540 = 0;
*(uint32_t*)0x200000006544 = 0xff;
*(uint32_t*)0x200000006548 = 0;
*(uint32_t*)0x20000000654c = 0xc;
*(uint32_t*)0x200000006550 = 0xa4;
*(uint32_t*)0x200000006554 = 0x7f;
*(uint32_t*)0x200000006558 = 0x24;
*(uint32_t*)0x20000000655c = 0xa9a;
*(uint32_t*)0x200000006560 = 8;
*(uint32_t*)0x200000006564 = 5;
*(uint32_t*)0x200000006568 = 0x8001;
*(uint32_t*)0x20000000656c = 0x2ba;
*(uint32_t*)0x200000006570 = 0x8001;
*(uint32_t*)0x200000006574 = 0x854;
*(uint32_t*)0x200000006578 = 4;
*(uint32_t*)0x20000000657c = 0xe7;
*(uint32_t*)0x200000006580 = 2;
*(uint32_t*)0x200000006584 = 3;
*(uint32_t*)0x200000006588 = 2;
*(uint32_t*)0x20000000658c = 5;
*(uint32_t*)0x200000006590 = 5;
*(uint32_t*)0x200000006594 = 2;
*(uint32_t*)0x200000006598 = 9;
*(uint32_t*)0x20000000659c = 0x3ff;
*(uint32_t*)0x2000000065a0 = 1;
*(uint32_t*)0x2000000065a4 = -1;
*(uint32_t*)0x2000000065a8 = 8;
*(uint32_t*)0x2000000065ac = 0xfff;
*(uint32_t*)0x2000000065b0 = 9;
*(uint32_t*)0x2000000065b4 = 2;
*(uint32_t*)0x2000000065b8 = 3;
*(uint32_t*)0x2000000065bc = 0;
*(uint32_t*)0x2000000065c0 = 0x80000000;
*(uint32_t*)0x2000000065c4 = 8;
*(uint32_t*)0x2000000065c8 = 0xfff;
*(uint32_t*)0x2000000065cc = 0;
*(uint32_t*)0x2000000065d0 = 0x86;
*(uint32_t*)0x2000000065d4 = 0x81;
*(uint32_t*)0x2000000065d8 = 9;
*(uint32_t*)0x2000000065dc = 9;
*(uint32_t*)0x2000000065e0 = 0x800;
*(uint32_t*)0x2000000065e4 = 0xfffffffd;
*(uint32_t*)0x2000000065e8 = 0x9c1;
*(uint32_t*)0x2000000065ec = 2;
*(uint32_t*)0x2000000065f0 = 0xfffffffc;
*(uint32_t*)0x2000000065f4 = 8;
*(uint32_t*)0x2000000065f8 = 0xc;
*(uint32_t*)0x2000000065fc = 2;
*(uint32_t*)0x200000006600 = 0;
*(uint32_t*)0x200000006604 = 3;
*(uint32_t*)0x200000006608 = 7;
*(uint32_t*)0x20000000660c = 5;
*(uint32_t*)0x200000006610 = 0xd;
*(uint32_t*)0x200000006614 = 0xb;
*(uint16_t*)0x200000006618 = 0xc;
*(uint16_t*)0x20000000661a = 8;
*(uint64_t*)0x20000000661c = 5;
*(uint16_t*)0x200000006624 = 0x404;
*(uint16_t*)0x200000006626 = 3;
*(uint32_t*)0x200000006628 = 3;
*(uint32_t*)0x20000000662c = 4;
*(uint32_t*)0x200000006630 = 0xc6c;
*(uint32_t*)0x200000006634 = 9;
*(uint32_t*)0x200000006638 = 0xb;
*(uint32_t*)0x20000000663c = 2;
*(uint32_t*)0x200000006640 = 3;
*(uint32_t*)0x200000006644 = 1;
*(uint32_t*)0x200000006648 = 8;
*(uint32_t*)0x20000000664c = 1;
*(uint32_t*)0x200000006650 = 0;
*(uint32_t*)0x200000006654 = 0x7ff;
*(uint32_t*)0x200000006658 = 1;
*(uint32_t*)0x20000000665c = 0x8001;
*(uint32_t*)0x200000006660 = 5;
*(uint32_t*)0x200000006664 = 0x7f;
*(uint32_t*)0x200000006668 = 8;
*(uint32_t*)0x20000000666c = 6;
*(uint32_t*)0x200000006670 = 7;
*(uint32_t*)0x200000006674 = -1;
*(uint32_t*)0x200000006678 = 2;
*(uint32_t*)0x20000000667c = 0xf;
*(uint32_t*)0x200000006680 = 4;
*(uint32_t*)0x200000006684 = -1;
*(uint32_t*)0x200000006688 = 1;
*(uint32_t*)0x20000000668c = 0x1000000;
*(uint32_t*)0x200000006690 = 0xf;
*(uint32_t*)0x200000006694 = 2;
*(uint32_t*)0x200000006698 = 4;
*(uint32_t*)0x20000000669c = 5;
*(uint32_t*)0x2000000066a0 = 3;
*(uint32_t*)0x2000000066a4 = 0x8000;
*(uint32_t*)0x2000000066a8 = 0x9f4f5d67;
*(uint32_t*)0x2000000066ac = 9;
*(uint32_t*)0x2000000066b0 = 9;
*(uint32_t*)0x2000000066b4 = 0;
*(uint32_t*)0x2000000066b8 = 7;
*(uint32_t*)0x2000000066bc = 8;
*(uint32_t*)0x2000000066c0 = 8;
*(uint32_t*)0x2000000066c4 = 0x7ff;
*(uint32_t*)0x2000000066c8 = 2;
*(uint32_t*)0x2000000066cc = 0x32;
*(uint32_t*)0x2000000066d0 = 3;
*(uint32_t*)0x2000000066d4 = 8;
*(uint32_t*)0x2000000066d8 = 0x30000000;
*(uint32_t*)0x2000000066dc = 0xdd;
*(uint32_t*)0x2000000066e0 = 0;
*(uint32_t*)0x2000000066e4 = 1;
*(uint32_t*)0x2000000066e8 = 0x400;
*(uint32_t*)0x2000000066ec = 3;
*(uint32_t*)0x2000000066f0 = 8;
*(uint32_t*)0x2000000066f4 = 0x101;
*(uint32_t*)0x2000000066f8 = -1;
*(uint32_t*)0x2000000066fc = 9;
*(uint32_t*)0x200000006700 = 3;
*(uint32_t*)0x200000006704 = 0xa;
*(uint32_t*)0x200000006708 = 6;
*(uint32_t*)0x20000000670c = 0xd;
*(uint32_t*)0x200000006710 = 2;
*(uint32_t*)0x200000006714 = 7;
*(uint32_t*)0x200000006718 = 3;
*(uint32_t*)0x20000000671c = 9;
*(uint32_t*)0x200000006720 = 0x39c0;
*(uint32_t*)0x200000006724 = 3;
*(uint32_t*)0x200000006728 = 4;
*(uint32_t*)0x20000000672c = 0x94b;
*(uint32_t*)0x200000006730 = 5;
*(uint32_t*)0x200000006734 = 1;
*(uint32_t*)0x200000006738 = 0x777;
*(uint32_t*)0x20000000673c = 2;
*(uint32_t*)0x200000006740 = 9;
*(uint32_t*)0x200000006744 = 0x800;
*(uint32_t*)0x200000006748 = 0x1000;
*(uint32_t*)0x20000000674c = 0xa;
*(uint32_t*)0x200000006750 = 0x9e;
*(uint32_t*)0x200000006754 = 0xcc;
*(uint32_t*)0x200000006758 = 8;
*(uint32_t*)0x20000000675c = 0;
*(uint32_t*)0x200000006760 = 0xffffff37;
*(uint32_t*)0x200000006764 = 9;
*(uint32_t*)0x200000006768 = 7;
*(uint32_t*)0x20000000676c = 8;
*(uint32_t*)0x200000006770 = 0x7ff;
*(uint32_t*)0x200000006774 = 7;
*(uint32_t*)0x200000006778 = -1;
*(uint32_t*)0x20000000677c = 8;
*(uint32_t*)0x200000006780 = 0xfffffffc;
*(uint32_t*)0x200000006784 = 0x101;
*(uint32_t*)0x200000006788 = 8;
*(uint32_t*)0x20000000678c = 9;
*(uint32_t*)0x200000006790 = 4;
*(uint32_t*)0x200000006794 = 9;
*(uint32_t*)0x200000006798 = 4;
*(uint32_t*)0x20000000679c = 9;
*(uint32_t*)0x2000000067a0 = 7;
*(uint32_t*)0x2000000067a4 = 4;
*(uint32_t*)0x2000000067a8 = 0xf3;
*(uint32_t*)0x2000000067ac = 1;
*(uint32_t*)0x2000000067b0 = 0x10000;
*(uint32_t*)0x2000000067b4 = 0x10000;
*(uint32_t*)0x2000000067b8 = 8;
*(uint32_t*)0x2000000067bc = 0x7a36;
*(uint32_t*)0x2000000067c0 = 7;
*(uint32_t*)0x2000000067c4 = 0x40;
*(uint32_t*)0x2000000067c8 = 0xd10;
*(uint32_t*)0x2000000067cc = 0x455e;
*(uint32_t*)0x2000000067d0 = 4;
*(uint32_t*)0x2000000067d4 = 4;
*(uint32_t*)0x2000000067d8 = 5;
*(uint32_t*)0x2000000067dc = 0xff;
*(uint32_t*)0x2000000067e0 = 2;
*(uint32_t*)0x2000000067e4 = 6;
*(uint32_t*)0x2000000067e8 = 0x40000;
*(uint32_t*)0x2000000067ec = -1;
*(uint32_t*)0x2000000067f0 = 0x18bc169;
*(uint32_t*)0x2000000067f4 = 0x10;
*(uint32_t*)0x2000000067f8 = 4;
*(uint32_t*)0x2000000067fc = 0xb66;
*(uint32_t*)0x200000006800 = 0x100;
*(uint32_t*)0x200000006804 = 5;
*(uint32_t*)0x200000006808 = 0x3d;
*(uint32_t*)0x20000000680c = 5;
*(uint32_t*)0x200000006810 = 0;
*(uint32_t*)0x200000006814 = 0x81;
*(uint32_t*)0x200000006818 = 0x81;
*(uint32_t*)0x20000000681c = 2;
*(uint32_t*)0x200000006820 = 0x8001;
*(uint32_t*)0x200000006824 = 4;
*(uint32_t*)0x200000006828 = 7;
*(uint32_t*)0x20000000682c = 9;
*(uint32_t*)0x200000006830 = 3;
*(uint32_t*)0x200000006834 = 0xc;
*(uint32_t*)0x200000006838 = 1;
*(uint32_t*)0x20000000683c = 0;
*(uint32_t*)0x200000006840 = 6;
*(uint32_t*)0x200000006844 = 0x7fffffff;
*(uint32_t*)0x200000006848 = 0x52acd031;
*(uint32_t*)0x20000000684c = 0xf938;
*(uint32_t*)0x200000006850 = 0xc8;
*(uint32_t*)0x200000006854 = 0x1b;
*(uint32_t*)0x200000006858 = 3;
*(uint32_t*)0x20000000685c = 0x80000001;
*(uint32_t*)0x200000006860 = 9;
*(uint32_t*)0x200000006864 = 6;
*(uint32_t*)0x200000006868 = 2;
*(uint32_t*)0x20000000686c = 8;
*(uint32_t*)0x200000006870 = 0x41;
*(uint32_t*)0x200000006874 = 0x401;
*(uint32_t*)0x200000006878 = 0xfff;
*(uint32_t*)0x20000000687c = 7;
*(uint32_t*)0x200000006880 = 0x100007;
*(uint32_t*)0x200000006884 = 1;
*(uint32_t*)0x200000006888 = 0xd17;
*(uint32_t*)0x20000000688c = 7;
*(uint32_t*)0x200000006890 = 0x400;
*(uint32_t*)0x200000006894 = 0;
*(uint32_t*)0x200000006898 = 4;
*(uint32_t*)0x20000000689c = 0x80000000;
*(uint32_t*)0x2000000068a0 = 0x400;
*(uint32_t*)0x2000000068a4 = 1;
*(uint32_t*)0x2000000068a8 = 0xfffffffd;
*(uint32_t*)0x2000000068ac = 0xc6;
*(uint32_t*)0x2000000068b0 = 9;
*(uint32_t*)0x2000000068b4 = 8;
*(uint32_t*)0x2000000068b8 = 7;
*(uint32_t*)0x2000000068bc = 0x25;
*(uint32_t*)0x2000000068c0 = 2;
*(uint32_t*)0x2000000068c4 = 0x400;
*(uint32_t*)0x2000000068c8 = 4;
*(uint32_t*)0x2000000068cc = 0xb;
*(uint32_t*)0x2000000068d0 = 3;
*(uint32_t*)0x2000000068d4 = 1;
*(uint32_t*)0x2000000068d8 = 6;
*(uint32_t*)0x2000000068dc = 0;
*(uint32_t*)0x2000000068e0 = 0x81;
*(uint32_t*)0x2000000068e4 = 1;
*(uint32_t*)0x2000000068e8 = 0;
*(uint32_t*)0x2000000068ec = 0x200000a;
*(uint32_t*)0x2000000068f0 = 3;
*(uint32_t*)0x2000000068f4 = 3;
*(uint32_t*)0x2000000068f8 = 7;
*(uint32_t*)0x2000000068fc = 0x8000;
*(uint32_t*)0x200000006900 = 0xd;
*(uint32_t*)0x200000006904 = 8;
*(uint32_t*)0x200000006908 = 3;
*(uint32_t*)0x20000000690c = 0xb;
*(uint32_t*)0x200000006910 = 9;
*(uint32_t*)0x200000006914 = 0xff;
*(uint32_t*)0x200000006918 = 0;
*(uint32_t*)0x20000000691c = 0;
*(uint32_t*)0x200000006920 = 3;
*(uint32_t*)0x200000006924 = 0x83;
*(uint32_t*)0x200000006928 = 0x1ff;
*(uint32_t*)0x20000000692c = 1;
*(uint32_t*)0x200000006930 = 4;
*(uint32_t*)0x200000006934 = 0xa;
*(uint32_t*)0x200000006938 = 0x87;
*(uint32_t*)0x20000000693c = 0x800;
*(uint32_t*)0x200000006940 = 0xdba;
*(uint32_t*)0x200000006944 = 0;
*(uint32_t*)0x200000006948 = 0xe1d;
*(uint32_t*)0x20000000694c = 0x7f;
*(uint32_t*)0x200000006950 = 7;
*(uint32_t*)0x200000006954 = 0x8001;
*(uint32_t*)0x200000006958 = 9;
*(uint32_t*)0x20000000695c = 9;
*(uint32_t*)0x200000006960 = 0xfffffffa;
*(uint32_t*)0x200000006964 = 8;
*(uint32_t*)0x200000006968 = 4;
*(uint32_t*)0x20000000696c = 5;
*(uint32_t*)0x200000006970 = 0xff;
*(uint32_t*)0x200000006974 = 7;
*(uint32_t*)0x200000006978 = 9;
*(uint32_t*)0x20000000697c = 0x9ca;
*(uint32_t*)0x200000006980 = 0;
*(uint32_t*)0x200000006984 = 0xc;
*(uint32_t*)0x200000006988 = 9;
*(uint32_t*)0x20000000698c = 0xfffffb9b;
*(uint32_t*)0x200000006990 = 0xd;
*(uint32_t*)0x200000006994 = 0xfff;
*(uint32_t*)0x200000006998 = 9;
*(uint32_t*)0x20000000699c = 2;
*(uint32_t*)0x2000000069a0 = 0x800;
*(uint32_t*)0x2000000069a4 = 0xfffffff7;
*(uint32_t*)0x2000000069a8 = 0x7ff;
*(uint32_t*)0x2000000069ac = 5;
*(uint32_t*)0x2000000069b0 = 5;
*(uint32_t*)0x2000000069b4 = 0x8001;
*(uint32_t*)0x2000000069b8 = 1;
*(uint32_t*)0x2000000069bc = 0x80000001;
*(uint32_t*)0x2000000069c0 = 0xc9;
*(uint32_t*)0x2000000069c4 = 2;
*(uint32_t*)0x2000000069c8 = 1;
*(uint32_t*)0x2000000069cc = 0x8001;
*(uint32_t*)0x2000000069d0 = 5;
*(uint32_t*)0x2000000069d4 = 9;
*(uint32_t*)0x2000000069d8 = 3;
*(uint32_t*)0x2000000069dc = 8;
*(uint32_t*)0x2000000069e0 = 0xe47;
*(uint32_t*)0x2000000069e4 = 0x1ff;
*(uint32_t*)0x2000000069e8 = 3;
*(uint32_t*)0x2000000069ec = 2;
*(uint32_t*)0x2000000069f0 = 0x49;
*(uint32_t*)0x2000000069f4 = 7;
*(uint32_t*)0x2000000069f8 = 0xfffffa1f;
*(uint32_t*)0x2000000069fc = 1;
*(uint32_t*)0x200000006a00 = 0x7f;
*(uint32_t*)0x200000006a04 = 4;
*(uint32_t*)0x200000006a08 = 0x3ff;
*(uint32_t*)0x200000006a0c = 3;
*(uint32_t*)0x200000006a10 = 0x18000;
*(uint32_t*)0x200000006a14 = 0x4d0;
*(uint32_t*)0x200000006a18 = 0x8000;
*(uint32_t*)0x200000006a1c = 6;
*(uint32_t*)0x200000006a20 = 2;
*(uint32_t*)0x200000006a24 = 0x5cd;
*(uint16_t*)0x200000006a28 = 8;
*(uint16_t*)0x200000006a2a = 4;
*(uint32_t*)0x200000006a2c = 0x80;
*(uint16_t*)0x200000006a30 = 0x404;
*(uint16_t*)0x200000006a32 = 2;
*(uint32_t*)0x200000006a34 = 6;
*(uint32_t*)0x200000006a38 = 0;
*(uint32_t*)0x200000006a3c = 0x80000000;
*(uint32_t*)0x200000006a40 = 4;
*(uint32_t*)0x200000006a44 = 7;
*(uint32_t*)0x200000006a48 = 3;
*(uint32_t*)0x200000006a4c = 0x200;
*(uint32_t*)0x200000006a50 = 4;
*(uint32_t*)0x200000006a54 = 0;
*(uint32_t*)0x200000006a58 = 5;
*(uint32_t*)0x200000006a5c = 0x7fffffff;
*(uint32_t*)0x200000006a60 = 9;
*(uint32_t*)0x200000006a64 = 4;
*(uint32_t*)0x200000006a68 = 0x101;
*(uint32_t*)0x200000006a6c = 0xffffff51;
*(uint32_t*)0x200000006a70 = 5;
*(uint32_t*)0x200000006a74 = 2;
*(uint32_t*)0x200000006a78 = 0x401;
*(uint32_t*)0x200000006a7c = 3;
*(uint32_t*)0x200000006a80 = 0xd5c6;
*(uint32_t*)0x200000006a84 = 0x400;
*(uint32_t*)0x200000006a88 = 9;
*(uint32_t*)0x200000006a8c = 0x9c3;
*(uint32_t*)0x200000006a90 = 0;
*(uint32_t*)0x200000006a94 = 0xb;
*(uint32_t*)0x200000006a98 = 0;
*(uint32_t*)0x200000006a9c = 0xfffffffa;
*(uint32_t*)0x200000006aa0 = 3;
*(uint32_t*)0x200000006aa4 = 0;
*(uint32_t*)0x200000006aa8 = 5;
*(uint32_t*)0x200000006aac = 0xd9;
*(uint32_t*)0x200000006ab0 = 0xef;
*(uint32_t*)0x200000006ab4 = 7;
*(uint32_t*)0x200000006ab8 = -1;
*(uint32_t*)0x200000006abc = 7;
*(uint32_t*)0x200000006ac0 = 1;
*(uint32_t*)0x200000006ac4 = 0xffff;
*(uint32_t*)0x200000006ac8 = 0xfffffffb;
*(uint32_t*)0x200000006acc = 9;
*(uint32_t*)0x200000006ad0 = 8;
*(uint32_t*)0x200000006ad4 = 3;
*(uint32_t*)0x200000006ad8 = 0;
*(uint32_t*)0x200000006adc = 3;
*(uint32_t*)0x200000006ae0 = 4;
*(uint32_t*)0x200000006ae4 = 2;
*(uint32_t*)0x200000006ae8 = 0xfffffffd;
*(uint32_t*)0x200000006aec = 7;
*(uint32_t*)0x200000006af0 = 9;
*(uint32_t*)0x200000006af4 = 0xffff;
*(uint32_t*)0x200000006af8 = 0x800;
*(uint32_t*)0x200000006afc = 0xfffffff8;
*(uint32_t*)0x200000006b00 = 0;
*(uint32_t*)0x200000006b04 = 0xb;
*(uint32_t*)0x200000006b08 = 6;
*(uint32_t*)0x200000006b0c = 0x67;
*(uint32_t*)0x200000006b10 = 0xfd0;
*(uint32_t*)0x200000006b14 = 0xffffffbe;
*(uint32_t*)0x200000006b18 = 2;
*(uint32_t*)0x200000006b1c = 1;
*(uint32_t*)0x200000006b20 = 2;
*(uint32_t*)0x200000006b24 = 4;
*(uint32_t*)0x200000006b28 = 5;
*(uint32_t*)0x200000006b2c = 1;
*(uint32_t*)0x200000006b30 = 0;
*(uint32_t*)0x200000006b34 = 0xff;
*(uint32_t*)0x200000006b38 = 0x101;
*(uint32_t*)0x200000006b3c = 1;
*(uint32_t*)0x200000006b40 = 0;
*(uint32_t*)0x200000006b44 = 1;
*(uint32_t*)0x200000006b48 = 0;
*(uint32_t*)0x200000006b4c = 0xffff;
*(uint32_t*)0x200000006b50 = 0xfffffff7;
*(uint32_t*)0x200000006b54 = 8;
*(uint32_t*)0x200000006b58 = 9;
*(uint32_t*)0x200000006b5c = 0xa2;
*(uint32_t*)0x200000006b60 = 0x1336df01;
*(uint32_t*)0x200000006b64 = -1;
*(uint32_t*)0x200000006b68 = 0x81;
*(uint32_t*)0x200000006b6c = 9;
*(uint32_t*)0x200000006b70 = 3;
*(uint32_t*)0x200000006b74 = 0x40;
*(uint32_t*)0x200000006b78 = 0;
*(uint32_t*)0x200000006b7c = 0xf;
*(uint32_t*)0x200000006b80 = 0x3ff;
*(uint32_t*)0x200000006b84 = 1;
*(uint32_t*)0x200000006b88 = 0x80000001;
*(uint32_t*)0x200000006b8c = 0xc0d7;
*(uint32_t*)0x200000006b90 = 0xf9;
*(uint32_t*)0x200000006b94 = 0x59;
*(uint32_t*)0x200000006b98 = 0x1000;
*(uint32_t*)0x200000006b9c = 0;
*(uint32_t*)0x200000006ba0 = 0;
*(uint32_t*)0x200000006ba4 = 0x400;
*(uint32_t*)0x200000006ba8 = 6;
*(uint32_t*)0x200000006bac = 9;
*(uint32_t*)0x200000006bb0 = 0x8001;
*(uint32_t*)0x200000006bb4 = 0xff6d;
*(uint32_t*)0x200000006bb8 = 0x1ff;
*(uint32_t*)0x200000006bbc = 6;
*(uint32_t*)0x200000006bc0 = 0x7f;
*(uint32_t*)0x200000006bc4 = 0x90000;
*(uint32_t*)0x200000006bc8 = 8;
*(uint32_t*)0x200000006bcc = 0xf;
*(uint32_t*)0x200000006bd0 = 9;
*(uint32_t*)0x200000006bd4 = 3;
*(uint32_t*)0x200000006bd8 = 0x8cca;
*(uint32_t*)0x200000006bdc = 0x8000;
*(uint32_t*)0x200000006be0 = -1;
*(uint32_t*)0x200000006be4 = 0;
*(uint32_t*)0x200000006be8 = 5;
*(uint32_t*)0x200000006bec = 0x10000;
*(uint32_t*)0x200000006bf0 = 9;
*(uint32_t*)0x200000006bf4 = 1;
*(uint32_t*)0x200000006bf8 = 7;
*(uint32_t*)0x200000006bfc = 3;
*(uint32_t*)0x200000006c00 = 8;
*(uint32_t*)0x200000006c04 = 0xaa;
*(uint32_t*)0x200000006c08 = 8;
*(uint32_t*)0x200000006c0c = 4;
*(uint32_t*)0x200000006c10 = 3;
*(uint32_t*)0x200000006c14 = 1;
*(uint32_t*)0x200000006c18 = 0x40;
*(uint32_t*)0x200000006c1c = -1;
*(uint32_t*)0x200000006c20 = 7;
*(uint32_t*)0x200000006c24 = 4;
*(uint32_t*)0x200000006c28 = 0xfffffff5;
*(uint32_t*)0x200000006c2c = 0x95c;
*(uint32_t*)0x200000006c30 = 0xf6;
*(uint32_t*)0x200000006c34 = 4;
*(uint32_t*)0x200000006c38 = 2;
*(uint32_t*)0x200000006c3c = 0x7fffffff;
*(uint32_t*)0x200000006c40 = 9;
*(uint32_t*)0x200000006c44 = 4;
*(uint32_t*)0x200000006c48 = 0x1000;
*(uint32_t*)0x200000006c4c = 1;
*(uint32_t*)0x200000006c50 = 7;
*(uint32_t*)0x200000006c54 = 0xffff7fff;
*(uint32_t*)0x200000006c58 = 9;
*(uint32_t*)0x200000006c5c = 0x71;
*(uint32_t*)0x200000006c60 = 0xff;
*(uint32_t*)0x200000006c64 = 0;
*(uint32_t*)0x200000006c68 = 0;
*(uint32_t*)0x200000006c6c = 5;
*(uint32_t*)0x200000006c70 = 0xb4;
*(uint32_t*)0x200000006c74 = 0x3ff;
*(uint32_t*)0x200000006c78 = 1;
*(uint32_t*)0x200000006c7c = 6;
*(uint32_t*)0x200000006c80 = 9;
*(uint32_t*)0x200000006c84 = 6;
*(uint32_t*)0x200000006c88 = 3;
*(uint32_t*)0x200000006c8c = 0x7791070f;
*(uint32_t*)0x200000006c90 = 9;
*(uint32_t*)0x200000006c94 = 0x4eb8;
*(uint32_t*)0x200000006c98 = 7;
*(uint32_t*)0x200000006c9c = 0xe2;
*(uint32_t*)0x200000006ca0 = 9;
*(uint32_t*)0x200000006ca4 = 9;
*(uint32_t*)0x200000006ca8 = 3;
*(uint32_t*)0x200000006cac = 1;
*(uint32_t*)0x200000006cb0 = 5;
*(uint32_t*)0x200000006cb4 = 8;
*(uint32_t*)0x200000006cb8 = 1;
*(uint32_t*)0x200000006cbc = 8;
*(uint32_t*)0x200000006cc0 = 5;
*(uint32_t*)0x200000006cc4 = 6;
*(uint32_t*)0x200000006cc8 = 5;
*(uint32_t*)0x200000006ccc = 5;
*(uint32_t*)0x200000006cd0 = 0xffffff01;
*(uint32_t*)0x200000006cd4 = 0xfffffffe;
*(uint32_t*)0x200000006cd8 = 0xc;
*(uint32_t*)0x200000006cdc = 4;
*(uint32_t*)0x200000006ce0 = 0x40;
*(uint32_t*)0x200000006ce4 = 0x400;
*(uint32_t*)0x200000006ce8 = 3;
*(uint32_t*)0x200000006cec = 7;
*(uint32_t*)0x200000006cf0 = 9;
*(uint32_t*)0x200000006cf4 = 0;
*(uint32_t*)0x200000006cf8 = 0x38;
*(uint32_t*)0x200000006cfc = 5;
*(uint32_t*)0x200000006d00 = 0xb25;
*(uint32_t*)0x200000006d04 = 5;
*(uint32_t*)0x200000006d08 = 0x73c0;
*(uint32_t*)0x200000006d0c = 4;
*(uint32_t*)0x200000006d10 = 0x9000000;
*(uint32_t*)0x200000006d14 = 6;
*(uint32_t*)0x200000006d18 = 5;
*(uint32_t*)0x200000006d1c = 0x57b;
*(uint32_t*)0x200000006d20 = 0xa;
*(uint32_t*)0x200000006d24 = 0x7f;
*(uint32_t*)0x200000006d28 = 0x3fb2;
*(uint32_t*)0x200000006d2c = 0xce;
*(uint32_t*)0x200000006d30 = 0x8000;
*(uint32_t*)0x200000006d34 = 0xb315;
*(uint32_t*)0x200000006d38 = 0xfffffff2;
*(uint32_t*)0x200000006d3c = 2;
*(uint32_t*)0x200000006d40 = 3;
*(uint32_t*)0x200000006d44 = 5;
*(uint32_t*)0x200000006d48 = 1;
*(uint32_t*)0x200000006d4c = -1;
*(uint32_t*)0x200000006d50 = 3;
*(uint32_t*)0x200000006d54 = 5;
*(uint32_t*)0x200000006d58 = 5;
*(uint32_t*)0x200000006d5c = 6;
*(uint32_t*)0x200000006d60 = 0x8001;
*(uint32_t*)0x200000006d64 = 0xfffffff8;
*(uint32_t*)0x200000006d68 = 4;
*(uint32_t*)0x200000006d6c = 0xf;
*(uint32_t*)0x200000006d70 = 0xfffffffd;
*(uint32_t*)0x200000006d74 = 0x100;
*(uint32_t*)0x200000006d78 = 2;
*(uint32_t*)0x200000006d7c = 0x101;
*(uint32_t*)0x200000006d80 = 8;
*(uint32_t*)0x200000006d84 = 9;
*(uint32_t*)0x200000006d88 = 5;
*(uint32_t*)0x200000006d8c = 1;
*(uint32_t*)0x200000006d90 = 3;
*(uint32_t*)0x200000006d94 = 4;
*(uint32_t*)0x200000006d98 = 0x3ff;
*(uint32_t*)0x200000006d9c = 4;
*(uint32_t*)0x200000006da0 = 0x100;
*(uint32_t*)0x200000006da4 = 4;
*(uint32_t*)0x200000006da8 = 6;
*(uint32_t*)0x200000006dac = 0xffff8000;
*(uint32_t*)0x200000006db0 = 2;
*(uint32_t*)0x200000006db4 = 0xb;
*(uint32_t*)0x200000006db8 = 0x1000;
*(uint32_t*)0x200000006dbc = 0x7282;
*(uint32_t*)0x200000006dc0 = 9;
*(uint32_t*)0x200000006dc4 = 0x8c;
*(uint32_t*)0x200000006dc8 = 7;
*(uint32_t*)0x200000006dcc = 0xe;
*(uint32_t*)0x200000006dd0 = 0x81;
*(uint32_t*)0x200000006dd4 = 9;
*(uint32_t*)0x200000006dd8 = 2;
*(uint32_t*)0x200000006ddc = 5;
*(uint32_t*)0x200000006de0 = 6;
*(uint32_t*)0x200000006de4 = 1;
*(uint32_t*)0x200000006de8 = 0x10000;
*(uint32_t*)0x200000006dec = 0xff;
*(uint32_t*)0x200000006df0 = 0x1c;
*(uint32_t*)0x200000006df4 = 1;
*(uint32_t*)0x200000006df8 = 6;
*(uint32_t*)0x200000006dfc = 0x8000;
*(uint32_t*)0x200000006e00 = 5;
*(uint32_t*)0x200000006e04 = 8;
*(uint32_t*)0x200000006e08 = 6;
*(uint32_t*)0x200000006e0c = 0x81;
*(uint32_t*)0x200000006e10 = 0xa;
*(uint32_t*)0x200000006e14 = 0xf;
*(uint32_t*)0x200000006e18 = 0xbc;
*(uint32_t*)0x200000006e1c = 0x1ff;
*(uint32_t*)0x200000006e20 = 9;
*(uint32_t*)0x200000006e24 = 3;
*(uint32_t*)0x200000006e28 = 5;
*(uint32_t*)0x200000006e2c = 0x1000;
*(uint32_t*)0x200000006e30 = 9;
*(uint16_t*)0x200000006e34 = 0x404;
*(uint16_t*)0x200000006e36 = 3;
*(uint32_t*)0x200000006e38 = 0x8cf;
*(uint32_t*)0x200000006e3c = 0x3ff;
*(uint32_t*)0x200000006e40 = 4;
*(uint32_t*)0x200000006e44 = 0x59c;
*(uint32_t*)0x200000006e48 = 3;
*(uint32_t*)0x200000006e4c = 0xfffffffc;
*(uint32_t*)0x200000006e50 = 0x5f2c;
*(uint32_t*)0x200000006e54 = 3;
*(uint32_t*)0x200000006e58 = 0x100;
*(uint32_t*)0x200000006e5c = 0x35b;
*(uint32_t*)0x200000006e60 = 0xbe;
*(uint32_t*)0x200000006e64 = 0x7d;
*(uint32_t*)0x200000006e68 = 0xab99;
*(uint32_t*)0x200000006e6c = 4;
*(uint32_t*)0x200000006e70 = 0x101;
*(uint32_t*)0x200000006e74 = 0;
*(uint32_t*)0x200000006e78 = 0xf76;
*(uint32_t*)0x200000006e7c = 0x8001;
*(uint32_t*)0x200000006e80 = 4;
*(uint32_t*)0x200000006e84 = 0x3ff;
*(uint32_t*)0x200000006e88 = 0xd;
*(uint32_t*)0x200000006e8c = 7;
*(uint32_t*)0x200000006e90 = 6;
*(uint32_t*)0x200000006e94 = 8;
*(uint32_t*)0x200000006e98 = 7;
*(uint32_t*)0x200000006e9c = 7;
*(uint32_t*)0x200000006ea0 = 4;
*(uint32_t*)0x200000006ea4 = 6;
*(uint32_t*)0x200000006ea8 = 0;
*(uint32_t*)0x200000006eac = 0xab45;
*(uint32_t*)0x200000006eb0 = 0x8244;
*(uint32_t*)0x200000006eb4 = 0x60000;
*(uint32_t*)0x200000006eb8 = 0xe2a;
*(uint32_t*)0x200000006ebc = 0xae8;
*(uint32_t*)0x200000006ec0 = 1;
*(uint32_t*)0x200000006ec4 = 0x20076355;
*(uint32_t*)0x200000006ec8 = 3;
*(uint32_t*)0x200000006ecc = 2;
*(uint32_t*)0x200000006ed0 = 0x10;
*(uint32_t*)0x200000006ed4 = 4;
*(uint32_t*)0x200000006ed8 = 0xa;
*(uint32_t*)0x200000006edc = 0xd;
*(uint32_t*)0x200000006ee0 = 9;
*(uint32_t*)0x200000006ee4 = 5;
*(uint32_t*)0x200000006ee8 = 1;
*(uint32_t*)0x200000006eec = 0x7ff;
*(uint32_t*)0x200000006ef0 = 0x200;
*(uint32_t*)0x200000006ef4 = 0xcb;
*(uint32_t*)0x200000006ef8 = 2;
*(uint32_t*)0x200000006efc = 7;
*(uint32_t*)0x200000006f00 = 0x80;
*(uint32_t*)0x200000006f04 = 5;
*(uint32_t*)0x200000006f08 = 4;
*(uint32_t*)0x200000006f0c = 1;
*(uint32_t*)0x200000006f10 = 0x45e;
*(uint32_t*)0x200000006f14 = 8;
*(uint32_t*)0x200000006f18 = 0x1f;
*(uint32_t*)0x200000006f1c = 4;
*(uint32_t*)0x200000006f20 = 7;
*(uint32_t*)0x200000006f24 = 0x80000001;
*(uint32_t*)0x200000006f28 = 5;
*(uint32_t*)0x200000006f2c = 0;
*(uint32_t*)0x200000006f30 = 4;
*(uint32_t*)0x200000006f34 = 0x800;
*(uint32_t*)0x200000006f38 = 0xfffffffc;
*(uint32_t*)0x200000006f3c = 7;
*(uint32_t*)0x200000006f40 = 0x81;
*(uint32_t*)0x200000006f44 = 0x6e3833b8;
*(uint32_t*)0x200000006f48 = 9;
*(uint32_t*)0x200000006f4c = 0x5520;
*(uint32_t*)0x200000006f50 = 0;
*(uint32_t*)0x200000006f54 = 0;
*(uint32_t*)0x200000006f58 = 0xe1;
*(uint32_t*)0x200000006f5c = 4;
*(uint32_t*)0x200000006f60 = 0xffffff8e;
*(uint32_t*)0x200000006f64 = 6;
*(uint32_t*)0x200000006f68 = 1;
*(uint32_t*)0x200000006f6c = 9;
*(uint32_t*)0x200000006f70 = 0x200;
*(uint32_t*)0x200000006f74 = 0x57;
*(uint32_t*)0x200000006f78 = 5;
*(uint32_t*)0x200000006f7c = 5;
*(uint32_t*)0x200000006f80 = 0xf;
*(uint32_t*)0x200000006f84 = 0;
*(uint32_t*)0x200000006f88 = 1;
*(uint32_t*)0x200000006f8c = 0;
*(uint32_t*)0x200000006f90 = 0xb91;
*(uint32_t*)0x200000006f94 = 0xfffffffa;
*(uint32_t*)0x200000006f98 = 0xf6;
*(uint32_t*)0x200000006f9c = 0x10;
*(uint32_t*)0x200000006fa0 = 0xd;
*(uint32_t*)0x200000006fa4 = 3;
*(uint32_t*)0x200000006fa8 = 1;
*(uint32_t*)0x200000006fac = 5;
*(uint32_t*)0x200000006fb0 = 9;
*(uint32_t*)0x200000006fb4 = 4;
*(uint32_t*)0x200000006fb8 = 5;
*(uint32_t*)0x200000006fbc = 0xffffff44;
*(uint32_t*)0x200000006fc0 = 3;
*(uint32_t*)0x200000006fc4 = 4;
*(uint32_t*)0x200000006fc8 = 4;
*(uint32_t*)0x200000006fcc = 0x19d;
*(uint32_t*)0x200000006fd0 = 4;
*(uint32_t*)0x200000006fd4 = 1;
*(uint32_t*)0x200000006fd8 = 0x1e0;
*(uint32_t*)0x200000006fdc = 3;
*(uint32_t*)0x200000006fe0 = 3;
*(uint32_t*)0x200000006fe4 = 6;
*(uint32_t*)0x200000006fe8 = 9;
*(uint32_t*)0x200000006fec = 0x10001;
*(uint32_t*)0x200000006ff0 = 0xf1;
*(uint32_t*)0x200000006ff4 = 9;
*(uint32_t*)0x200000006ff8 = 5;
*(uint32_t*)0x200000006ffc = 3;
*(uint32_t*)0x200000007000 = 2;
*(uint32_t*)0x200000007004 = 7;
*(uint32_t*)0x200000007008 = 0xd0;
*(uint32_t*)0x20000000700c = 5;
*(uint32_t*)0x200000007010 = 2;
*(uint32_t*)0x200000007014 = 0xffff;
*(uint32_t*)0x200000007018 = 8;
*(uint32_t*)0x20000000701c = 5;
*(uint32_t*)0x200000007020 = 0x4b;
*(uint32_t*)0x200000007024 = 0x6168;
*(uint32_t*)0x200000007028 = 0xd;
*(uint32_t*)0x20000000702c = 0x1ff;
*(uint32_t*)0x200000007030 = 0x80000000;
*(uint32_t*)0x200000007034 = 0x10001;
*(uint32_t*)0x200000007038 = 9;
*(uint32_t*)0x20000000703c = 3;
*(uint32_t*)0x200000007040 = 0xff;
*(uint32_t*)0x200000007044 = 2;
*(uint32_t*)0x200000007048 = 0xc;
*(uint32_t*)0x20000000704c = 9;
*(uint32_t*)0x200000007050 = 0xd75;
*(uint32_t*)0x200000007054 = 5;
*(uint32_t*)0x200000007058 = 9;
*(uint32_t*)0x20000000705c = 3;
*(uint32_t*)0x200000007060 = 6;
*(uint32_t*)0x200000007064 = 1;
*(uint32_t*)0x200000007068 = 0xb1;
*(uint32_t*)0x20000000706c = 6;
*(uint32_t*)0x200000007070 = 3;
*(uint32_t*)0x200000007074 = 0xa7b;
*(uint32_t*)0x200000007078 = 7;
*(uint32_t*)0x20000000707c = 0;
*(uint32_t*)0x200000007080 = 6;
*(uint32_t*)0x200000007084 = 0xfffffff7;
*(uint32_t*)0x200000007088 = 6;
*(uint32_t*)0x20000000708c = 0;
*(uint32_t*)0x200000007090 = 0xfffffffd;
*(uint32_t*)0x200000007094 = 5;
*(uint32_t*)0x200000007098 = 0;
*(uint32_t*)0x20000000709c = 0x7f;
*(uint32_t*)0x2000000070a0 = 0xe;
*(uint32_t*)0x2000000070a4 = 8;
*(uint32_t*)0x2000000070a8 = 2;
*(uint32_t*)0x2000000070ac = 1;
*(uint32_t*)0x2000000070b0 = 8;
*(uint32_t*)0x2000000070b4 = 0xc1b;
*(uint32_t*)0x2000000070b8 = 0x401;
*(uint32_t*)0x2000000070bc = 7;
*(uint32_t*)0x2000000070c0 = 9;
*(uint32_t*)0x2000000070c4 = 0x5a;
*(uint32_t*)0x2000000070c8 = 0xffff;
*(uint32_t*)0x2000000070cc = 0x10000;
*(uint32_t*)0x2000000070d0 = 9;
*(uint32_t*)0x2000000070d4 = 8;
*(uint32_t*)0x2000000070d8 = 0x152f;
*(uint32_t*)0x2000000070dc = 0xfffffff4;
*(uint32_t*)0x2000000070e0 = 0xfff;
*(uint32_t*)0x2000000070e4 = 9;
*(uint32_t*)0x2000000070e8 = 6;
*(uint32_t*)0x2000000070ec = 5;
*(uint32_t*)0x2000000070f0 = 9;
*(uint32_t*)0x2000000070f4 = 0x1cf;
*(uint32_t*)0x2000000070f8 = 0x10000;
*(uint32_t*)0x2000000070fc = 6;
*(uint32_t*)0x200000007100 = 9;
*(uint32_t*)0x200000007104 = 0x4a87;
*(uint32_t*)0x200000007108 = 6;
*(uint32_t*)0x20000000710c = 6;
*(uint32_t*)0x200000007110 = 0xfffffff8;
*(uint32_t*)0x200000007114 = 5;
*(uint32_t*)0x200000007118 = 9;
*(uint32_t*)0x20000000711c = 7;
*(uint32_t*)0x200000007120 = 4;
*(uint32_t*)0x200000007124 = 0x3b452a9;
*(uint32_t*)0x200000007128 = 0xf;
*(uint32_t*)0x20000000712c = 0x1400000;
*(uint32_t*)0x200000007130 = 6;
*(uint32_t*)0x200000007134 = 5;
*(uint32_t*)0x200000007138 = 0x100;
*(uint32_t*)0x20000000713c = 6;
*(uint32_t*)0x200000007140 = 5;
*(uint32_t*)0x200000007144 = 0x40;
*(uint32_t*)0x200000007148 = 0x10;
*(uint32_t*)0x20000000714c = 0x3ff;
*(uint32_t*)0x200000007150 = 1;
*(uint32_t*)0x200000007154 = 3;
*(uint32_t*)0x200000007158 = 0xfffffffb;
*(uint32_t*)0x20000000715c = 4;
*(uint32_t*)0x200000007160 = 7;
*(uint32_t*)0x200000007164 = 0xa87;
*(uint32_t*)0x200000007168 = 7;
*(uint32_t*)0x20000000716c = 5;
*(uint32_t*)0x200000007170 = 0x3ff;
*(uint32_t*)0x200000007174 = 0x8000;
*(uint32_t*)0x200000007178 = 0x10000;
*(uint32_t*)0x20000000717c = 5;
*(uint32_t*)0x200000007180 = 5;
*(uint32_t*)0x200000007184 = 0xab2b;
*(uint32_t*)0x200000007188 = 2;
*(uint32_t*)0x20000000718c = 3;
*(uint32_t*)0x200000007190 = 7;
*(uint32_t*)0x200000007194 = 0x6ec6;
*(uint32_t*)0x200000007198 = 4;
*(uint32_t*)0x20000000719c = 8;
*(uint32_t*)0x2000000071a0 = 0xc9;
*(uint32_t*)0x2000000071a4 = 3;
*(uint32_t*)0x2000000071a8 = 0x723bdbde;
*(uint32_t*)0x2000000071ac = 0x757f157a;
*(uint32_t*)0x2000000071b0 = 9;
*(uint32_t*)0x2000000071b4 = 0x3ff;
*(uint32_t*)0x2000000071b8 = 2;
*(uint32_t*)0x2000000071bc = 9;
*(uint32_t*)0x2000000071c0 = 2;
*(uint32_t*)0x2000000071c4 = 9;
*(uint32_t*)0x2000000071c8 = 0x200;
*(uint32_t*)0x2000000071cc = 0x40;
*(uint32_t*)0x2000000071d0 = 0x69;
*(uint32_t*)0x2000000071d4 = 0;
*(uint32_t*)0x2000000071d8 = 0x84;
*(uint32_t*)0x2000000071dc = 9;
*(uint32_t*)0x2000000071e0 = 4;
*(uint32_t*)0x2000000071e4 = 5;
*(uint32_t*)0x2000000071e8 = 7;
*(uint32_t*)0x2000000071ec = 0x1000;
*(uint32_t*)0x2000000071f0 = 0x6f;
*(uint32_t*)0x2000000071f4 = 0xb;
*(uint32_t*)0x2000000071f8 = 0x5a4;
*(uint32_t*)0x2000000071fc = 5;
*(uint32_t*)0x200000007200 = 3;
*(uint32_t*)0x200000007204 = 6;
*(uint32_t*)0x200000007208 = 0x80000000;
*(uint32_t*)0x20000000720c = 0x7fff;
*(uint32_t*)0x200000007210 = 8;
*(uint32_t*)0x200000007214 = 4;
*(uint32_t*)0x200000007218 = 0xb;
*(uint32_t*)0x20000000721c = 0x7f;
*(uint32_t*)0x200000007220 = 0xe528;
*(uint32_t*)0x200000007224 = 2;
*(uint32_t*)0x200000007228 = 2;
*(uint32_t*)0x20000000722c = -1;
*(uint32_t*)0x200000007230 = 3;
*(uint32_t*)0x200000007234 = 0;
*(uint16_t*)0x200000007238 = 4;
*(uint16_t*)0x20000000723a = 6;
*(uint16_t*)0x20000000723c = 0xc;
*(uint16_t*)0x20000000723e = 7;
*(uint32_t*)0x200000007240 = 1;
*(uint32_t*)0x200000007244 = 0;
*(uint16_t*)0x200000007248 = 0xc;
*(uint16_t*)0x20000000724a = 8;
*(uint32_t*)0x20000000724c = 0;
*(uint32_t*)0x200000007250 = 2;
*(uint16_t*)0x200000007254 = 0x2c;
STORE_BY_BITMASK(uint16_t, , 0x200000007256, 1, 0, 14);
STORE_BY_BITMASK(uint16_t, , 0x200000007257, 0, 6, 1);
STORE_BY_BITMASK(uint16_t, , 0x200000007257, 0, 7, 1);
*(uint16_t*)0x200000007258 = 7;
*(uint16_t*)0x20000000725a = 1;
memcpy((void*)0x20000000725c, "ct\000", 3);
*(uint16_t*)0x200000007260 = 4;
STORE_BY_BITMASK(uint16_t, , 0x200000007262, 2, 0, 14);
STORE_BY_BITMASK(uint16_t, , 0x200000007263, 0, 6, 1);
STORE_BY_BITMASK(uint16_t, , 0x200000007263, 1, 7, 1);
*(uint16_t*)0x200000007264 = 4;
*(uint16_t*)0x200000007266 = 6;
*(uint16_t*)0x200000007268 = 0xc;
*(uint16_t*)0x20000000726a = 7;
*(uint32_t*)0x20000000726c = 1;
*(uint32_t*)0x200000007270 = 0;
*(uint16_t*)0x200000007274 = 0xc;
*(uint16_t*)0x200000007276 = 8;
*(uint32_t*)0x200000007278 = 2;
*(uint32_t*)0x20000000727c = 1;
*(uint16_t*)0x200000007280 = 0x30;
STORE_BY_BITMASK(uint16_t, , 0x200000007282, 1, 0, 14);
STORE_BY_BITMASK(uint16_t, , 0x200000007283, 0, 6, 1);
STORE_BY_BITMASK(uint16_t, , 0x200000007283, 0, 7, 1);
*(uint16_t*)0x200000007284 = 9;
*(uint16_t*)0x200000007286 = 1;
memcpy((void*)0x200000007288, "gact\000", 5);
*(uint16_t*)0x200000007290 = 4;
STORE_BY_BITMASK(uint16_t, , 0x200000007292, 2, 0, 14);
STORE_BY_BITMASK(uint16_t, , 0x200000007293, 0, 6, 1);
STORE_BY_BITMASK(uint16_t, , 0x200000007293, 1, 7, 1);
*(uint16_t*)0x200000007294 = 4;
*(uint16_t*)0x200000007296 = 6;
*(uint16_t*)0x200000007298 = 0xc;
*(uint16_t*)0x20000000729a = 7;
*(uint32_t*)0x20000000729c = 1;
*(uint32_t*)0x2000000072a0 = 0;
*(uint16_t*)0x2000000072a4 = 0xc;
*(uint16_t*)0x2000000072a6 = 8;
*(uint32_t*)0x2000000072a8 = 1;
*(uint32_t*)0x2000000072ac = 0;
*(uint64_t*)0x200000000148 = 0x1230;
*(uint64_t*)0x200000006058 = 1;
*(uint64_t*)0x200000006060 = 0;
*(uint64_t*)0x200000006068 = 0;
*(uint32_t*)0x200000006070 = 1;
syscall(__NR_sendmsg, /*fd=*/(intptr_t)-1, /*msg=*/0x200000006040ul, /*f=MSG_ZEROCOPY|MSG_BATCH|MSG_EOR|0x1000*/0x4041080ul);
// io_uring_enter arguments: [
// fd: fd_io_uring (resource)
// to_submit: int32 = 0x1203 (4 bytes)
// min_complete: int32 = 0x109c (4 bytes)
// flags: io_uring_enter_flags = 0x16 (8 bytes)
// sigmask: nil
// size: len = 0xffffffffffffff02 (8 bytes)
// ]
syscall(__NR_io_uring_enter, /*fd=*/r[0], /*to_submit=*/0x1203, /*min_complete=*/0x109c, /*flags=IORING_ENTER_REGISTERED_RING|IORING_ENTER_SQ_WAIT|IORING_ENTER_SQ_WAKEUP*/0x16ul, /*sigmask=*/0ul, /*size=*/0xffffffffffffff02ul);
return 0;
}
Reply: Based on the analysis of the bug report and the provided reproducer, here is the assessment of the security impact:
**Bug Analysis:**
The bug report indicates a memory leak of a `struct file` object (size 176 bytes) allocated in `alloc_empty_file` during the `path_openat` syscall. The reproducer triggers this by opening a Video4Linux device node (`/dev/vbi#`, which is handled by the `vivid` test driver) and subsequently interacting with `io_uring` and `sendmsg`.
Because the `struct file` reference count is incremented but not properly decremented (or the file is removed from the fd table without calling `fput`), the kernel fails to free the memory associated with the file object when the process exits.
**Exploitability:**
Memory leaks of this nature (where an object is simply abandoned without being freed) do not result in memory corruption, use-after-free, out-of-bounds accesses, or control-flow hijacking. Therefore, this bug is **not exploitable** for privilege escalation or arbitrary code execution.
**Denial of Service (DoS):**
An attacker can repeatedly trigger this bug to leak `struct file` objects. Over time, this will consume a significant amount of kernel memory (slab memory) and potentially exhaust the system-wide limit on open files (`fs.file-max`), leading to a Denial of Service (OOM conditions or inability for other processes to open files).
**Accessibility:**
The bug can be triggered by a standard, unprivileged local user process. The reproducer uses basic syscalls (`open`, `mmap`, `io_uring_setup`, `sendmsg`) that do not require `CAP_SYS_ADMIN` or any other special capabilities. It is also accessible from within user namespaces.
**Other Triggers:**
This is a local syscall-based vulnerability. It cannot be triggered remotely via network traffic (Ethernet or otherwise), nor is it related to parsing malicious filesystems, peripheral devices, or virtualization boundaries (VM Guest/Host).
|
| 6/2 |
2026/06/12 22:20 |
llm |
expert |
0m
Model:
Tokens:
input: 66602
output: 19
thoughts: 969
Thoughts: **Analyzing a Memory Leak in the io_uring Subsystem**
Okay, so I've got this memory leak report, and it looks like a classic unreferenced object issue. The kernel is reporting an object of size 176 bytes as leaked, and the backtrace points to `alloc_empty_file`, which is concerning because that means a `struct file` is being leaked.
The reproducer sequence is interesting: `io_uring_setup`, `syz_open_dev`, `sendmsg`, `io_uring_enter`. `syz_open_dev` is key here – it's opening `/dev/vbi#`, a V4L2 device. And `io_uring` is being used right after. We know that `io_uring` can attach files and can use `openat`. The leak is happening through the `path_openat` path, meaning a file is opened but not closed, or a reference count is lost. This is where `io_uring` comes in. It's the only subsystem in this reproducer that could be doing that. So the focus should be `io_uring` and how it handles files.
Let's look more closely at the `io_uring_setup` flags. The reproducer is using a combination of flags (0x1c080). This includes flags for both polling and non-polling setups. I'll need to check the exact implications of those flags, specifically related to file registration or open operations within `io_uring`. I'll need to dive into the `io_uring` code, especially around how it handles file descriptors and handles open/close semantics in the context of these specific flags. I'll want to check `include/uapi/linux/io_uring.h` to see how those flags affect `io_uring`'s file handling.
|
| 7/2 |
2026/06/12 22:20 |
tool |
grepper |
0m
Args: map[Expression:IORING_SETUP_]
Results: map[Output:
Full output is too long, showing 500 out of 919 lines.
Use more precise expression if possible.
Documentation/networking/iou-zcrx.rst=74=Create an io_uring instance with the following required setup flags::
Documentation/networking/iou-zcrx.rst-75-
Documentation/networking/iou-zcrx.rst:76: IORING_SETUP_SINGLE_ISSUER
Documentation/networking/iou-zcrx.rst:77: IORING_SETUP_DEFER_TASKRUN
Documentation/networking/iou-zcrx.rst:78: IORING_SETUP_CQE32 or IORING_SETUP_CQE_MIXED
Documentation/networking/iou-zcrx.rst-79-
--
include/linux/io_uring_types.h=14=enum {
--
include/linux/io_uring_types.h-19- * Must not be used with requests generating more than one CQE.
include/linux/io_uring_types.h:20: * It's also ignored unless IORING_SETUP_DEFER_TASKRUN is set.
include/linux/io_uring_types.h-21- */
--
include/linux/io_uring_types.h=293=struct io_ring_ctx {
--
include/linux/io_uring_types.h-341- * ->iopoll_list is protected by the ctx->uring_lock for
include/linux/io_uring_types.h:342: * io_uring instances that don't use IORING_SETUP_SQPOLL.
include/linux/io_uring_types.h-343- * For SQPOLL, only the single threaded io_sq_thread() will
--
include/trace/events/io_uring.h=323=TP_PROTO(struct io_ring_ctx *ctx, void *req, struct io_uring_cqe *cqe),
--
include/trace/events/io_uring.h-342- __entry->cflags = cqe->flags;
include/trace/events/io_uring.h:343: __entry->extra1 = ctx->flags & IORING_SETUP_CQE32 || cqe->flags & IORING_CQE_F_32 ? cqe->big_cqe[0] : 0;
include/trace/events/io_uring.h:344: __entry->extra2 = ctx->flags & IORING_SETUP_CQE32 || cqe->flags & IORING_CQE_F_32 ? cqe->big_cqe[1] : 0;
include/trace/events/io_uring.h-345- ),
--
include/trace/events/io_uring.h=364=TRACE_EVENT(io_uring_submit_req,
--
include/trace/events/io_uring.h-386- __entry->flags = (__force unsigned long long) req->flags;
include/trace/events/io_uring.h:387: __entry->sq_thread = req->ctx->flags & IORING_SETUP_SQPOLL;
include/trace/events/io_uring.h-388-
--
include/uapi/linux/io_uring.h=32=struct io_uring_sqe {
--
include/uapi/linux/io_uring.h-114- /*
include/uapi/linux/io_uring.h:115: * If the ring is initialized with IORING_SETUP_SQE128, then
include/uapi/linux/io_uring.h-116- * this field is used for 80 bytes of arbitrary command data
--
include/uapi/linux/io_uring.h=143=enum io_uring_sqe_flags_bit {
--
include/uapi/linux/io_uring.h-173- */
include/uapi/linux/io_uring.h:174:#define IORING_SETUP_IOPOLL (1U << 0) /* io_context is polled */
include/uapi/linux/io_uring.h:175:#define IORING_SETUP_SQPOLL (1U << 1) /* SQ poll thread */
include/uapi/linux/io_uring.h:176:#define IORING_SETUP_SQ_AFF (1U << 2) /* sq_thread_cpu is valid */
include/uapi/linux/io_uring.h:177:#define IORING_SETUP_CQSIZE (1U << 3) /* app defines CQ size */
include/uapi/linux/io_uring.h:178:#define IORING_SETUP_CLAMP (1U << 4) /* clamp SQ/CQ ring sizes */
include/uapi/linux/io_uring.h:179:#define IORING_SETUP_ATTACH_WQ (1U << 5) /* attach to existing wq */
include/uapi/linux/io_uring.h:180:#define IORING_SETUP_R_DISABLED (1U << 6) /* start with ring disabled */
include/uapi/linux/io_uring.h:181:#define IORING_SETUP_SUBMIT_ALL (1U << 7) /* continue submit on error */
include/uapi/linux/io_uring.h-182-/*
--
include/uapi/linux/io_uring.h-188- */
include/uapi/linux/io_uring.h:189:#define IORING_SETUP_COOP_TASKRUN (1U << 8)
include/uapi/linux/io_uring.h-190-/*
--
include/uapi/linux/io_uring.h-195- */
include/uapi/linux/io_uring.h:196:#define IORING_SETUP_TASKRUN_FLAG (1U << 9)
include/uapi/linux/io_uring.h:197:#define IORING_SETUP_SQE128 (1U << 10) /* SQEs are 128 byte */
include/uapi/linux/io_uring.h:198:#define IORING_SETUP_CQE32 (1U << 11) /* CQEs are 32 byte */
include/uapi/linux/io_uring.h-199-/*
--
include/uapi/linux/io_uring.h-201- */
include/uapi/linux/io_uring.h:202:#define IORING_SETUP_SINGLE_ISSUER (1U << 12)
include/uapi/linux/io_uring.h-203-
--
include/uapi/linux/io_uring.h-208- */
include/uapi/linux/io_uring.h:209:#define IORING_SETUP_DEFER_TASKRUN (1U << 13)
include/uapi/linux/io_uring.h-210-
--
include/uapi/linux/io_uring.h-213- */
include/uapi/linux/io_uring.h:214:#define IORING_SETUP_NO_MMAP (1U << 14)
include/uapi/linux/io_uring.h-215-
--
include/uapi/linux/io_uring.h-220- */
include/uapi/linux/io_uring.h:221:#define IORING_SETUP_REGISTERED_FD_ONLY (1U << 15)
include/uapi/linux/io_uring.h-222-
--
include/uapi/linux/io_uring.h-225- */
include/uapi/linux/io_uring.h:226:#define IORING_SETUP_NO_SQARRAY (1U << 16)
include/uapi/linux/io_uring.h-227-
include/uapi/linux/io_uring.h-228-/* Use hybrid poll in iopoll process */
include/uapi/linux/io_uring.h:229:#define IORING_SETUP_HYBRID_IOPOLL (1U << 17)
include/uapi/linux/io_uring.h-230-
--
include/uapi/linux/io_uring.h-234- */
include/uapi/linux/io_uring.h:235:#define IORING_SETUP_CQE_MIXED (1U << 18)
include/uapi/linux/io_uring.h-236-
--
include/uapi/linux/io_uring.h-240- */
include/uapi/linux/io_uring.h:241:#define IORING_SETUP_SQE_MIXED (1U << 19)
include/uapi/linux/io_uring.h-242-
--
include/uapi/linux/io_uring.h-248- *
include/uapi/linux/io_uring.h:249: * It requires IORING_SETUP_NO_SQARRAY and is incompatible with
include/uapi/linux/io_uring.h:250: * IORING_SETUP_SQPOLL. The user must also never change the SQ head and tail
include/uapi/linux/io_uring.h-251- * values and keep it set to 0. Any other value is undefined behaviour.
include/uapi/linux/io_uring.h-252- */
include/uapi/linux/io_uring.h:253:#define IORING_SETUP_SQ_REWIND (1U << 20)
include/uapi/linux/io_uring.h-254-
--
include/uapi/linux/io_uring.h=500=struct io_uring_cqe {
--
include/uapi/linux/io_uring.h-505- /*
include/uapi/linux/io_uring.h:506: * If the ring is initialized with IORING_SETUP_CQE32, then this field
include/uapi/linux/io_uring.h-507- * contains 16-bytes of padding, doubling the size of the CQE.
--
include/uapi/linux/io_uring/query.h=31=struct io_uring_query_opcode {
--
include/uapi/linux/io_uring/query.h-37- __u64 feature_flags;
include/uapi/linux/io_uring/query.h:38: /* Bitmask of all supported IORING_SETUP_* flags */
include/uapi/linux/io_uring/query.h-39- __u64 ring_setup_flags;
--
io_uring/bpf-ops.c=159=static int io_install_bpf(struct io_ring_ctx *ctx, struct io_uring_bpf_ops *ops)
io_uring/bpf-ops.c-160-{
io_uring/bpf-ops.c:161: if (ctx->flags & (IORING_SETUP_SQPOLL | IORING_SETUP_IOPOLL))
io_uring/bpf-ops.c-162- return -EOPNOTSUPP;
io_uring/bpf-ops.c:163: if (!(ctx->flags & IORING_SETUP_DEFER_TASKRUN))
io_uring/bpf-ops.c-164- return -EOPNOTSUPP;
--
io_uring/cancel.c=515=__cold bool io_uring_try_cancel_requests(struct io_ring_ctx *ctx,
--
io_uring/cancel.c-523- /* set it so io_req_local_work_add() would wake us up */
io_uring/cancel.c:524: if (ctx->flags & IORING_SETUP_DEFER_TASKRUN) {
io_uring/cancel.c-525- atomic_set(&ctx->cq_wait_nr, 1);
--
io_uring/cancel.c-545- /* SQPOLL thread does its own polling */
io_uring/cancel.c:546: if ((!(ctx->flags & IORING_SETUP_SQPOLL) && cancel_all) ||
io_uring/cancel.c-547- is_sqpoll_thread) {
--
io_uring/cancel.c-554-
io_uring/cancel.c:555: if ((ctx->flags & IORING_SETUP_DEFER_TASKRUN) &&
io_uring/cancel.c-556- io_allowed_defer_tw_run(ctx))
--
io_uring/fdinfo.c=60=static void __io_uring_show_fdinfo(struct io_ring_ctx *ctx, struct seq_file *m)
--
io_uring/fdinfo.c-74-
io_uring/fdinfo.c:75: if (ctx->flags & IORING_SETUP_SQE128)
io_uring/fdinfo.c-76- sq_shift = 1;
--
io_uring/fdinfo.c-100-
io_uring/fdinfo.c:101: if (ctx->flags & IORING_SETUP_NO_SQARRAY)
io_uring/fdinfo.c-102- sq_idx = entry & sq_mask;
--
io_uring/fdinfo.c-115- } else if (io_issue_defs[opcode].is_128) {
io_uring/fdinfo.c:116: if (!(ctx->flags & IORING_SETUP_SQE_MIXED)) {
io_uring/fdinfo.c-117- seq_printf(m,
--
io_uring/fdinfo.c-159- cqe = &r->cqes[(cq_head & cq_mask)];
io_uring/fdinfo.c:160: if (cqe->flags & IORING_CQE_F_32 || ctx->flags & IORING_SETUP_CQE32)
io_uring/fdinfo.c-161- cqe32 = true;
--
io_uring/fdinfo.c-176-
io_uring/fdinfo.c:177: if (ctx->flags & IORING_SETUP_SQPOLL) {
io_uring/fdinfo.c-178- struct io_sq_data *sq = ctx->sq_data;
--
io_uring/io_uring.c-24- *
io_uring/io_uring.c:25: * When using the SQ poll thread (IORING_SETUP_SQPOLL), the application
io_uring/io_uring.c-26- * needs to check the SQ flags for IORING_SQ_NEED_WAKEUP *after*
--
io_uring/io_uring.c=523=static void __io_cqring_overflow_flush(struct io_ring_ctx *ctx, bool dying)
--
io_uring/io_uring.c-540- if (ocqe->cqe.flags & IORING_CQE_F_32 ||
io_uring/io_uring.c:541: ctx->flags & IORING_SETUP_CQE32) {
io_uring/io_uring.c-542- is_cqe32 = true;
--
io_uring/io_uring.c-544- }
io_uring/io_uring.c:545: if (ctx->flags & IORING_SETUP_CQE32)
io_uring/io_uring.c-546- is_cqe32 = false;
--
io_uring/io_uring.c=660=static struct io_overflow_cqe *io_alloc_ocqe(struct io_ring_ctx *ctx,
--
io_uring/io_uring.c-667-
io_uring/io_uring.c:668: if (cqe->flags & IORING_CQE_F_32 || ctx->flags & IORING_SETUP_CQE32) {
io_uring/io_uring.c-669- is_cqe32 = true;
--
io_uring/io_uring.c=726=bool io_cqe_cache_refill(struct io_ring_ctx *ctx, bool overflow, bool cqe32)
--
io_uring/io_uring.c-755-
io_uring/io_uring.c:756: if (ctx->flags & IORING_SETUP_CQE32) {
io_uring/io_uring.c-757- off <<= 1;
--
io_uring/io_uring.c=766=static bool io_fill_cqe_aux32(struct io_ring_ctx *ctx,
--
io_uring/io_uring.c-770-
io_uring/io_uring.c:771: if (WARN_ON_ONCE(!(ctx->flags & (IORING_SETUP_CQE32|IORING_SETUP_CQE_MIXED))))
io_uring/io_uring.c-772- return false;
--
io_uring/io_uring.c=1181=__cold void io_iopoll_try_reap_events(struct io_ring_ctx *ctx)
io_uring/io_uring.c-1182-{
io_uring/io_uring.c:1183: if (!(ctx->flags & IORING_SETUP_IOPOLL))
io_uring/io_uring.c-1184- return;
--
io_uring/io_uring.c-1203-
io_uring/io_uring.c:1204: if (ctx->flags & IORING_SETUP_DEFER_TASKRUN)
io_uring/io_uring.c-1205- io_move_task_work_from_local(ctx);
--
io_uring/io_uring.c=1287=static void io_iopoll_req_issued(struct io_kiocb *req, unsigned int issue_flags)
--
io_uring/io_uring.c-1314- /*
io_uring/io_uring.c:1315: * If IORING_SETUP_SQPOLL is enabled, sqes are either handle
io_uring/io_uring.c-1316- * in sq thread task context or in io worker task context. If
--
io_uring/io_uring.c-1319- */
io_uring/io_uring.c:1320: if ((ctx->flags & IORING_SETUP_SQPOLL) &&
io_uring/io_uring.c-1321- wq_has_sleeper(&ctx->sq_data->wait))
--
io_uring/io_uring.c=1734=static int io_init_req(struct io_ring_ctx *ctx, struct io_kiocb *req,
--
io_uring/io_uring.c-1759- def = &io_issue_defs[req->opcode];
io_uring/io_uring.c:1760: if (def->is_128 && !(ctx->flags & IORING_SETUP_SQE128)) {
io_uring/io_uring.c-1761- /*
--
io_uring/io_uring.c-1764- */
io_uring/io_uring.c:1765: if (!(ctx->flags & IORING_SETUP_SQE_MIXED) || *left < 2 ||
io_uring/io_uring.c-1766- (unsigned)(sqe - ctx->sq_sqes) >= ctx->sq_entries - 1)
--
io_uring/io_uring.c-1810- return io_init_fail_req(req, -EINVAL);
io_uring/io_uring.c:1811: if (!def->iopoll && (ctx->flags & IORING_SETUP_IOPOLL))
io_uring/io_uring.c-1812- return io_init_fail_req(req, -EINVAL);
--
io_uring/io_uring.c=1970=static void io_commit_sqring(struct io_ring_ctx *ctx)
--
io_uring/io_uring.c-1973-
io_uring/io_uring.c:1974: if (ctx->flags & IORING_SETUP_SQ_REWIND) {
io_uring/io_uring.c-1975- ctx->cached_sq_head = 0;
--
io_uring/io_uring.c=1994=static bool io_get_sqe(struct io_ring_ctx *ctx, const struct io_uring_sqe **sqe)
--
io_uring/io_uring.c-1999- if (static_branch_unlikely(&io_key_has_sqarray.key) &&
io_uring/io_uring.c:2000: (!(ctx->flags & IORING_SETUP_NO_SQARRAY))) {
io_uring/io_uring.c-2001- head = READ_ONCE(ctx->sq_array[head]);
--
io_uring/io_uring.c-2019- /* double index for 128-byte SQEs, twice as long */
io_uring/io_uring.c:2020: if (ctx->flags & IORING_SETUP_SQE128)
io_uring/io_uring.c-2021- head <<= 1;
--
io_uring/io_uring.c=2026=int io_submit_sqes(struct io_ring_ctx *ctx, unsigned int nr)
--
io_uring/io_uring.c-2032-
io_uring/io_uring.c:2033: if (ctx->flags & IORING_SETUP_SQ_REWIND)
io_uring/io_uring.c-2034- entries = ctx->sq_entries;
--
io_uring/io_uring.c-2058- * Continue submitting even for sqe failure if the
io_uring/io_uring.c:2059: * ring was setup with IORING_SETUP_SUBMIT_ALL
io_uring/io_uring.c-2060- */
io_uring/io_uring.c-2061- if (unlikely(io_submit_sqe(ctx, req, sqe, &left)) &&
io_uring/io_uring.c:2062: !(ctx->flags & IORING_SETUP_SUBMIT_ALL)) {
io_uring/io_uring.c-2063- left--;
--
io_uring/io_uring.c=2091=static int rings_size(unsigned int flags, unsigned int sq_entries,
--
io_uring/io_uring.c-2097-
io_uring/io_uring.c:2098: if (flags & IORING_SETUP_CQE_MIXED) {
io_uring/io_uring.c-2099- if (cq_entries < 2)
--
io_uring/io_uring.c-2101- }
io_uring/io_uring.c:2102: if (flags & IORING_SETUP_SQE_MIXED) {
io_uring/io_uring.c-2103- if (sq_entries < 2)
--
io_uring/io_uring.c-2109- sqe_size = sizeof(struct io_uring_sqe);
io_uring/io_uring.c:2110: if (flags & IORING_SETUP_SQE128)
io_uring/io_uring.c-2111- sqe_size *= 2;
--
io_uring/io_uring.c-2117- off = struct_size(rings, cqes, cq_entries);
io_uring/io_uring.c:2118: if (flags & IORING_SETUP_CQE32)
io_uring/io_uring.c-2119- off = size_mul(off, 2);
--
io_uring/io_uring.c-2128-
io_uring/io_uring.c:2129: if (!(flags & IORING_SETUP_NO_SQARRAY)) {
io_uring/io_uring.c-2130- size_t sq_array_size;
--
io_uring/io_uring.c=2167=static __cold void io_ring_ctx_free(struct io_ring_ctx *ctx)
--
io_uring/io_uring.c-2194-
io_uring/io_uring.c:2195: if (!(ctx->flags & IORING_SETUP_NO_SQARRAY))
io_uring/io_uring.c-2196- static_branch_slow_dec_deferred(&io_key_has_sqarray);
--
io_uring/io_uring.c=2321=static __cold void io_ring_exit_work(struct work_struct *work)
--
io_uring/io_uring.c-2348- do {
io_uring/io_uring.c:2349: if (ctx->flags & IORING_SETUP_DEFER_TASKRUN)
io_uring/io_uring.c-2350- io_move_task_work_from_local(ctx);
--
io_uring/io_uring.c-2418- /* pairs with RCU read section in io_req_local_work_add() */
io_uring/io_uring.c:2419: if (ctx->flags & IORING_SETUP_DEFER_TASKRUN)
io_uring/io_uring.c-2420- synchronize_rcu();
--
io_uring/io_uring.c=2600=SYSCALL_DEFINE6(io_uring_enter, unsigned int, fd, u32, to_submit,
--
io_uring/io_uring.c-2616- /*
io_uring/io_uring.c:2617: * Keep IORING_SETUP_R_DISABLED check before submitter_task load
io_uring/io_uring.c-2618- * in io_uring_add_tctx_node() -> __io_uring_add_tctx_node_from_submit()
io_uring/io_uring.c-2619- */
io_uring/io_uring.c:2620: if (unlikely(smp_load_acquire(&ctx->flags) & IORING_SETUP_R_DISABLED))
io_uring/io_uring.c-2621- goto out;
--
io_uring/io_uring.c-2633- ret = 0;
io_uring/io_uring.c:2634: if (ctx->flags & IORING_SETUP_SQPOLL) {
io_uring/io_uring.c-2635- if (unlikely(ctx->sq_data->thread == NULL)) {
--
io_uring/io_uring.c-2662- */
io_uring/io_uring.c:2663: if (ctx->flags & IORING_SETUP_DEFER_TASKRUN)
io_uring/io_uring.c-2664- (void)io_run_local_work_locked(ctx, min_complete);
--
io_uring/io_uring.c=2731=static __cold int io_allocate_scq_urings(struct io_ring_ctx *ctx,
--
io_uring/io_uring.c-2745- rd.size = PAGE_ALIGN(rl->rings_size);
io_uring/io_uring.c:2746: if (ctx->flags & IORING_SETUP_NO_MMAP) {
io_uring/io_uring.c-2747- rd.user_addr = p->cq_off.user_addr;
--
io_uring/io_uring.c-2754- rcu_assign_pointer(ctx->rings_rcu, rings);
io_uring/io_uring.c:2755: if (!(ctx->flags & IORING_SETUP_NO_SQARRAY))
io_uring/io_uring.c-2756- ctx->sq_array = (u32 *)((char *)rings + rl->sq_array_offset);
--
io_uring/io_uring.c-2759- rd.size = PAGE_ALIGN(rl->sq_size);
io_uring/io_uring.c:2760: if (ctx->flags & IORING_SETUP_NO_MMAP) {
io_uring/io_uring.c-2761- rd.user_addr = p->sq_off.user_addr;
--
io_uring/io_uring.c=2802=static int io_uring_sanitise_params(struct io_uring_params *p)
--
io_uring/io_uring.c-2805-
io_uring/io_uring.c:2806: if (flags & ~IORING_SETUP_FLAGS)
io_uring/io_uring.c-2807- return -EINVAL;
io_uring/io_uring.c-2808-
io_uring/io_uring.c:2809: if (flags & IORING_SETUP_SQ_REWIND) {
io_uring/io_uring.c:2810: if ((flags & IORING_SETUP_SQPOLL) ||
io_uring/io_uring.c:2811: !(flags & IORING_SETUP_NO_SQARRAY))
io_uring/io_uring.c-2812- return -EINVAL;
--
io_uring/io_uring.c-2815- /* There is no way to mmap rings without a real fd */
io_uring/io_uring.c:2816: if ((flags & IORING_SETUP_REGISTERED_FD_ONLY) &&
io_uring/io_uring.c:2817: !(flags & IORING_SETUP_NO_MMAP))
io_uring/io_uring.c-2818- return -EINVAL;
io_uring/io_uring.c-2819-
io_uring/io_uring.c:2820: if (flags & IORING_SETUP_SQPOLL) {
io_uring/io_uring.c-2821- /* IPI related flags don't make sense with SQPOLL */
io_uring/io_uring.c:2822: if (flags & (IORING_SETUP_COOP_TASKRUN |
io_uring/io_uring.c:2823: IORING_SETUP_TASKRUN_FLAG |
io_uring/io_uring.c:2824: IORING_SETUP_DEFER_TASKRUN))
io_uring/io_uring.c-2825- return -EINVAL;
--
io_uring/io_uring.c-2827-
io_uring/io_uring.c:2828: if (flags & IORING_SETUP_TASKRUN_FLAG) {
io_uring/io_uring.c:2829: if (!(flags & (IORING_SETUP_COOP_TASKRUN |
io_uring/io_uring.c:2830: IORING_SETUP_DEFER_TASKRUN)))
io_uring/io_uring.c-2831- return -EINVAL;
--
io_uring/io_uring.c-2834- /* HYBRID_IOPOLL only valid with IOPOLL */
io_uring/io_uring.c:2835: if ((flags & IORING_SETUP_HYBRID_IOPOLL) && !(flags & IORING_SETUP_IOPOLL))
io_uring/io_uring.c-2836- return -EINVAL;
--
io_uring/io_uring.c-2841- */
io_uring/io_uring.c:2842: if ((flags & IORING_SETUP_DEFER_TASKRUN) &&
io_uring/io_uring.c:2843: !(flags & IORING_SETUP_SINGLE_ISSUER))
io_uring/io_uring.c-2844- return -EINVAL;
--
io_uring/io_uring.c-2849- */
io_uring/io_uring.c:2850: if ((flags & (IORING_SETUP_CQE32|IORING_SETUP_CQE_MIXED)) ==
io_uring/io_uring.c:2851: (IORING_SETUP_CQE32|IORING_SETUP_CQE_MIXED))
io_uring/io_uring.c-2852- return -EINVAL;
--
io_uring/io_uring.c-2856- */
io_uring/io_uring.c:2857: if ((flags & (IORING_SETUP_SQE128|IORING_SETUP_SQE_MIXED)) ==
io_uring/io_uring.c:2858: (IORING_SETUP_SQE128|IORING_SETUP_SQE_MIXED))
io_uring/io_uring.c-2859- return -EINVAL;
--
io_uring/io_uring.c=2864=static int io_uring_fill_params(struct io_uring_params *p)
--
io_uring/io_uring.c-2870- if (entries > IORING_MAX_ENTRIES) {
io_uring/io_uring.c:2871: if (!(p->flags & IORING_SETUP_CLAMP))
io_uring/io_uring.c-2872- return -EINVAL;
--
io_uring/io_uring.c-2880- * some flexibility in overcommitting a bit. If the application has
io_uring/io_uring.c:2881: * set IORING_SETUP_CQSIZE, it will have passed in the desired number
io_uring/io_uring.c-2882- * of CQ ring entries manually.
--
io_uring/io_uring.c-2884- p->sq_entries = roundup_pow_of_two(entries);
io_uring/io_uring.c:2885: if (p->flags & IORING_SETUP_CQSIZE) {
io_uring/io_uring.c-2886- /*
io_uring/io_uring.c:2887: * If IORING_SETUP_CQSIZE is set, we do the same roundup
io_uring/io_uring.c-2888- * to a power-of-two, if it isn't already. We do NOT impose
--
io_uring/io_uring.c-2893- if (p->cq_entries > IORING_MAX_CQ_ENTRIES) {
io_uring/io_uring.c:2894: if (!(p->flags & IORING_SETUP_CLAMP))
io_uring/io_uring.c-2895- return -EINVAL;
--
io_uring/io_uring.c=2908=int io_prepare_config(struct io_ctx_config *config)
--
io_uring/io_uring.c-2932- p->sq_off.resv1 = 0;
io_uring/io_uring.c:2933: if (!(p->flags & IORING_SETUP_NO_MMAP))
io_uring/io_uring.c-2934- p->sq_off.user_addr = 0;
--
io_uring/io_uring.c-2943- p->cq_off.resv1 = 0;
io_uring/io_uring.c:2944: if (!(p->flags & IORING_SETUP_NO_MMAP))
io_uring/io_uring.c-2945- p->cq_off.user_addr = 0;
io_uring/io_uring.c:2946: if (!(p->flags & IORING_SETUP_NO_SQARRAY))
io_uring/io_uring.c-2947- p->sq_off.array = config->layout.sq_array_offset;
--
io_uring/io_uring.c=2978=static __cold int io_uring_create(struct io_ctx_config *config)
--
io_uring/io_uring.c-2996-
io_uring/io_uring.c:2997: if (!(ctx->flags & IORING_SETUP_NO_SQARRAY))
io_uring/io_uring.c-2998- static_branch_deferred_inc(&io_key_has_sqarray);
io_uring/io_uring.c-2999-
io_uring/io_uring.c:3000: if ((ctx->flags & IORING_SETUP_DEFER_TASKRUN) &&
io_uring/io_uring.c:3001: !(ctx->flags & IORING_SETUP_IOPOLL))
io_uring/io_uring.c-3002- ctx->int_flags |= IO_RING_F_TASK_COMPLETE;
--
io_uring/io_uring.c-3004- if ((ctx->int_flags & IO_RING_F_TASK_COMPLETE) ||
io_uring/io_uring.c:3005: (ctx->flags & IORING_SETUP_IOPOLL))
io_uring/io_uring.c-3006- ctx->int_flags |= IO_RING_F_LOCKLESS_CQ;
--
io_uring/io_uring.c-3020- */
io_uring/io_uring.c:3021: if (ctx->flags & IORING_SETUP_IOPOLL &&
io_uring/io_uring.c:3022: !(ctx->flags & IORING_SETUP_SQPOLL))
io_uring/io_uring.c-3023- ctx->int_flags |= IO_RING_F_SYSCALL_IOPOLL;
--
io_uring/io_uring.c-3033- */
io_uring/io_uring.c:3034: if (ctx->flags & (IORING_SETUP_SQPOLL|IORING_SETUP_COOP_TASKRUN))
io_uring/io_uring.c-3035- ctx->notify_method = TWA_SIGNAL_NO_IPI;
--
io_uring/io_uring.c-3069-
io_uring/io_uring.c:3070: if (ctx->flags & IORING_SETUP_SINGLE_ISSUER
io_uring/io_uring.c:3071: && !(ctx->flags & IORING_SETUP_R_DISABLED))
io_uring/io_uring.c-3072- ctx->submitter_task = get_task_struct(current);
--
io_uring/io_uring.c-3088- */
io_uring/io_uring.c:3089: if (p->flags & IORING_SETUP_REGISTERED_FD_ONLY)
io_uring/io_uring.c-3090- ret = io_ring_add_registered_file(tctx, file, 0, IO_RINGFD_REG_MAX);
--
io_uring/io_uring.h=29=struct io_ctx_config {
--
io_uring/io_uring.h-53-
io_uring/io_uring.h:54:#define IORING_SETUP_FLAGS (IORING_SETUP_IOPOLL |\
io_uring/io_uring.h:55: IORING_SETUP_SQPOLL |\
io_uring/io_uring.h:56: IORING_SETUP_SQ_AFF |\
io_uring/io_uring.h:57: IORING_SETUP_CQSIZE |\
io_uring/io_uring.h:58: IORING_SETUP_CLAMP |\
io_uring/io_uring.h:59: IORING_SETUP_ATTACH_WQ |\
io_uring/io_uring.h:60: IORING_SETUP_R_DISABLED |\
io_uring/io_uring.h:61: IORING_SETUP_SUBMIT_ALL |\
io_uring/io_uring.h:62: IORING_SETUP_COOP_TASKRUN |\
io_uring/io_uring.h:63: IORING_SETUP_TASKRUN_FLAG |\
io_uring/io_uring.h:64: IORING_SETUP_SQE128 |\
io_uring/io_uring.h:65: IORING_SETUP_CQE32 |\
io_uring/io_uring.h:66: IORING_SETUP_SINGLE_ISSUER |\
io_uring/io_uring.h:67: IORING_SETUP_DEFER_TASKRUN |\
io_uring/io_uring.h:68: IORING_SETUP_NO_MMAP |\
io_uring/io_uring.h:69: IORING_SETUP_REGISTERED_FD_ONLY |\
io_uring/io_uring.h:70: IORING_SETUP_NO_SQARRAY |\
io_uring/io_uring.h:71: IORING_SETUP_HYBRID_IOPOLL |\
io_uring/io_uring.h:72: IORING_SETUP_CQE_MIXED |\
io_uring/io_uring.h:73: IORING_SETUP_SQE_MIXED |\
io_uring/io_uring.h:74: IORING_SETUP_SQ_REWIND)
io_uring/io_uring.h-75-
--
io_uring/io_uring.h=217=static inline void io_lockdep_assert_cq_locked(struct io_ring_ctx *ctx)
--
io_uring/io_uring.h-221-
io_uring/io_uring.h:222: if (ctx->flags & IORING_SETUP_DEFER_TASKRUN)
io_uring/io_uring.h-223- lockdep_assert_held(&ctx->uring_lock);
io_uring/io_uring.h-224-
io_uring/io_uring.h:225: if (ctx->flags & IORING_SETUP_IOPOLL) {
io_uring/io_uring.h-226- lockdep_assert_held(&ctx->uring_lock);
--
io_uring/io_uring.h-231- * ->submitter_task may be NULL and we can still post a CQE,
io_uring/io_uring.h:232: * if the ring has been setup with IORING_SETUP_R_DISABLED.
io_uring/io_uring.h-233- * Not from an SQE, as those cannot be submitted, but via
--
io_uring/io_uring.h=257=static inline bool io_get_cqe_overflow(struct io_ring_ctx *ctx,
--
io_uring/io_uring.h-269- ctx->cqe_cached++;
io_uring/io_uring.h:270: if (ctx->flags & IORING_SETUP_CQE32) {
io_uring/io_uring.h-271- ctx->cqe_cached++;
io_uring/io_uring.h:272: } else if (cqe32 && ctx->flags & IORING_SETUP_CQE_MIXED) {
io_uring/io_uring.h-273- ctx->cqe_cached++;
--
io_uring/io_uring.h=286=static inline bool io_defer_get_uncommited_cqe(struct io_ring_ctx *ctx,
--
io_uring/io_uring.h-291- ctx->submit_state.cq_flush = true;
io_uring/io_uring.h:292: return io_get_cqe(ctx, cqe_ret, ctx->flags & IORING_SETUP_CQE_MIXED);
io_uring/io_uring.h-293-}
--
io_uring/io_uring.h=295=static __always_inline bool io_fill_cqe_req(struct io_ring_ctx *ctx,
--
io_uring/io_uring.h-308- memcpy(cqe, &req->cqe, sizeof(*cqe));
io_uring/io_uring.h:309: if (ctx->flags & IORING_SETUP_CQE32 || is_cqe32) {
io_uring/io_uring.h-310- memcpy(cqe->big_cqe, &req->big_cqe, sizeof(*cqe));
--
io_uring/io_uring.h=334=static inline u32 ctx_cqe32_flags(struct io_ring_ctx *ctx)
io_uring/io_uring.h-335-{
io_uring/io_uring.h:336: if (ctx->flags & IORING_SETUP_CQE_MIXED)
io_uring/io_uring.h-337- return IORING_CQE_F_32;
--
io_uring/msg_ring.c=113=static int __io_msg_ring_data(struct io_ring_ctx *target_ctx,
--
io_uring/msg_ring.c-123- /*
io_uring/msg_ring.c:124: * Keep IORING_SETUP_R_DISABLED check before submitter_task load
io_uring/msg_ring.c-125- * in io_msg_data_remote() -> io_req_task_work_add_remote()
io_uring/msg_ring.c-126- */
]
|
| 8/2 |
2026/06/12 22:20 |
llm |
expert |
0m
Model:
Tokens:
input: 79603
output: 25
thoughts: 647
Thoughts: **Analyzing a Potential io_uring Bug**
Okay, let's break this down. My initial observation is that this reproducer uses a specific set of `io_uring_setup` flags. I'm seeing `IORING_SETUP_SQPOLL`, `IORING_SETUP_CQSIZE`, `IORING_SETUP_CLAMP`, `IORING_SETUP_ATTACH_WQ`, `IORING_SETUP_R_DISABLED`, `IORING_SETUP_SUBMIT_ALL`, `IORING_SETUP_COOP_TASKRUN`, `IORING_SETUP_TASKRUN_FLAG`, `IORING_SETUP_SQE128`, `IORING_SETUP_CQE32`, `IORING_SETUP_SINGLE_ISSUER`, and `IORING_SETUP_DEFER_TASKRUN`. That's a lot of options, and some of them jump out.
Specifically, `IORING_SETUP_SQPOLL` (which is `1U << 1`) and `IORING_SETUP_R_DISABLED` (that's `1U << 6`) are interesting in this context, but, more importantly, `IORING_SETUP_DEFER_TASKRUN` (which is `1U << 13`).
The reason for the concern immediately arose from the examination of `io_uring_sanitise_params`. It's clear that the kernel expects `io_uring_setup` to return `-EINVAL` if both `IORING_SETUP_SQPOLL` and `IORING_SETUP_DEFER_TASKRUN` are set simultaneously. That's a definite conflict, and it should fail.
Now, let's revisit the reproducer. It's setting a value to `0x200000000048` and it equals to `0x1c080`. Decoding that reveals: `1 << 16`, `1 << 15`, `1 << 14`, and `1 << 7`. Those are `IORING_SETUP_NO_SQARRAY`, `IORING_SETUP_REGISTERED_FD_ONLY`, `IORING_SETUP_NO_MMAP`, and `IORING_SETUP_SUBMIT_ALL`, respectively.
The critical piece here is `IORING_SETUP_REGISTERED_FD_ONLY`. If that's set, then `io_uring_setup` is *supposed* to return an *index* into a registered fd, not the actual file descriptor. This suggests that the ring file descriptor itself *should* be registered. However, this doesn't fit with how the file descriptor is returned as an actual file descriptor. This seems contradictory. Thus, it's worth checking `io_uring_setup` with `IORING_SETUP_REGISTERED_FD_ONLY` set. I need to understand what's actually happening when that flag is used. This seems to be the crucial part of the issue.
|
| 9/2 |
2026/06/12 22:20 |
tool |
grepper |
0m
Args: map[Expression:IORING_SETUP_REGISTERED_FD_ONLY]
Results: map[Output:include/uapi/linux/io_uring.h=143=enum io_uring_sqe_flags_bit {
--
include/uapi/linux/io_uring.h-220- */
include/uapi/linux/io_uring.h:221:#define IORING_SETUP_REGISTERED_FD_ONLY (1U << 15)
include/uapi/linux/io_uring.h-222-
--
io_uring/io_uring.c=2802=static int io_uring_sanitise_params(struct io_uring_params *p)
--
io_uring/io_uring.c-2815- /* There is no way to mmap rings without a real fd */
io_uring/io_uring.c:2816: if ((flags & IORING_SETUP_REGISTERED_FD_ONLY) &&
io_uring/io_uring.c-2817- !(flags & IORING_SETUP_NO_MMAP))
--
io_uring/io_uring.c=2978=static __cold int io_uring_create(struct io_ctx_config *config)
--
io_uring/io_uring.c-3088- */
io_uring/io_uring.c:3089: if (p->flags & IORING_SETUP_REGISTERED_FD_ONLY)
io_uring/io_uring.c-3090- ret = io_ring_add_registered_file(tctx, file, 0, IO_RINGFD_REG_MAX);
--
io_uring/io_uring.h=29=struct io_ctx_config {
--
io_uring/io_uring.h-68- IORING_SETUP_NO_MMAP |\
io_uring/io_uring.h:69: IORING_SETUP_REGISTERED_FD_ONLY |\
io_uring/io_uring.h-70- IORING_SETUP_NO_SQARRAY |\
--
tools/include/uapi/linux/io_uring.h=117=enum {
--
tools/include/uapi/linux/io_uring.h-193- */
tools/include/uapi/linux/io_uring.h:194:#define IORING_SETUP_REGISTERED_FD_ONLY (1U << 15)
tools/include/uapi/linux/io_uring.h-195-
]
|
| 10/2 |
2026/06/12 22:20 |
llm |
expert |
0m
Model:
Tokens:
input: 81520
output: 38
thoughts: 78
Thoughts: Okay, let me break this down.
**Diving into the io_uring File Registration**
Alright, so the core of this seems to be triggered by a call to `io_ring_add_registered_file(tctx, file, 0, IO_RINGFD_REG_MAX)`. My initial thought is, "Okay, file registered, nothing too unusual." But wait a second, that's not the whole picture. I'm remembering how `io_uring_create` functions. It *allocates* a file first. Typically that is done via an anonymous inode with `anon_inode_getfile` or something comparable, and *then* it registers it. That's the key. That's where the nuance is. I need to refresh my memory on the exact sequence here. Time to jump into the `io_uring_create` source code and confirm what's going on. I need to understand the relationship between the file allocation and this registration process, the subtle implications of the timing, and any potential side effects. That's the critical piece of this puzzle I need to solidify.
|
| 11/2 |
2026/06/12 22:20 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_uring_create]
Results: map[SourceCode:2978: static __cold int io_uring_create(struct io_ctx_config *config)
2979: {
2980: struct io_uring_params *p = &config->p;
2981: struct io_ring_ctx *ctx;
2982: struct io_uring_task *tctx;
2983: struct file *file;
2984: int ret;
2985:
2986: ret = io_prepare_config(config);
2987: if (ret)
2988: return ret;
2989:
2990: ctx = io_ring_ctx_alloc(p);
2991: if (!ctx)
2992: return -ENOMEM;
2993:
2994: ctx->clockid = CLOCK_MONOTONIC;
2995: ctx->clock_offset = 0;
2996:
2997: if (!(ctx->flags & IORING_SETUP_NO_SQARRAY))
2998: static_branch_deferred_inc(&io_key_has_sqarray);
2999:
3000: if ((ctx->flags & IORING_SETUP_DEFER_TASKRUN) &&
3001: !(ctx->flags & IORING_SETUP_IOPOLL))
3002: ctx->int_flags |= IO_RING_F_TASK_COMPLETE;
3003:
3004: if ((ctx->int_flags & IO_RING_F_TASK_COMPLETE) ||
3005: (ctx->flags & IORING_SETUP_IOPOLL))
3006: ctx->int_flags |= IO_RING_F_LOCKLESS_CQ;
3007:
3008: /*
3009: * lazy poll_wq activation relies on ->task_complete for synchronisation
3010: * purposes, see io_activate_pollwq()
3011: */
3012: if (!(ctx->int_flags & IO_RING_F_TASK_COMPLETE))
3013: ctx->int_flags |= IO_RING_F_POLL_ACTIVATED;
3014:
3015: /*
3016: * When SETUP_IOPOLL and SETUP_SQPOLL are both enabled, user
3017: * space applications don't need to do io completion events
3018: * polling again, they can rely on io_sq_thread to do polling
3019: * work, which can reduce cpu usage and uring_lock contention.
3020: */
3021: if (ctx->flags & IORING_SETUP_IOPOLL &&
3022: !(ctx->flags & IORING_SETUP_SQPOLL))
3023: ctx->int_flags |= IO_RING_F_SYSCALL_IOPOLL;
3024:
3025: if (in_compat_syscall())
3026: ctx->int_flags |= IO_RING_F_COMPAT;
3027: if (!ns_capable_noaudit(&init_user_ns, CAP_IPC_LOCK))
3028: ctx->user = get_uid(current_user());
3029:
3030: /*
3031: * For SQPOLL, we just need a wakeup, always. For !SQPOLL, if
3032: * COOP_TASKRUN is set, then IPIs are never needed by the app.
3033: */
3034: if (ctx->flags & (IORING_SETUP_SQPOLL|IORING_SETUP_COOP_TASKRUN))
3035: ctx->notify_method = TWA_SIGNAL_NO_IPI;
3036: else
3037: ctx->notify_method = TWA_SIGNAL;
3038:
3039: /*
3040: * If the current task has restrictions enabled, then copy them to
3041: * our newly created ring and mark it as registered.
3042: */
3043: if (current->io_uring_restrict)
3044: io_ctx_restriction_clone(ctx, current->io_uring_restrict);
3045:
3046: /*
3047: * This is just grabbed for accounting purposes. When a process exits,
3048: * the mm is exited and dropped before the files, hence we need to hang
3049: * on to this mm purely for the purposes of being able to unaccount
3050: * memory (locked/pinned vm). It's not used for anything else.
3051: */
3052: mmgrab(current->mm);
3053: ctx->mm_account = current->mm;
3054:
3055: ret = io_allocate_scq_urings(ctx, config);
3056: if (ret)
3057: goto err;
3058:
3059: ret = io_sq_offload_create(ctx, p);
3060: if (ret)
3061: goto err;
3062:
3063: p->features = IORING_FEAT_FLAGS;
3064:
3065: if (copy_to_user(config->uptr, p, sizeof(*p))) {
3066: ret = -EFAULT;
3067: goto err;
3068: }
3069:
3070: if (ctx->flags & IORING_SETUP_SINGLE_ISSUER
3071: && !(ctx->flags & IORING_SETUP_R_DISABLED))
3072: ctx->submitter_task = get_task_struct(current);
3073:
3074: file = io_uring_get_file(ctx);
3075: if (IS_ERR(file)) {
3076: ret = PTR_ERR(file);
3077: goto err;
3078: }
3079:
3080: ret = __io_uring_add_tctx_node(ctx);
3081: if (ret)
3082: goto err_fput;
3083: tctx = current->io_uring;
3084:
3085: /*
3086: * Install ring fd as the very last thing, so we don't risk someone
3087: * having closed it before we finish setup
3088: */
3089: if (p->flags & IORING_SETUP_REGISTERED_FD_ONLY)
3090: ret = io_ring_add_registered_file(tctx, file, 0, IO_RINGFD_REG_MAX);
3091: else
3092: ret = io_uring_install_fd(file);
3093: if (ret < 0)
3094: goto err_fput;
3095:
3096: trace_io_uring_create(ret, ctx, p->sq_entries, p->cq_entries, p->flags);
3097: return ret;
3098: err:
3099: io_ring_ctx_wait_and_kill(ctx);
3100: return ret;
3101: err_fput:
3102: fput(file);
3103: return ret;
3104: }
SourceFile:io_uring/io_uring.c]
|
| 12/2 |
2026/06/12 22:20 |
llm |
expert |
0m
Model:
Tokens:
input: 83888
output: 42
thoughts: 135
Thoughts: **Analyzing the io_uring File Registration Process**
Okay, so I'm tracing this `io_uring_create` call and I see that it ultimately leads to `io_uring_get_file(ctx)`, which allocates a file. Standard stuff. Then, based on the flags set, specifically if `IORING_SETUP_REGISTERED_FD_ONLY` is present, it dives into `io_ring_add_registered_file(tctx, file, 0, IO_RINGFD_REG_MAX)`. That makes sense, handling the registered file descriptor aspect. The function returns an index if successful, which is what I'd expect.
But wait a minute… the way I'm reading this, `io_ring_add_registered_file` appears to *take a reference* to that file. That’s a key detail to verify. I need to dive into the implementation of `io_ring_add_registered_file` to confirm how the file reference is handled. That's a critical point for understanding the overall lifecycle and potential memory management implications within this context.
|
| 13/2 |
2026/06/12 22:20 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_ring_add_registered_file]
Results: map[SourceCode: 270: int io_ring_add_registered_file(struct io_uring_task *tctx, struct file *file,
271: int start, int end)
272: {
273: int offset, idx;
274: for (offset = start; offset < end; offset++) {
275: idx = array_index_nospec(offset, IO_RINGFD_REG_MAX);
276: if (tctx->registered_rings[idx])
277: continue;
278:
279: tctx->registered_rings[idx] = file;
280: return idx;
281: }
282: return -EBUSY;
283: }
SourceFile:io_uring/tctx.c]
|
| 14/2 |
2026/06/12 22:20 |
llm |
expert |
0m
Model:
Tokens:
input: 84535
output: 40
thoughts: 168
Thoughts: **Analyzing the File Descriptor Registration Process**
Okay, let's break this down. My initial understanding of how registered file descriptors are handled by `io_uring_add_registered_file` seems to be flawed. I was under the impression it was somehow managing the file's reference count. But no, it simply assigns the file to a specific index within `tctx->registered_rings` and returns that index. It's not taking a reference. That's key.
Right, so `io_uring_get_file` *does* return a file with a reference count of 1. If `io_ring_add_registered_file` executes without error, it returns the index `idx`, which is zero or greater. Then `io_uring_create` ultimately returns that same `idx` as `ret`, which makes sense. Crucially, the file's reference is *not* being dropped at any point there. This has some implications. I need to keep track of where the reference count is incremented and decremented as it moves through these functions.
Okay, let's see, if the `IORING_SETUP_REGISTERED_FD_ONLY` flag is *not* set, the `io_uring_install_fd(file)` function will be called. I need to refresh my memory on what that function does exactly, and how it handles the file descriptor. Let me check its implementation to understand how the file is ultimately used within the context of the I/O ring. That's the next critical piece of this puzzle.
|
| 15/2 |
2026/06/12 22:21 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_uring_install_fd]
Results: map[SourceCode:2779: static int io_uring_install_fd(struct file *file)
2780: {
2781: int fd;
2782:
2783: fd = get_unused_fd_flags(O_RDWR | O_CLOEXEC);
2784: if (fd < 0)
2785: return fd;
2786: fd_install(fd, file);
2787: return fd;
2788: }
SourceFile:io_uring/io_uring.c]
|
| 16/2 |
2026/06/12 22:21 |
llm |
expert |
0m
Model:
Tokens:
input: 85236
output: 40
thoughts: 226
Thoughts: **Understanding File Descriptor and Reference Counting in io_uring**
Okay, so I'm digging into this `fd_install` function and initially, I was under the impression it was consuming the file's reference count. But that's wrong. `fd_install` simply registers the file with the file descriptor table; the file was created with a refcount of 1, and the table then holds that sole reference.
Now, I'm looking at `io_ring_add_registered_file`, and it just seems to be storing the file pointer in `tctx->registered_rings[idx]`. This raises some questions immediately. Does *that* assignment hold a reference? It doesn't look like `io_ring_add_registered_file` itself increments the reference count. If not, then the file's refcount is still at 1, and `tctx->registered_rings` is indeed the *holder* of that sole reference.
This is critical because if `tctx->registered_rings` is holding that reference, then when the `tctx` is destroyed, the code will call `fput` on the file. That would be expected behavior.
I should check the `io_uring_clean_tctx` function for confirmation to make sure. That should definitively show the refcount management during the context's destruction.
|
| 17/2 |
2026/06/12 22:21 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/tctx.c Name:io_uring_clean_tctx]
Results: map[SourceCode: 237: __cold void io_uring_clean_tctx(struct io_uring_task *tctx)
238: {
239: struct io_wq *wq = tctx->io_wq;
240: struct io_tctx_node *node;
241: unsigned long index;
242:
243: xa_for_each(&tctx->xa, index, node) {
244: io_uring_del_tctx_node(index);
245: cond_resched();
246: }
247: if (wq) {
248: /*
249: * Must be after io_uring_del_tctx_node() (removes nodes under
250: * uring_lock) to avoid race with io_uring_try_cancel_iowq().
251: */
252: io_wq_put_and_exit(wq);
253: tctx->io_wq = NULL;
254: }
255: }
SourceFile:io_uring/tctx.c]
|
| 18/2 |
2026/06/12 22:21 |
llm |
expert |
0m
Model:
Tokens:
input: 86112
output: 17
thoughts: 12
Thoughts: Here's my attempt at summarizing that thought process, tailored for an expert audience:
**Unraveling Ring Registration Cleanup**
Okay, so I'm digging through this code, and a nagging question pops up: *Where* exactly are those `registered_rings` getting cleaned up? I'm familiar with the overall structure, and I'm pretty sure I know where they're being *used*, but I'm suddenly drawing a blank on the lifecycle. Are we relying on RAII, a specific shutdown function, or something else entirely to manage them? This is a critical area for potential memory leaks or resource contention, so I need to nail down the exact mechanism. Gotta track down the deallocation logic and ensure it's robust and thread-safe. Time to start digging and confirm my assumptions, or, more likely, uncover an oversight I need to fix!
|
| 19/2 |
2026/06/12 22:21 |
tool |
grepper |
0m
Args: map[Expression:registered_rings]
Results: map[Output:include/linux/io_uring_types.h=116=struct io_uring_task {
--
include/linux/io_uring_types.h-121- struct io_wq *io_wq;
include/linux/io_uring_types.h:122: struct file *registered_rings[IO_RINGFD_REG_MAX];
include/linux/io_uring_types.h-123-
--
io_uring/io_uring.c=2571=struct file *io_uring_ctx_get_file(unsigned int fd, bool registered)
--
io_uring/io_uring.c-2584- fd = array_index_nospec(fd, IO_RINGFD_REG_MAX);
io_uring/io_uring.c:2585: file = tctx->registered_rings[fd];
io_uring/io_uring.c-2586- } else {
--
io_uring/tctx.c=257=void io_uring_unreg_ringfd(void)
--
io_uring/tctx.c-262- for (i = 0; i < IO_RINGFD_REG_MAX; i++) {
io_uring/tctx.c:263: if (tctx->registered_rings[i]) {
io_uring/tctx.c:264: fput(tctx->registered_rings[i]);
io_uring/tctx.c:265: tctx->registered_rings[i] = NULL;
io_uring/tctx.c-266- }
--
io_uring/tctx.c=270=int io_ring_add_registered_file(struct io_uring_task *tctx, struct file *file,
--
io_uring/tctx.c-275- idx = array_index_nospec(offset, IO_RINGFD_REG_MAX);
io_uring/tctx.c:276: if (tctx->registered_rings[idx])
io_uring/tctx.c-277- continue;
io_uring/tctx.c-278-
io_uring/tctx.c:279: tctx->registered_rings[idx] = file;
io_uring/tctx.c-280- return idx;
--
io_uring/tctx.c=312=int io_ringfd_register(struct io_ring_ctx *ctx, void __user *__arg,
--
io_uring/tctx.c-360- if (copy_to_user(&arg[i], ®, sizeof(reg))) {
io_uring/tctx.c:361: fput(tctx->registered_rings[reg.offset]);
io_uring/tctx.c:362: tctx->registered_rings[reg.offset] = NULL;
io_uring/tctx.c-363- ret = -EFAULT;
--
io_uring/tctx.c=371=int io_ringfd_unregister(struct io_ring_ctx *ctx, void __user *__arg,
--
io_uring/tctx.c-394- reg.offset = array_index_nospec(reg.offset, IO_RINGFD_REG_MAX);
io_uring/tctx.c:395: if (tctx->registered_rings[reg.offset]) {
io_uring/tctx.c:396: fput(tctx->registered_rings[reg.offset]);
io_uring/tctx.c:397: tctx->registered_rings[reg.offset] = NULL;
io_uring/tctx.c-398- }
]
|
| 20/2 |
2026/06/12 22:21 |
llm |
expert |
0m
Model:
Tokens:
input: 87250
output: 33
thoughts: 82
Thoughts: Okay, let's see...
**De-registering the Ring File Descriptor**
Right, so I'm trying to wrap my head around how the ring file descriptor gets cleaned up, and I had a hunch that `io_uring_unreg_ringfd` was the key. Seems logical, yeah, it *unregisters* the file descriptor. But, I was initially thinking that it was called within the `io_uring_clean_tctx` function, as part of the teardown process for a specific thread context. Upon a quick check, that doesn't seem to be the case. So, now I need to actually find *where* this `io_uring_unreg_ringfd` function gets called from. Time to dig a bit deeper.
|
| 21/2 |
2026/06/12 22:21 |
tool |
codesearch-find-references |
0m
Args: map[IncludeSnippetLines:0 Name:io_uring_unreg_ringfd]
Results: map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__io_uring_cancel SourceFile:io_uring/cancel.c SourceLine:439]] TruncatedOutput:false]
|
| 22/2 |
2026/06/12 22:21 |
llm |
expert |
0m
Model:
Tokens:
input: 87598
output: 37
thoughts: 12
Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience:
**Diving into `__io_uring_cancel`**
Alright, let's get down to brass tacks. My initial thought is to zero in on `__io_uring_cancel`. It's the core function for canceling outstanding I/O requests within the io_uring framework, so understanding its mechanics is paramount. I need to refresh my understanding of how it interacts with the submission and completion queues, and particularly, what sort of locking or synchronization it uses to maintain data integrity. I'll need to consider potential race conditions and edge cases, especially when dealing with concurrent submissions and cancellations. Beyond the basic control flow, I'm curious about the specific criteria it uses to identify requests that are eligible for cancellation - does it use flags, states, or offsets in the data structures? Then, I need to look into how the system signals the completion queue about these cancellations. Does it generate specific completion codes, and how are these codes handled at the user-space level? Finally, I need to assess how it handles incomplete requests, and how the various completion queues are cleaned up after the cancellation call.
|
| 23/2 |
2026/06/12 22:21 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/cancel.c Name:__io_uring_cancel]
Results: map[SourceCode: 437: void __io_uring_cancel(bool cancel_all)
438: {
439: io_uring_unreg_ringfd();
440: io_uring_cancel_generic(cancel_all, NULL);
441: }
SourceFile:io_uring/cancel.c]
|
| 24/2 |
2026/06/12 22:21 |
llm |
expert |
0m
Model:
Tokens:
input: 87997
output: 40
thoughts: 418
Thoughts: **Analyzing Potential Resource Leaks in io_uring Setup**
Okay, so I'm digging into the `io_uring` code, specifically focusing on potential leak scenarios. I see that `__io_uring_cancel` is called from `io_uring_task_cancel` and related functions, which is important to remember. But let's rewind and look at the `io_uring_create` function. Ah, here's an interesting condition:
```c
if (p->flags & IORING_SETUP_REGISTERED_FD_ONLY)
ret = io_ring_add_registered_file(tctx, file, 0, IO_RINGFD_REG_MAX);
else
ret = io_uring_install_fd(file);
if (ret < 0)
goto err_fput;
```
If the `IORING_SETUP_REGISTERED_FD_ONLY` flag is set, `io_ring_add_registered_file` is called. Critically, if it returns a negative value, `err_fput` is jumped to, which cleans up the `file` with `fput(file)`. If it returns a non-negative value, it just returns the value back.
Okay, let's step up to the `sys_io_uring_setup` system call which seems to call `io_uring_create`.
```c
SYSCALL_DEFINE2(io_uring_setup, u32, entries,
struct io_uring_params __user *, params)
{
return io_uring_setup(entries, params);
}
```
Wait, `sys_io_uring_setup` returns either a file descriptor (`fd`) or an index (`idx`). If the `IORING_SETUP_REGISTERED_FD_ONLY` flag is set, `idx` is returned. So, if `io_uring_create` returns a positive number and the sys call returns the `ret` value, this could be a point of concern.
However, I'm thinking... does `io_uring_create` have the ability to fail *after* a successful `io_ring_add_registered_file` call? No, it looks like `io_ring_add_registered_file` is the last operation done in that sequence. That's good.
So, if `io_uring_create` manages to succeed, but somehow `sys_io_uring_setup` returns an error to userspace, are there any resources leaked here? I think I need to check how `io_uring_get_file` works to make sure there's nothing lingering that needs to be addressed. Let me go check that out.
|
| 25/2 |
2026/06/12 22:21 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_uring_get_file]
Results: map[SourceCode:2790: /*
2791: * Allocate an anonymous fd, this is what constitutes the application
2792: * visible backing of an io_uring instance. The application mmaps this
2793: * fd to gain access to the SQ/CQ ring details.
2794: */
2795: static struct file *io_uring_get_file(struct io_ring_ctx *ctx)
2796: {
2797: /* Create a new inode so that the LSM can block the creation. */
2798: return anon_inode_create_getfile("[io_uring]", &io_uring_fops, ctx,
2799: O_RDWR | O_CLOEXEC, NULL);
2800: }
SourceFile:io_uring/io_uring.c]
|
| 26/2 |
2026/06/12 22:21 |
llm |
expert |
0m
Model:
Tokens:
input: 89273
output: 42
thoughts: 1345
Thoughts: **Analyzing a Potential File Descriptor Leak in io_uring with Registered FDs**
Okay, let's break this down. Initially, I was thinking the leak was related to `anon_inode_create_getfile` and how file descriptors were handled with `IORING_SETUP_REGISTERED_FD_ONLY` and `io_uring_unreg_ringfd`. The process seems to correctly decrement the refcount to zero and the file is freed, so that's not it.
Then I saw the syzbot report and noticed the call stack - `alloc_empty_file`, `path_openat`, `do_file_open`, and `do_sys_openat2`. This is *not* `io_uring_setup`. It's `openat`. The leak is coming from `openat`! Got it.
Looking at the reproducer, `syz_open_dev` is called, which opens `/dev/vbi3`. It sets up a netlink socket, does `sendmsg`, and then `io_uring_enter`. `io_uring_enter` submits a request. I need to understand *that* request.
The io_uring is created with `IORING_SETUP_REGISTERED_FD_ONLY`, `IORING_SETUP_NO_SQARRAY`, and `IORING_SETUP_NO_MMAP`. Since `IORING_SETUP_NO_MMAP` is set, the user provides the memory for the rings. The user memory for `io_uring_params` is at `0x200000000040`.
Now, where are the rings themselves? The `sq_off` and `cq_off` structures in `io_uring_params` are the key. Specifically, `user_addr` is zero. If `user_addr` is zero, `io_uring_setup` might attempt to map the rings at address zero, which would cause an access violation, right? No, the `user_addr` is a pointer to the rings, if it is 0, the kernel might have an issue with `copy_from_user` or `access_ok` with that address.
Actually, it seems the rings are mapped at `0x1ffffffff000ul` and `0x200000000000ul`. So address zero is not mapped.
So could `io_uring_setup` potentially fail due to this invalid ring address? I should check `io_allocate_scq_urings` with `IORING_SETUP_NO_MMAP` to verify what happens. That could be the key to understanding the leak.
|
| 27/2 |
2026/06/12 22:21 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_allocate_scq_urings]
Results: map[SourceCode:2731: static __cold int io_allocate_scq_urings(struct io_ring_ctx *ctx,
2732: struct io_ctx_config *config)
2733: {
2734: struct io_uring_params *p = &config->p;
2735: struct io_rings_layout *rl = &config->layout;
2736: struct io_uring_region_desc rd;
2737: struct io_rings *rings;
2738: int ret;
2739:
2740: /* make sure these are sane, as we already accounted them */
2741: ctx->sq_entries = p->sq_entries;
2742: ctx->cq_entries = p->cq_entries;
2743:
2744: memset(&rd, 0, sizeof(rd));
2745: rd.size = PAGE_ALIGN(rl->rings_size);
2746: if (ctx->flags & IORING_SETUP_NO_MMAP) {
2747: rd.user_addr = p->cq_off.user_addr;
2748: rd.flags |= IORING_MEM_REGION_TYPE_USER;
2749: }
2750: ret = io_create_region(ctx, &ctx->ring_region, &rd, IORING_OFF_CQ_RING);
2751: if (ret)
2752: return ret;
2753: ctx->rings = rings = io_region_get_ptr(&ctx->ring_region);
2754: rcu_assign_pointer(ctx->rings_rcu, rings);
2755: if (!(ctx->flags & IORING_SETUP_NO_SQARRAY))
2756: ctx->sq_array = (u32 *)((char *)rings + rl->sq_array_offset);
2757:
2758: memset(&rd, 0, sizeof(rd));
2759: rd.size = PAGE_ALIGN(rl->sq_size);
2760: if (ctx->flags & IORING_SETUP_NO_MMAP) {
2761: rd.user_addr = p->sq_off.user_addr;
2762: rd.flags |= IORING_MEM_REGION_TYPE_USER;
2763: }
2764: ret = io_create_region(ctx, &ctx->sq_region, &rd, IORING_OFF_SQES);
2765: if (ret) {
2766: io_rings_free(ctx);
2767: return ret;
2768: }
2769: ctx->sq_sqes = io_region_get_ptr(&ctx->sq_region);
2770:
2771: memset(rings, 0, sizeof(*rings));
2772: WRITE_ONCE(rings->sq_ring_mask, ctx->sq_entries - 1);
2773: WRITE_ONCE(rings->cq_ring_mask, ctx->cq_entries - 1);
2774: WRITE_ONCE(rings->sq_ring_entries, ctx->sq_entries);
2775: WRITE_ONCE(rings->cq_ring_entries, ctx->cq_entries);
2776: return 0;
2777: }
SourceFile:io_uring/io_uring.c]
|
| 28/2 |
2026/06/12 22:21 |
llm |
expert |
0m
Model:
Tokens:
input: 92155
output: 37
thoughts: 43
Thoughts: Here's my analysis of what's going on:
**Deconstructing this `io_create_region` Call**
Okay, so I'm looking at this `io_create_region` call, specifically the parameters. The key point here is that we're using `IORING_MEM_REGION_TYPE_USER` and passing `user_addr = 0`. This immediately flags some potential issues and requires a closer look. With my experience, the combination of these two values, particularly the zero address, usually means something specific.
My immediate instinct is to delve into the `io_create_region` function documentation and source code. I need to understand what this combination implies in this context. Is it intended, a placeholder, or a bug? What's the kernel expecting, and what are the implications of a zero address with this particular region type? Is it for a mapping of the memory from a device? I need to analyze how the zero address will be interpreted. I need to figure out what type of memory is being requested here. I will start by figuring out what the actual intent is.
|
| 29/2 |
2026/06/12 22:21 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/memmap.c Name:io_create_region]
Results: map[SourceCode: 184: int io_create_region(struct io_ring_ctx *ctx, struct io_mapped_region *mr,
185: struct io_uring_region_desc *reg,
186: unsigned long mmap_offset)
187: {
188: int nr_pages, ret;
189: u64 end;
190:
191: if (WARN_ON_ONCE(mr->pages || mr->ptr || mr->nr_pages))
192: return -EFAULT;
193: if (memchr_inv(®->__resv, 0, sizeof(reg->__resv)))
194: return -EINVAL;
195: if (reg->flags & ~IORING_MEM_REGION_TYPE_USER)
196: return -EINVAL;
197: /* user_addr should be set IFF it's a user memory backed region */
198: if ((reg->flags & IORING_MEM_REGION_TYPE_USER) != !!reg->user_addr)
199: return -EFAULT;
200: if (!reg->size || reg->mmap_offset || reg->id)
201: return -EINVAL;
202: if ((reg->size >> PAGE_SHIFT) > INT_MAX)
203: return -E2BIG;
204: if ((reg->user_addr | reg->size) & ~PAGE_MASK)
205: return -EINVAL;
206: if (check_add_overflow(reg->user_addr, reg->size, &end))
207: return -EOVERFLOW;
208:
209: nr_pages = reg->size >> PAGE_SHIFT;
210: if (ctx->user) {
211: ret = __io_account_mem(ctx->user, nr_pages);
212: if (ret)
213: return ret;
214: }
215: mr->nr_pages = nr_pages;
216:
217: if (reg->flags & IORING_MEM_REGION_TYPE_USER)
218: ret = io_region_pin_pages(mr, reg);
219: else
220: ret = io_region_allocate_pages(mr, reg, mmap_offset);
221: if (ret)
222: goto out_free;
223:
224: ret = io_region_init_ptr(mr);
225: if (ret)
226: goto out_free;
227: return 0;
228: out_free:
229: io_free_region(ctx->user, mr);
230: return ret;
231: }
SourceFile:io_uring/memmap.c]
|
| 30/2 |
2026/06/12 22:21 |
llm |
expert |
0m
Model:
Tokens:
input: 93272
output: 24
thoughts: 1867
Thoughts: **Deconstructing the Potential Memory Leak**
Okay, let's break this down systematically. Initially, I was following the `io_uring` path, specifically the `IORING_MEM_REGION_TYPE_USER` flag and its interaction with `user_addr`. The check `if ((reg->flags & IORING_MEM_REGION_TYPE_USER) != !!reg->user_addr)` seemed suspect, especially with `user_addr` being zero. My thinking was that this could lead to `-EFAULT` during `io_uring_setup`, potentially masking a deeper issue.
I traced the `-EFAULT` through `io_allocate_scq_urings` and `io_uring_create` to the `io_uring_setup` call. The reproducer calls `io_uring_setup` with a specific argument. If the setup fails (as is expected with the test values), `r[0]` would be left at `0xffffffffffffffff`. This then leads to the `io_uring_enter` being called with `fd = -1`, resulting in a clear `-EBADF` and so definitively pointing away from any `io_uring` involvement.
Since `io_uring` is a dead end, I went back to the reproducer and the critical `syz_open_dev` function and the subsequent `sendmsg` calls. I noted the arguments to `syz_open_dev`, particularly the device name `/dev/vbi3`. It uses `syz_open_dev` with the arguments, and that calls a non-closing open function.
The reproducer opens `/dev/vbi3` and then, crucially, doesn't close the resulting file descriptor. My initial reaction was that the kernel would clean up upon process exit and close the open files. But then I saw that the `sendmsg` calls use `-1` as the file descriptor! Both `sendmsg` calls use `-1`. This strongly suggests that `sendmsg` is not supposed to be sending to the file descriptor created by the `open` call, and the file descriptor leak must happen inside of a different subsystem.
The `sendmsg` calls send Netlink messages related to traffic control (TC) filters: `RTM_NEWTFILTER` with filters and actions. The key is in those filters and actions.
The `syz_open_dev` function is calling `open("/dev/vbi3", 2, 0)` so the file is opened in O_RDWR mode and this is *not closed*. That means that if the reproducer exits normally, the kernel should close the FD. But there's *no guarantee* that this happens. This means a file struct could be leaked. That opens the door to another path. But it may or may not be the path to the memory leak. The kernel is supposed to clean up file descriptors, file structures, and other resources on process exit. So there's some kind of *double-free*, or *use-after-free*, happening, *somehow*.
The thing to investigate *carefully* is the interaction between `/dev/vbi3`, the TC filters being configured via Netlink, and what could happen when the process exits. We need to look closely at how the kernel handles `open`, the associated file structure, and its interaction with TC filter configuration and teardown.
My attention is now on the fact that if this `open` call is succeeding, then there's a file descriptor that *should* be closed upon process exit, but isn't. So if there's a memory leak, it could be a reference count issue on the file struct, or the file not being properly detached from the fd table.
Let's re-examine `io_uring` though, because something doesn't sit right... If `io_uring_setup` *did* succeed (which it shouldn't with those args, I know), could it *still* be leaking something unrelated to the initial `-EFAULT`? I need to know *when* `IORING_MEM_REGION_TYPE_USER` was introduced. Is it a new flag that's exposing a race condition?
|
| 31/2 |
2026/06/12 22:22 |
tool |
grepper |
0m
Args: map[Expression:IORING_MEM_REGION_TYPE_USER]
Results: map[Output:Documentation/networking/iou-zcrx.rst=111=Fill in registration structs::
--
Documentation/networking/iou-zcrx.rst-121- .size = ring_size,
Documentation/networking/iou-zcrx.rst:122: .flags = IORING_MEM_REGION_TYPE_USER,
Documentation/networking/iou-zcrx.rst-123- };
--
include/uapi/linux/io_uring.h=746=enum {
include/uapi/linux/io_uring.h-747- /* initialise with user provided memory pointed by user_addr */
include/uapi/linux/io_uring.h:748: IORING_MEM_REGION_TYPE_USER = 1,
include/uapi/linux/io_uring.h-749-};
--
io_uring/io_uring.c=2731=static __cold int io_allocate_scq_urings(struct io_ring_ctx *ctx,
--
io_uring/io_uring.c-2747- rd.user_addr = p->cq_off.user_addr;
io_uring/io_uring.c:2748: rd.flags |= IORING_MEM_REGION_TYPE_USER;
io_uring/io_uring.c-2749- }
--
io_uring/io_uring.c-2761- rd.user_addr = p->sq_off.user_addr;
io_uring/io_uring.c:2762: rd.flags |= IORING_MEM_REGION_TYPE_USER;
io_uring/io_uring.c-2763- }
--
io_uring/kbuf.c=616=int io_register_pbuf_ring(struct io_ring_ctx *ctx, void __user *arg)
--
io_uring/kbuf.c-662- rd.user_addr = reg.ring_addr;
io_uring/kbuf.c:663: rd.flags |= IORING_MEM_REGION_TYPE_USER;
io_uring/kbuf.c-664- }
--
io_uring/memmap.c=184=int io_create_region(struct io_ring_ctx *ctx, struct io_mapped_region *mr,
--
io_uring/memmap.c-194- return -EINVAL;
io_uring/memmap.c:195: if (reg->flags & ~IORING_MEM_REGION_TYPE_USER)
io_uring/memmap.c-196- return -EINVAL;
io_uring/memmap.c-197- /* user_addr should be set IFF it's a user memory backed region */
io_uring/memmap.c:198: if ((reg->flags & IORING_MEM_REGION_TYPE_USER) != !!reg->user_addr)
io_uring/memmap.c-199- return -EFAULT;
--
io_uring/memmap.c-216-
io_uring/memmap.c:217: if (reg->flags & IORING_MEM_REGION_TYPE_USER)
io_uring/memmap.c-218- ret = io_region_pin_pages(mr, reg);
--
io_uring/register.c=498=static int io_register_resize_rings(struct io_ring_ctx *ctx, void __user *arg)
--
io_uring/register.c-528- rd.user_addr = p->cq_off.user_addr;
io_uring/register.c:529: rd.flags |= IORING_MEM_REGION_TYPE_USER;
io_uring/register.c-530- }
--
io_uring/register.c-558- rd.user_addr = p->sq_off.user_addr;
io_uring/register.c:559: rd.flags |= IORING_MEM_REGION_TYPE_USER;
io_uring/register.c-560- }
--
tools/testing/selftests/drivers/net/hw/iou-zcrx.c=141=static void setup_zcrx(struct io_uring *ring)
--
tools/testing/selftests/drivers/net/hw/iou-zcrx.c-184- .user_addr = (__u64)(unsigned long)ring_ptr,
tools/testing/selftests/drivers/net/hw/iou-zcrx.c:185: .flags = IORING_MEM_REGION_TYPE_USER,
tools/testing/selftests/drivers/net/hw/iou-zcrx.c-186- };
]
|
| 32/2 |
2026/06/12 22:22 |
llm |
expert |
0m
Model:
Tokens:
input: 97251
output: 38
thoughts: 2193
Thoughts: **Analyzing the io_uring_setup Reproducer**
Okay, so I'm digging into this `io_uring_setup` reproducer. Initially, I was thinking about the return values of `io_uring_setup` – either a file descriptor (`fd`) or an index (`idx`), and in case of failure, `-EFAULT`. But the code's got some interesting twists.
The first thing I see is that it's writing directly to memory addresses: `0x200000000040` onward, to be precise. That looks like it's setting up the `io_uring_params` structure. I can see the data being written, but I'll need to figure out what those specific values are for. The `entries` parameter is set to `0x523` when calling `io_uring_setup`, and the `params` is at address `0x200000000040`.
Now, if I think about the offsets within `io_uring_params`, `sq_off` and `cq_off` are at `0x28` and `0x50`, respectively. So, the corresponding addresses for these would be `0x200000000068` and `0x200000000090`. But, here's where it gets interesting: the reproducer also makes a call to `sendmsg` *before* the `io_uring_setup` call. The values for `sendmsg` include:
```c
*(uint64_t*)0x200000000080 = 0;
*(uint32_t*)0x200000000088 = 0;
*(uint64_t*)0x200000000090 = 0;
*(uint64_t*)0x200000000098 = 1;
*(uint64_t*)0x2000000000a0 = 0;
*(uint64_t*)0x2000000000a8 = 0;
*(uint32_t*)0x2000000000b0 = 0;
syscall(__NR_sendmsg, /*fd=*/(intptr_t)-1, /*msg=*/0x200000000080ul, /*f=MSG_ZEROCOPY|MSG_FASTOPEN|MSG_OOB|MSG_NOSIGNAL|MSG_DONTWAIT|MSG_DONTROUTE*/0x24004045ul);
```
Critically, these offsets overlap with what's being initialized for the `io_uring_setup` call, specifically, `0x200000000090`, which I calculated as `cq_off`'s location.
Then after, the call `io_uring_setup` is made. It looks like it does not re-initialize the `cq_off` or `sq_off` locations after this call. I'm noting the address `0x200000000080` (where some `sendmsg` struct data is written to), that corresponds to the initial `io_uring_params` location (`0x200000000040`).
But wait, I need to check something: The reproducer then calls `prctl` *before* the `sendmsg` call, and sets values:
```c
*(uint64_t*)0x200000000080 = 0x200000ff7000;
*(uint64_t*)0x200000000088 = 0x200000ff1000;
*(uint64_t*)0x200000000090 = 0x200000ff1000;
*(uint64_t*)0x200000000098 = 0x200000ff5000;
*(uint64_t*)0x2000000000a0 = 0x200000ff8000;
*(uint64_t*)0x2000000000a
|
| 33/2 |
2026/06/12 22:22 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_uring_create]
Results: map[SourceCode:2978: static __cold int io_uring_create(struct io_ctx_config *config)
2979: {
2980: struct io_uring_params *p = &config->p;
2981: struct io_ring_ctx *ctx;
2982: struct io_uring_task *tctx;
2983: struct file *file;
2984: int ret;
2985:
2986: ret = io_prepare_config(config);
2987: if (ret)
2988: return ret;
2989:
2990: ctx = io_ring_ctx_alloc(p);
2991: if (!ctx)
2992: return -ENOMEM;
2993:
2994: ctx->clockid = CLOCK_MONOTONIC;
2995: ctx->clock_offset = 0;
2996:
2997: if (!(ctx->flags & IORING_SETUP_NO_SQARRAY))
2998: static_branch_deferred_inc(&io_key_has_sqarray);
2999:
3000: if ((ctx->flags & IORING_SETUP_DEFER_TASKRUN) &&
3001: !(ctx->flags & IORING_SETUP_IOPOLL))
3002: ctx->int_flags |= IO_RING_F_TASK_COMPLETE;
3003:
3004: if ((ctx->int_flags & IO_RING_F_TASK_COMPLETE) ||
3005: (ctx->flags & IORING_SETUP_IOPOLL))
3006: ctx->int_flags |= IO_RING_F_LOCKLESS_CQ;
3007:
3008: /*
3009: * lazy poll_wq activation relies on ->task_complete for synchronisation
3010: * purposes, see io_activate_pollwq()
3011: */
3012: if (!(ctx->int_flags & IO_RING_F_TASK_COMPLETE))
3013: ctx->int_flags |= IO_RING_F_POLL_ACTIVATED;
3014:
3015: /*
3016: * When SETUP_IOPOLL and SETUP_SQPOLL are both enabled, user
3017: * space applications don't need to do io completion events
3018: * polling again, they can rely on io_sq_thread to do polling
3019: * work, which can reduce cpu usage and uring_lock contention.
3020: */
3021: if (ctx->flags & IORING_SETUP_IOPOLL &&
3022: !(ctx->flags & IORING_SETUP_SQPOLL))
3023: ctx->int_flags |= IO_RING_F_SYSCALL_IOPOLL;
3024:
3025: if (in_compat_syscall())
3026: ctx->int_flags |= IO_RING_F_COMPAT;
3027: if (!ns_capable_noaudit(&init_user_ns, CAP_IPC_LOCK))
3028: ctx->user = get_uid(current_user());
3029:
3030: /*
3031: * For SQPOLL, we just need a wakeup, always. For !SQPOLL, if
3032: * COOP_TASKRUN is set, then IPIs are never needed by the app.
3033: */
3034: if (ctx->flags & (IORING_SETUP_SQPOLL|IORING_SETUP_COOP_TASKRUN))
3035: ctx->notify_method = TWA_SIGNAL_NO_IPI;
3036: else
3037: ctx->notify_method = TWA_SIGNAL;
3038:
3039: /*
3040: * If the current task has restrictions enabled, then copy them to
3041: * our newly created ring and mark it as registered.
3042: */
3043: if (current->io_uring_restrict)
3044: io_ctx_restriction_clone(ctx, current->io_uring_restrict);
3045:
3046: /*
3047: * This is just grabbed for accounting purposes. When a process exits,
3048: * the mm is exited and dropped before the files, hence we need to hang
3049: * on to this mm purely for the purposes of being able to unaccount
3050: * memory (locked/pinned vm). It's not used for anything else.
3051: */
3052: mmgrab(current->mm);
3053: ctx->mm_account = current->mm;
3054:
3055: ret = io_allocate_scq_urings(ctx, config);
3056: if (ret)
3057: goto err;
3058:
3059: ret = io_sq_offload_create(ctx, p);
3060: if (ret)
3061: goto err;
3062:
3063: p->features = IORING_FEAT_FLAGS;
3064:
3065: if (copy_to_user(config->uptr, p, sizeof(*p))) {
3066: ret = -EFAULT;
3067: goto err;
3068: }
3069:
3070: if (ctx->flags & IORING_SETUP_SINGLE_ISSUER
3071: && !(ctx->flags & IORING_SETUP_R_DISABLED))
3072: ctx->submitter_task = get_task_struct(current);
3073:
3074: file = io_uring_get_file(ctx);
3075: if (IS_ERR(file)) {
3076: ret = PTR_ERR(file);
3077: goto err;
3078: }
3079:
3080: ret = __io_uring_add_tctx_node(ctx);
3081: if (ret)
3082: goto err_fput;
3083: tctx = current->io_uring;
3084:
3085: /*
3086: * Install ring fd as the very last thing, so we don't risk someone
3087: * having closed it before we finish setup
3088: */
3089: if (p->flags & IORING_SETUP_REGISTERED_FD_ONLY)
3090: ret = io_ring_add_registered_file(tctx, file, 0, IO_RINGFD_REG_MAX);
3091: else
3092: ret = io_uring_install_fd(file);
3093: if (ret < 0)
3094: goto err_fput;
3095:
3096: trace_io_uring_create(ret, ctx, p->sq_entries, p->cq_entries, p->flags);
3097: return ret;
3098: err:
3099: io_ring_ctx_wait_and_kill(ctx);
3100: return ret;
3101: err_fput:
3102: fput(file);
3103: return ret;
3104: }
SourceFile:io_uring/io_uring.c]
|
| 34/2 |
2026/06/12 22:22 |
llm |
expert |
0m
Model:
Tokens:
input: 102523
output: 38
thoughts: 240
Thoughts: **Analyzing Potential Resource Leaks in the io_uring Setup Reproducer**
Okay, so I'm digging into this code and trying to pinpoint a possible file descriptor leak. My initial thought was focused on the `io_allocate_scq_urings` failure path. If that function errors out, we jump to `err:` which calls `io_ring_ctx_wait_and_kill(ctx)`. I was concerned that maybe we'd have a dangling file descriptor. However, it looks like that's safe; the `file` variable isn't even allocated at that point, so no leak there.
Now, if `io_uring_setup` succeeds, things get a bit more interesting. I noticed that the reproducer doesn't explicitly close the file descriptor returned by `io_uring_setup`. That's a red flag! But wait, the reproducer uses `IORING_SETUP_REGISTERED_FD_ONLY`, which is crucial. This changes things. `io_uring_setup` returns an *index* into a registration table, not a standard file descriptor.
The actual file information, as I understand it, is stored in `tctx->registered_rings[idx]`. This means the file descriptor isn't directly exposed in the usual way. So, how is this handled on exit? When the process terminates, I believe `__io_uring_cancel` gets called. And, that function calls `io_uring_unreg_ringfd`.
Looking closer at `io_uring_unreg_ringfd`, it iterates through `tctx->registered_rings` and calls `fput` on each entry. This should release the file descriptors, or at least trigger their cleanup. This seems reasonable. But… just to be 100% sure, I need to confirm that `__io_uring_cancel` is reliably called when the process exits. I'll need to double check how `io_uring_task_cancel` is involved, to confirm it.
|
| 35/2 |
2026/06/12 22:22 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/cancel.c Name:io_uring_task_cancel]
Results: map[SourceCode: 22: static inline void io_uring_task_cancel(void)
23: {
24: if (current->io_uring)
25: __io_uring_cancel(true);
26: }
SourceFile:include/linux/io_uring.h]
|
| 36/2 |
2026/06/12 22:22 |
llm |
expert |
0m
Model:
Tokens:
input: 103321
output: 41
thoughts: 82
Thoughts: Here's my summary, as the expert:
**Investigating a Potential io_uring Resource Leak During Process Exit**
Okay, so I'm digging into this `io_uring` cleanup process, and something's bugging me. I'm following the flow from `do_exit` and I see that `io_uring_task_cancel` is being called. That's good, that's what I expect. Which means that `__io_uring_cancel` is the ultimate function being called in this context.
But then my mind races. What if, during a process exit, `io_uring_unreg_ringfd` gets called *before* something crucial is done? Specifically, what if `io_uring_unreg_ringfd` is called *without* properly clearing the `tctx->registered_rings[idx]` entry? That could lead to a dangling reference, a possible resource leak! I need to verify how `io_uring_unreg_ringfd` works in this scenario. I have to trace into that function and check for that specific race condition. I'm going to dig into the `io_uring_unreg_ringfd` implementation to make sure this isn't happening, or, to identify where it is, and then design a fix.
|
| 37/2 |
2026/06/12 22:22 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/tctx.c Name:io_uring_unreg_ringfd]
Results: map[SourceCode: 257: void io_uring_unreg_ringfd(void)
258: {
259: struct io_uring_task *tctx = current->io_uring;
260: int i;
261:
262: for (i = 0; i < IO_RINGFD_REG_MAX; i++) {
263: if (tctx->registered_rings[i]) {
264: fput(tctx->registered_rings[i]);
265: tctx->registered_rings[i] = NULL;
266: }
267: }
268: }
SourceFile:io_uring/tctx.c]
|
| 38/2 |
2026/06/12 22:22 |
llm |
expert |
0m
Model:
Tokens:
input: 103929
output: 38
thoughts: 464
Thoughts: **Analyzing the Resource Management in `io_uring_create`**
Okay, so I'm stepping through this `io_uring_create` function, trying to understand the resource handling. It seems straightforward initially: it grabs a file using `io_uring_get_file` and then sets it to `NULL`, implying the file descriptor is released. Right, so a file should be freed. But, wait, I need to check the error handling.
Looking closer, if `io_uring_create` fails *after* `io_uring_get_file`, we might have a problem. The code block clearly shows that after acquiring the `file` pointer, the program calls `__io_uring_add_tctx_node`, `io_ring_add_registered_file`, or `io_uring_install_fd`. Then, there's an `err_fput` label that is reached if something goes wrong. If `io_ring_add_registered_file` fails, it jumps to this `err_fput`, and that does an `fput(file)` call.
Hang on a second. If that `fput(file)` gets called, doesn't that mean the file is freed, potentially leaving a dangling pointer? The `io_uring_get_file` function uses `anon_inode_create_getfile` to create a file, and its `private_data` is set to `ctx`. Thus, when the file is freed, `io_uring_release` will be called. So, I need to understand what happens during the release. Let's see how `io_uring_release` is handled.
|
| 39/2 |
2026/06/12 22:22 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_uring_release]
Results: map[SourceCode:2448: static int io_uring_release(struct inode *inode, struct file *file)
2449: {
2450: struct io_ring_ctx *ctx = file->private_data;
2451:
2452: file->private_data = NULL;
2453: io_ring_ctx_wait_and_kill(ctx);
2454: return 0;
2455: }
SourceFile:io_uring/io_uring.c]
|
| 40/2 |
2026/06/12 22:22 |
llm |
expert |
0m
Model:
Tokens:
input: 104934
output: 39
thoughts: 258
Thoughts: **Analyzing a Potential io_uring File Descriptor Leak**
Okay, so I'm tracing through this potential leak in the `io_uring` code, and something's bugging me. Specifically, I'm trying to understand the lifecycle of the file descriptor and ring context. If `io_uring_create` errors and goes to `err_fput`, it calls `fput(file)`. That means the file is being cleaned up there. Then `io_uring_release` gets called, which in turn calls `io_ring_ctx_wait_and_kill(ctx)`. But, hold on a second! `io_uring_create` returns `ret`, so the `err_fput` path *doesn't* call `io_ring_ctx_wait_and_kill(ctx)` directly. `io_uring_release` handles that! It makes sense, as the caller should manage the cleanup based on the return value.
Now, I'm wondering about the return path; what if `io_uring_create` returns `ret` *and* `sys_io_uring_setup` returns `ret`? Could there be a double free or, even worse, a leak? No, because `fput(file)` should free the file and the ring context. It looks like it should be safe.
However, the bug report mentions the leak originates from `alloc_empty_file` called from `path_openat`. But wait, `path_openat` is called from `do_sys_openat2`. That's not the same as `anon_inode_create_getfile`! Does `anon_inode_create_getfile` call `alloc_empty_file`? I need to verify that. I'm going to look at the implementation of `anon_inode_create_getfile` to be certain.
|
| 41/2 |
2026/06/12 22:23 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/anon_inodes.c Name:anon_inode_create_getfile]
Results: map[SourceCode: 240: /**
241: * anon_inode_create_getfile - Like anon_inode_getfile(), but creates a new
242: * !S_PRIVATE anon inode rather than reuse the
243: * singleton anon inode and calls the
244: * inode_init_security_anon() LSM hook.
245: *
246: * @name: [in] name of the "class" of the new file
247: * @fops: [in] file operations for the new file
248: * @priv: [in] private data for the new file (will be file's private_data)
249: * @flags: [in] flags
250: * @context_inode:
251: * [in] the logical relationship with the new inode (optional)
252: *
253: * Create a new anonymous inode and file pair. This can be done for two
254: * reasons:
255: *
256: * - for the inode to have its own security context, so that LSMs can enforce
257: * policy on the inode's creation;
258: *
259: * - if the caller needs a unique inode, for example in order to customize
260: * the size returned by fstat()
261: *
262: * The LSM may use @context_inode in inode_init_security_anon(), but a
263: * reference to it is not held.
264: *
265: * Returns the newly created file* or an error pointer.
266: */
267: struct file *anon_inode_create_getfile(const char *name,
268: const struct file_operations *fops,
269: void *priv, int flags,
270: const struct inode *context_inode)
271: {
272: return __anon_inode_getfile(name, fops, priv, flags,
273: context_inode, true);
274: }
SourceFile:fs/anon_inodes.c]
|
| 42/2 |
2026/06/12 22:23 |
llm |
expert |
0m
Model:
Tokens:
input: 106246
output: 38
thoughts: 20
Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person:
**Initial Confusion and Rapid Deduction**
Right, *wait a minute*. I'm digging into `__anon_inode_getfile`, and something's not sitting right. This code path… this critical part of the anonymous inode creation process… is it *actually* calling `alloc_empty_file`? That's… unexpected. `alloc_empty_file` is supposed to be a low-level file allocation primitive; I wouldn't have automatically associated it with the high-level anonymous inode handling. It's almost like someone built it up from the very bottom! I need to retrace my mental steps. Is this optimization? Or a specific design choice? It might have important consequences down the line in file system internals or resource allocation. I’m going to need to look into this more deeply.
|
| 43/2 |
2026/06/12 22:23 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/anon_inodes.c Name:__anon_inode_getfile]
Results: map[SourceCode: 134: static struct file *__anon_inode_getfile(const char *name,
135: const struct file_operations *fops,
136: void *priv, int flags,
137: const struct inode *context_inode,
138: bool make_inode)
139: {
140: struct inode *inode;
141: struct file *file;
142:
143: if (fops->owner && !try_module_get(fops->owner))
144: return ERR_PTR(-ENOENT);
145:
146: if (make_inode) {
147: inode = anon_inode_make_secure_inode(anon_inode_mnt->mnt_sb,
148: name, context_inode);
149: if (IS_ERR(inode)) {
150: file = ERR_CAST(inode);
151: goto err;
152: }
153: } else {
154: inode = anon_inode_inode;
155: if (IS_ERR(inode)) {
156: file = ERR_PTR(-ENODEV);
157: goto err;
158: }
159: /*
160: * We know the anon_inode inode count is always
161: * greater than zero, so ihold() is safe.
162: */
163: ihold(inode);
164: }
165:
166: file = alloc_file_pseudo(inode, anon_inode_mnt, name,
167: flags & (O_ACCMODE | O_NONBLOCK), fops);
168: if (IS_ERR(file))
169: goto err_iput;
170:
171: file->f_mapping = inode->i_mapping;
172:
173: file->private_data = priv;
174:
175: return file;
176:
177: err_iput:
178: iput(inode);
179: err:
180: module_put(fops->owner);
181: return file;
182: }
SourceFile:fs/anon_inodes.c]
|
| 44/2 |
2026/06/12 22:23 |
llm |
expert |
0m
Model:
Tokens:
input: 107177
output: 37
thoughts: 1670
Thoughts: **Unraveling the File Leak**
Okay, let's break this down. Initially, I was thinking the issue stemmed from `alloc_file_pseudo` calling `alloc_empty_file`, but the backtrace quickly revealed it wasn't. The call chain points directly to `path_openat`, indicating the leak originates from an `open` call, likely targeting `/dev/vbi3`. `syz_open_dev` is, in fact, opening that file with `O_RDWR`. The immediate question is, why would a standard `open` operation leak a file? `open` should either return a valid FD, which the process should close on exit or fail and free the file. I considered the possibility of the file not being in the FD table after a successful open, but `do_sys_openat2` clearly allocates an FD and installs the file into the FD table if `do_file_open` succeeds. So, standard file operations are out.
I then briefly considered `io_uring`, since it can do `IORING_OP_OPENAT`. However, the reproducer isn't using it. The `io_uring_enter` call fails, likely because `io_uring_setup` failed, making `io_uring` irrelevant. So, I had to rule out any association with file operations through `io_uring`.
So, what else? The key is the combination of an `open` call to `/dev/vbi3` followed by a `sendmsg` call involving netlink messages configuring Traffic Control (TC) filters. Could these filters hold references to files? No, TC filters primarily reference netdevices, BPF programs, or actions.
The next thing that jumps out is the `ct` action with `basic` filters. It makes me wonder if there's something there. I then saw the `prctl(PR_SET_MM_MAP, ...)` system call. That's a different way to play with file descriptors, and I should start by looking at `struct prctl_mm_map`. The `exe_fd` member is what caught my eye. The reproducer sets `exe_fd` to `-1`. Now I need to see what `prctl_set_mm_map` does with that. If `exe_fd` is valid, it sets `mm->exe_file` using the file from that FD, but what happens if it's `-1`? Does it clear `exe_file` or leave it untouched? I'm betting that's the key. I need to dive into `prctl_set_mm_map` to see how it handles a negative `exe_fd`.
|
| 45/2 |
2026/06/12 22:23 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:kernel/sys.c Name:prctl_set_mm_map]
Results: map[SourceCode:2060: static int prctl_set_mm_map(int opt, const void __user *addr, unsigned long data_size)
2061: {
2062: struct prctl_mm_map prctl_map = { .exe_fd = (u32)-1, };
2063: unsigned long user_auxv[AT_VECTOR_SIZE];
2064: struct mm_struct *mm = current->mm;
2065: int error;
2066:
2067: BUILD_BUG_ON(sizeof(user_auxv) != sizeof(mm->saved_auxv));
2068: BUILD_BUG_ON(sizeof(struct prctl_mm_map) > 256);
2069:
2070: if (opt == PR_SET_MM_MAP_SIZE)
2071: return put_user((unsigned int)sizeof(prctl_map),
2072: (unsigned int __user *)addr);
2073:
2074: if (data_size != sizeof(prctl_map))
2075: return -EINVAL;
2076:
2077: if (copy_from_user(&prctl_map, addr, sizeof(prctl_map)))
2078: return -EFAULT;
2079:
2080: error = validate_prctl_map_addr(&prctl_map);
2081: if (error)
2082: return error;
2083:
2084: if (prctl_map.auxv_size) {
2085: /*
2086: * Someone is trying to cheat the auxv vector.
2087: */
2088: if (!prctl_map.auxv ||
2089: prctl_map.auxv_size > sizeof(mm->saved_auxv))
2090: return -EINVAL;
2091:
2092: memset(user_auxv, 0, sizeof(user_auxv));
2093: if (copy_from_user(user_auxv,
2094: (const void __user *)prctl_map.auxv,
2095: prctl_map.auxv_size))
2096: return -EFAULT;
2097:
2098: /* Last entry must be AT_NULL as specification requires */
2099: user_auxv[AT_VECTOR_SIZE - 2] = AT_NULL;
2100: user_auxv[AT_VECTOR_SIZE - 1] = AT_NULL;
2101: }
2102:
2103: if (prctl_map.exe_fd != (u32)-1) {
2104: /*
2105: * Check if the current user is checkpoint/restore capable.
2106: * At the time of this writing, it checks for CAP_SYS_ADMIN
2107: * or CAP_CHECKPOINT_RESTORE.
2108: * Note that a user with access to ptrace can masquerade an
2109: * arbitrary program as any executable, even setuid ones.
2110: * This may have implications in the tomoyo subsystem.
2111: */
2112: if (!checkpoint_restore_ns_capable(current_user_ns()))
2113: return -EPERM;
2114:
2115: error = prctl_set_mm_exe_file(mm, prctl_map.exe_fd);
2116: if (error)
2117: return error;
2118: }
2119:
2120: /*
2121: * arg_lock protects concurrent updates but we still need mmap_lock for
2122: * read to exclude races with sys_brk.
2123: */
2124: mmap_read_lock(mm);
2125:
2126: /*
2127: * We don't validate if these members are pointing to
2128: * real present VMAs because application may have correspond
2129: * VMAs already unmapped and kernel uses these members for statistics
2130: * output in procfs mostly, except
2131: *
2132: * - @start_brk/@brk which are used in do_brk_flags but kernel lookups
2133: * for VMAs when updating these members so anything wrong written
2134: * here cause kernel to swear at userspace program but won't lead
2135: * to any problem in kernel itself
2136: */
2137:
2138: spin_lock(&mm->arg_lock);
2139: mm->start_code = prctl_map.start_code;
2140: mm->end_code = prctl_map.end_code;
2141: mm->start_data = prctl_map.start_data;
2142: mm->end_data = prctl_map.end_data;
2143: mm->start_brk = prctl_map.start_brk;
2144: mm->brk = prctl_map.brk;
2145: mm->start_stack = prctl_map.start_stack;
2146: mm->arg_start = prctl_map.arg_start;
2147: mm->arg_end = prctl_map.arg_end;
2148: mm->env_start = prctl_map.env_start;
2149: mm->env_end = prctl_map.env_end;
2150: spin_unlock(&mm->arg_lock);
2151:
2152: /*
2153: * Note this update of @saved_auxv is lockless thus
2154: * if someone reads this member in procfs while we're
2155: * updating -- it may get partly updated results. It's
2156: * known and acceptable trade off: we leave it as is to
2157: * not introduce additional locks here making the kernel
2158: * more complex.
2159: */
2160: if (prctl_map.auxv_size)
2161: memcpy(mm->saved_auxv, user_auxv, sizeof(user_auxv));
2162:
2163: mmap_read_unlock(mm);
2164: return 0;
2165: }
SourceFile:kernel/sys.c]
|
| 46/2 |
2026/06/12 22:23 |
llm |
expert |
0m
Model:
Tokens:
input: 111239
output: 49
thoughts: 599
Thoughts: **Analyzing a Potential Kernel File Descriptor Leak**
Okay, let's break this down. First, `prctl_map.exe_fd` being `-1` means `prctl` isn't touching files directly. That's a dead end. I need to think about what else is going on. What about `sendmsg`? The reproducer uses it for netlink and TC filter configuration, that's interesting.
The `basic` filter has `pedit`, `police`, `ct`, and `gact` actions. The `ct` action, that's for connection tracking, so probably no file handle there, it looks suspicious, though.
Ah, I see the reproducer also opens `/dev/vbi3`. But if the syzbot report is for a standard file open with an allocation in `alloc_empty_file` and then `path_openat`, `do_file_open`, and `do_sys_openat2`, so, a plain open? I was too quick to assume that it came from the device being opened. So, what if the leak isn't directly from `syz_open_dev`?
Could the `sendmsg` trigger a module load? If it requests a new TC action that requires a module, the kernel would use `request_module` to load that module. `request_module` then calls `call_usermodehelper`, which executes `/sbin/modprobe`! And `/sbin/modprobe` *does* open files! That's a solid lead!
But if `/sbin/modprobe` leaked the file, the `comm` in the syzbot report would be `modprobe`, not `syz.0.19`. The report explicitly says the `comm` is `syz.0.19`.
So, the leak is *in* `syz.0.19`. But `syz.0.19` calls `openat` and it is associated with a file descriptor! And looking at the stack, `syz_open_dev` calls `open` which is equivalent to `openat(AT_FDCWD, ...)`!
So, the leaked file is `/dev/vbi3`. That makes sense. I need to check the `vbi` driver. `/dev/vbiX` devices are V4L2 VBI devices. Those use `v4l2_open`, so it's a good place to start looking.
|
| 47/2 |
2026/06/12 22:23 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/media/v4l2-core/v4l2-dev.c Name:v4l2_open]
Results: map[SourceCode: 410: /* Override for the open function */
411: static int v4l2_open(struct inode *inode, struct file *filp)
412: {
413: struct video_device *vdev;
414: int ret;
415:
416: /* Check if the video device is available */
417: mutex_lock(&videodev_lock);
418: vdev = video_devdata(filp);
419: /* return ENODEV if the video device has already been removed. */
420: if (vdev == NULL || !video_is_registered(vdev)) {
421: mutex_unlock(&videodev_lock);
422: return -ENODEV;
423: }
424: /* and increase the device refcount */
425: video_get(vdev);
426: mutex_unlock(&videodev_lock);
427:
428: if (!video_is_registered(vdev)) {
429: ret = -ENODEV;
430: goto done;
431: }
432:
433: ret = vdev->fops->open(filp);
434: if (ret)
435: goto done;
436:
437: /* All drivers must use v4l2_fh. */
438: if (WARN_ON(!test_bit(V4L2_FL_USES_V4L2_FH, &vdev->flags))) {
439: vdev->fops->release(filp);
440: ret = -ENODEV;
441: }
442:
443: done:
444: if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
445: dprintk("%s: open (%d)\n",
446: video_device_node_name(vdev), ret);
447:
448: /* decrease the refcount in case of an error */
449: if (ret)
450: video_put(vdev);
451: return ret;
452: }
SourceFile:drivers/media/v4l2-core/v4l2-dev.c]
|
| 48/2 |
2026/06/12 22:23 |
llm |
expert |
0m
Model:
Tokens:
input: 113086
output: 41
thoughts: 894
Thoughts: **Analyzing a Potential File Descriptor Leak in an io_uring Scenario**
Okay, let's break this down. First, `v4l2_open` uses the file operations structure, calling `vdev->fops->open`. If `open` returns an error, it'll check `V4L2_FL_USES_V4L2_FH` and if it is not set will call `vdev->fops->release(filp)` and return `-ENODEV`. I was momentarily concerned about a file descriptor leak there, thinking `vdev->fops->release` might leave things dangling, but no, the VFS layer (`do_file_open` down to `do_dentry_open`) properly handles the cleanup with `fput(f)` if `open` fails. So, the file is freed if `v4l2_open` returns an error, which is good.
But what if `v4l2_open` *succeeds*? It returns a valid file descriptor. The reproducer I'm looking at *doesn't* explicitly close this file descriptor. My initial thought was that it's okay because when the process exits, `exit_files` should clean up all file descriptors, right? But that wasn't the case! So, something else is at play.
Then I saw that `io_uring` is involved. The reproducer calls `io_uring_setup` with `IORING_SETUP_REGISTERED_FD_ONLY`. Ah, the plot thickens. `io_uring_setup` returns an index, right? And then `io_uring_enter` is called with `fd = r[0]`.
Wait a minute, `r[0]` is the *index* returned by `io_uring_setup`! `io_uring_enter` expects a *real* file descriptor, not an index! If `r[0]` is zero (like the first registered fd), `io_uring_enter` will be passed fd 0. What's on fd 0? Standard input! It's definitely NOT an `io_uring` file descriptor.
Okay, so `io_uring_enter` will check if `fd 0` is valid using `io_is_uring_fops(f.file)`. It should return `-EOPNOTSUPP` because stdin isn't an io_uring file. So `io_uring_enter` does effectively nothing and the error will be `-EOPNOTSUPP`. That means the `io_uring` operation doesn't execute on stdin.
So, if `io_uring_setup` returns 0, it means `io_ring_add_registered_file` returned 0, which is the index.
But, with `IORING_SETUP_REGISTERED_FD_ONLY`, the file is *not* put into the fd table, it's just stored in `tctx->registered_rings[0]`.
Now, when the process exits, `__io_uring_cancel` is called, which then calls `io_uring_unreg_ringfd`. That function, crucial! It calls `fput(tctx->registered_rings[0])`. Okay, so the file descriptor is *supposed* to be freed on exit through this unregistering process. I'm going to double-check `io_uring_unreg_ringfd` again to make absolutely sure...
|
| 49/2 |
2026/06/12 22:23 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/tctx.c Name:io_uring_unreg_ringfd]
Results: map[SourceCode: 257: void io_uring_unreg_ringfd(void)
258: {
259: struct io_uring_task *tctx = current->io_uring;
260: int i;
261:
262: for (i = 0; i < IO_RINGFD_REG_MAX; i++) {
263: if (tctx->registered_rings[i]) {
264: fput(tctx->registered_rings[i]);
265: tctx->registered_rings[i] = NULL;
266: }
267: }
268: }
SourceFile:io_uring/tctx.c]
|
| 50/2 |
2026/06/12 22:23 |
llm |
expert |
0m
Model:
Tokens:
input: 114973
output: 37
thoughts: 43
Thoughts: Okay, let's break this down.
**Investigating the Call Chain of `io_uring_unreg_ringfd`**
Hmm, so `io_uring_unreg_ringfd` is called from within `__io_uring_cancel(bool cancel_all)`. Interesting. I need to understand that. My immediate thought is to trace the execution path from there. I need to dive into the `__io_uring_cancel` function itself to see what triggers the unregistration of the ring file descriptor. This likely involves understanding the different cancellation scenarios that function handles – whether it's specific requests or a global cancellation. This is a crucial area for analyzing potential resource leaks, race conditions, or unexpected behavior within the IO_uring subsystem. Understanding this linkage and what calls `__io_uring_cancel` will be essential.
|
| 51/2 |
2026/06/12 22:23 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/cancel.c Name:__io_uring_cancel]
Results: map[SourceCode: 437: void __io_uring_cancel(bool cancel_all)
438: {
439: io_uring_unreg_ringfd();
440: io_uring_cancel_generic(cancel_all, NULL);
441: }
SourceFile:io_uring/cancel.c]
|
| 52/2 |
2026/06/12 22:23 |
llm |
expert |
0m
Model:
Tokens:
input: 115334
output: 40
thoughts: 22
Thoughts: Here's my take on those thoughts, tailored for an expert audience:
**Digging into the io_uring Cancellation Path**
Okay, so I'm tracing through the `io_uring` codebase again, specifically focusing on the cancellation mechanisms. It looks like `__io_uring_cancel` is the core function for handling cancellation, which isn't entirely surprising. But what's interesting is that the actual call to `__io_uring_cancel` originates from `io_uring_task_cancel`. I need to figure out the context of `io_uring_task_cancel`. Are we talking about cancellation within a specific task context or a more global request-level cancellation? What situations does it handle? Are there potential race conditions I need to consider with that approach? Does it take care of things like double-cancels, etc.
I'm thinking about the implications for different cancellation modes and how this interacts with things like linked requests. Where does the cancellation actually happen? Is it at the CQE submission, or does it depend on the internal structure of `io_uring` and the actual operations requested. The details of the code really matter to ensure its robustness and performance. Time to dig in and clarify some finer points.
|
| 53/2 |
2026/06/12 22:23 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:include/linux/io_uring.h Name:io_uring_task_cancel]
Results: map[SourceCode: 22: static inline void io_uring_task_cancel(void)
23: {
24: if (current->io_uring)
25: __io_uring_cancel(true);
26: }
SourceFile:include/linux/io_uring.h]
|
| 54/2 |
2026/06/12 22:23 |
llm |
expert |
0m
Model:
Tokens:
input: 115749
output: 21
thoughts: 19
Thoughts: Here's a summary of my thought process, as requested:
**Understanding `io_uring_task_cancel` and `do_exit` Interaction**
Okay, so I'm digging into this kernel code, and it's hitting me: `io_uring_task_cancel` is actually called from `do_exit`. This is significant because `do_exit` is the heart of the process termination sequence. I need to understand why this function, responsible for canceling I/O operations tied to a specific task (process or thread), is being invoked right at the moment the task is preparing to vanish.
What are the implications here? Is this a cleanup mechanism? Are we attempting to prevent dangling I/O operations when a process is exiting? Are there resource leaks that this is designed to mitigate? The timing is critical; `do_exit` is the last chance, it seems. I need to trace the control flow through these functions and see exactly where and why `io_uring_task_cancel` is being called and what its overall objectives are within the termination process. This potentially explains some edge cases I've been seeing with I/O operations going stale, or, perhaps, errors related to incomplete operations when the process abruptly stops.
|
| 55/2 |
2026/06/12 22:23 |
tool |
grepper |
0m
Args: map[Expression:io_uring_task_cancel]
Results: map[Output:fs/exec.c=1091=int begin_new_exec(struct linux_binprm * bprm)
--
fs/exec.c-1122- */
fs/exec.c:1123: io_uring_task_cancel();
fs/exec.c-1124-
--
include/linux/io_uring.h=17=static inline void io_uring_files_cancel(void)
--
include/linux/io_uring.h-21-}
include/linux/io_uring.h:22:static inline void io_uring_task_cancel(void)
include/linux/io_uring.h-23-{
--
include/linux/io_uring.h=32=static inline int io_uring_fork(struct task_struct *tsk)
--
include/linux/io_uring.h-39-#else
include/linux/io_uring.h:40:static inline void io_uring_task_cancel(void)
include/linux/io_uring.h-41-{
]
|
| 56/2 |
2026/06/12 22:23 |
llm |
expert |
0m
Model:
Tokens:
input: 116315
output: 21
thoughts: 30
Thoughts: Okay, here's my interpretation of those thoughts, presented as a personal thought process, as requested:
**Navigating the `io_uring` Lifecycle - A Question of Termination**
Right, so I'm thinking about the interaction between `io_uring` and process termination. Specifically, I'm tracing how tasks are cancelled within the context of a new process execution. And that's where `io_uring_task_cancel` comes in. It gets called from `begin_new_exec`, which makes sense for cleaning up the uring context when a new executable is loaded. But then I have to ask the important question - what about `do_exit`? That's the other crucial path when a process is terminated. It handles the cleanup when a process exits or is killed. I need to make sure that the `io_uring` tasks and all the associated resources are properly cleaned up in that scenario as well. I need to ensure there isn't a race or a resource leak. The cancellation mechanism must be robust across both of these critical areas of process lifecycle management, from a program's initial setup and execution to its final termination. I need to double-check that `do_exit` includes the necessary calls or integrations to avoid lingering issues with orphaned uring tasks. It's a critical point to ensure proper system stability.
|
| 57/2 |
2026/06/12 22:24 |
tool |
grepper |
0m
Args: map[Expression:io_uring_files_cancel]
Results: map[Output:include/linux/io_uring.h=15=int __io_uring_fork(struct task_struct *tsk);
include/linux/io_uring.h-16-
include/linux/io_uring.h:17:static inline void io_uring_files_cancel(void)
include/linux/io_uring.h-18-{
--
include/linux/io_uring.h=40=static inline void io_uring_task_cancel(void)
--
include/linux/io_uring.h-42-}
include/linux/io_uring.h:43:static inline void io_uring_files_cancel(void)
include/linux/io_uring.h-44-{
--
kernel/exit.c=896=void __noreturn do_exit(long code)
--
kernel/exit.c-915-
kernel/exit.c:916: io_uring_files_cancel();
kernel/exit.c-917- sched_mm_cid_exit(tsk);
]
|
| 58/2 |
2026/06/12 22:24 |
llm |
expert |
0m
Model:
Tokens:
input: 116908
output: 40
thoughts: 33
Thoughts: Okay, here's my interpretation of those thoughts, tailored for an expert audience, presented in the first person:
**Investigating the Exit Procedure**
Alright, so `do_exit` is calling `io_uring_files_cancel()`. That's the key. My first thought is to dive right into `io_uring_files_cancel()` and see what it's actually doing. It has to be handling the cleanup of those file descriptors and outstanding I/O operations associated with io_uring before the process fully exits. I need to understand the cancellation mechanisms, the ordering, and what protections are in place to prevent resource leaks or race conditions during termination. Let's see how it gracefully cleans up any active file descriptors and queued I/O requests to ensure data integrity and avoid leaving any dangling references. This is a critical point in the system's stability, and I need to fully grasp its function.
|
| 59/2 |
2026/06/12 22:24 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:include/linux/io_uring.h Name:io_uring_files_cancel]
Results: map[SourceCode: 17: static inline void io_uring_files_cancel(void)
18: {
19: if (current->io_uring)
20: __io_uring_cancel(false);
21: }
SourceFile:include/linux/io_uring.h]
|
| 60/2 |
2026/06/12 22:24 |
llm |
expert |
0m
Model:
Tokens:
input: 117266
output: 36
thoughts: 433
Thoughts: **Analyzing a Potential io_uring File Descriptor Leak**
Okay, let's break this down. My initial thought was, "Hang on, `io_uring_files_cancel` *does* call `__io_uring_cancel(false)`, and that in turn calls `io_uring_unreg_ringfd()`. So, `io_uring_unreg_ringfd` *is* called during `do_exit` as I suspected. And if `io_uring_unreg_ringfd` *is* called, it definitely calls `fput(tctx->registered_rings[i])`. So the io_uring file itself *should* be freed."
But wait... a critical question arises: "What if `tctx->registered_rings` is *not* properly freed? Could that be the source of the problem?" I need to confirm how `io_uring_unreg_ringfd` handles this. Looking at the code:
```c
for (i = 0; i < IO_RINGFD_REG_MAX; i++) {
if (tctx->registered_rings[i]) {
fput(tctx->registered_rings[i]);
tctx->registered_rings[i] = NULL;
}
}
```
Okay, the code *should* be clearing the array. It iterates through the array and sets the entry to NULL *after* `fput` is called. That *should* ensure that both the file and the array entry are handled. Hmm. This brings up another possible failure case: what if `io_uring_unreg_ringfd` is called, but `tctx` is NULL?
However, given that `io_uring_files_cancel` has a check `if (current->io_uring)`, I can rule out the case that `tctx` is NULL.
So, let's revisit: what if `io_uring_unreg_ringfd` *is* called and `tctx->registered_rings` *does* contain the file and `fput` *is* called? The file *should* be freed then.
My brain is now thinking: could the leaked file be something *other* than the io_uring file itself? The syzbot report specifically mentioned `alloc_empty_file` from `path_openat`. I know `io_uring_get_file` calls `anon_inode_create_getfile`, which then calls `alloc_file_pseudo`, which *also* calls `alloc_empty_file`.
Wait a minute... `alloc_file_pseudo` calls `alloc_empty_file` directly? That's a key observation. That's a potential root cause, which needs to be looked at carefully. It's time to check `alloc_file_pseudo`.
|
| 61/2 |
2026/06/12 22:24 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/file_table.c Name:alloc_file_pseudo]
Results: map[SourceCode: 413: struct file *alloc_file_pseudo(struct inode *inode, struct vfsmount *mnt,
414: const char *name, int flags,
415: const struct file_operations *fops)
416: {
417: int ret;
418: struct path path;
419: struct file *file;
420:
421: ret = alloc_path_pseudo(name, inode, mnt, &path);
422: if (ret)
423: return ERR_PTR(ret);
424:
425: file = alloc_file(&path, flags, fops);
426: if (IS_ERR(file)) {
427: ihold(inode);
428: path_put(&path);
429: return file;
430: }
431: /*
432: * Disable all fsnotify events for pseudo files by default.
433: * They may be enabled by caller with file_set_fsnotify_mode().
434: */
435: file_set_fsnotify_mode(file, FMODE_NONOTIFY);
436: return file;
437: }
SourceFile:fs/file_table.c]
|
| 62/2 |
2026/06/12 22:24 |
llm |
expert |
1m
Model:
Tokens:
input: 118724
output: 34
thoughts: 177
Thoughts: **Debugging a File Allocation Issue**
Okay, so I'm looking at this syzbot report and trying to make sense of the call stack. The initial assumption was that `alloc_file` was the culprit, and that makes sense, as the name suggests it's handling file allocation, and that in turn calls `alloc_empty_file`. But wait... the backtrace itself is screaming something different. It explicitly shows `path_openat` calling `alloc_empty_file`. This is crucial! It means `path_openat`, not `alloc_file`, is the point of entry into that particular allocation path. This directly implies that the root cause lies within `path_openat` or a function it calls, not necessarily in the `alloc_file` function I initially suspected, and its calling path. This changes my entire debugging approach, this is a very interesting observation. I need to focus my investigation on the execution path initiated from `path_openat` now.
|
| 63/2 |
2026/06/12 22:25 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/namei.c Name:path_openat]
Results: map[SourceCode:4838: static struct file *path_openat(struct nameidata *nd,
4839: const struct open_flags *op, unsigned flags)
4840: {
4841: struct file *file;
4842: int error;
4843:
4844: file = alloc_empty_file(op->open_flag, current_cred());
4845: if (IS_ERR(file))
4846: return file;
4847:
4848: if (unlikely(file->f_flags & __O_TMPFILE)) {
4849: error = do_tmpfile(nd, flags, op, file);
4850: } else if (unlikely(file->f_flags & O_PATH)) {
4851: error = do_o_path(nd, flags, file);
4852: } else {
4853: const char *s = path_init(nd, flags);
4854: while (!(error = link_path_walk(s, nd)) &&
4855: (s = open_last_lookups(nd, file, op)) != NULL)
4856: ;
4857: if (!error)
4858: error = do_open(nd, file, op);
4859: terminate_walk(nd);
4860: }
4861: if (likely(!error)) {
4862: if (likely(file->f_mode & FMODE_OPENED))
4863: return file;
4864: WARN_ON(1);
4865: error = -EINVAL;
4866: }
4867: fput_close(file);
4868: if (error == -EOPENSTALE) {
4869: if (flags & LOOKUP_RCU)
4870: error = -ECHILD;
4871: else
4872: error = -ESTALE;
4873: }
4874: return ERR_PTR(error);
4875: }
SourceFile:fs/namei.c]
|
| 64/2 |
2026/06/12 22:25 |
llm |
expert |
0m
Model:
Tokens:
input: 119729
output: 42
thoughts: 1313
Thoughts: **Analyzing the `/dev/vbi3` File Leak**
Okay, so `path_openat` calls `alloc_empty_file`, that much is clear. The file leak is definitively from `openat`. The reproducer opens `/dev/vbi3`, so the leaked file *is* `/dev/vbi3`. That's the starting point. But *why* is it being leaked? Let's trace the steps.
The reproducer calls `syz_open_dev` to open `/dev/vbi3` (specifically, it targets device ID 3). Immediately after, it calls `sendmsg` to configure TC filters. I had a hunch; could the TC filter configuration be using the file descriptor?
Wait a second, the `sendmsg` call uses `fd = -1`, which should cause it to fail. If `sendmsg` fails, then nothing should happen. Looking closer, though, the reproducer sets a value within the `sendmsg` payload to `-1`. That value resides at `0x2000000065a4`. That gets my attention. Is the `sendmsg` payload *itself* using file descriptors? Let's examine the `sendmsg` payload more closely.
```c
// array[police_policy] {
// union police_policy {
// TCA_POLICE_RATE: nlattr_t[const[TCA_POLICE_RATE, int16], array[int32, 256]] {
// nla_len: offsetof = 0x404 (2 bytes)
// nla_type: const = 0x2 (2 bytes)
// payload: array[int32] {
...
// int32 = -1 (4 bytes)
```
The payload is a netlink message. Netlink messages, in general, don't pass file descriptors unless we're talking about `SCM_RIGHTS`. But the `sendmsg` `msg_control` is NULL (`ctrl: const = 0x0`, `ctrllen: const = 0x0`). Therefore, `SCM_RIGHTS` isn't in play.
Going back, though, what if that `-1` in `fd` is NOT what we expect it to be? The reproducer literally passes `-1` as the file descriptor: `syscall(__NR_sendmsg, /*fd=*/(intptr_t)-1, /*msg=*/0x200000006040ul, /*f=MSG_ZEROCOPY|MSG_BATCH|MSG_EOR|0x1000*/0x4041080ul);`. The kernel should return `-EBADF` if the file descriptor is `-1` and the call should fail.
Okay, let's step through if `sendmsg` *succeeds*. The next step is `io_uring_enter` is called with `fd = r[0]`. What if `io_uring_setup` returns a valid file descriptor. That would mean `r[0]` would be a valid fd, then `io_uring_enter` is called.
However, `sq_off.user_addr` is set to 0. So, I would assume that means `io_uring_setup` *failed*. But let's check.
Looking at `IORING_MEM_REGION_TYPE_USER`, that flag is used internally in `io_create_region`. `io_allocate_scq_urings` sets `rd.flags |= IORING_MEM_REGION_TYPE_USER` *if* `ctx->flags & IORING_SETUP_NO_MMAP`. `IORING_SETUP_NO_MMAP` is set if a bit is set to `1U << 14`. The reproducer uses `flags = 0x1c080`. Breaking that down: `0x1c080` = `0x10000 | 0x8000 | 0x4000 | 0x80`. `0x4000` is indeed `IORING_SETUP_NO_MMAP`!
This means `io_uring_setup` *must* fail because `user_addr` is zero. Therefore, `r[0]` will be `-1`. Thus, the next call, `io_uring_enter`, will *also* fail. And the program will simply exit and all files should close. This contradicts the memory leak!
Let's check `io_allocate_scq_urings`
|
| 65/2 |
2026/06/12 22:25 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_allocate_scq_urings]
Results: map[SourceCode:2731: static __cold int io_allocate_scq_urings(struct io_ring_ctx *ctx,
2732: struct io_ctx_config *config)
2733: {
2734: struct io_uring_params *p = &config->p;
2735: struct io_rings_layout *rl = &config->layout;
2736: struct io_uring_region_desc rd;
2737: struct io_rings *rings;
2738: int ret;
2739:
2740: /* make sure these are sane, as we already accounted them */
2741: ctx->sq_entries = p->sq_entries;
2742: ctx->cq_entries = p->cq_entries;
2743:
2744: memset(&rd, 0, sizeof(rd));
2745: rd.size = PAGE_ALIGN(rl->rings_size);
2746: if (ctx->flags & IORING_SETUP_NO_MMAP) {
2747: rd.user_addr = p->cq_off.user_addr;
2748: rd.flags |= IORING_MEM_REGION_TYPE_USER;
2749: }
2750: ret = io_create_region(ctx, &ctx->ring_region, &rd, IORING_OFF_CQ_RING);
2751: if (ret)
2752: return ret;
2753: ctx->rings = rings = io_region_get_ptr(&ctx->ring_region);
2754: rcu_assign_pointer(ctx->rings_rcu, rings);
2755: if (!(ctx->flags & IORING_SETUP_NO_SQARRAY))
2756: ctx->sq_array = (u32 *)((char *)rings + rl->sq_array_offset);
2757:
2758: memset(&rd, 0, sizeof(rd));
2759: rd.size = PAGE_ALIGN(rl->sq_size);
2760: if (ctx->flags & IORING_SETUP_NO_MMAP) {
2761: rd.user_addr = p->sq_off.user_addr;
2762: rd.flags |= IORING_MEM_REGION_TYPE_USER;
2763: }
2764: ret = io_create_region(ctx, &ctx->sq_region, &rd, IORING_OFF_SQES);
2765: if (ret) {
2766: io_rings_free(ctx);
2767: return ret;
2768: }
2769: ctx->sq_sqes = io_region_get_ptr(&ctx->sq_region);
2770:
2771: memset(rings, 0, sizeof(*rings));
2772: WRITE_ONCE(rings->sq_ring_mask, ctx->sq_entries - 1);
2773: WRITE_ONCE(rings->cq_ring_mask, ctx->cq_entries - 1);
2774: WRITE_ONCE(rings->sq_ring_entries, ctx->sq_entries);
2775: WRITE_ONCE(rings->cq_ring_entries, ctx->cq_entries);
2776: return 0;
2777: }
SourceFile:io_uring/io_uring.c]
|
| 66/2 |
2026/06/12 22:25 |
llm |
expert |
0m
Model:
Tokens:
input: 123019
output: 49
thoughts: 822
Thoughts: **Analyzing a Potential File Descriptor Leak**
Okay, first things first, I need to understand this `-EFAULT` return from `io_create_region` when `user_addr` is zero. The reproducer sets up these memory addresses: `0x200000000044`, `0x200000000048`, and so on. Right, so `0x20000000005c` is cleared with `memset` for 12 bytes, meaning the memory from that address up to `0x200000000067` is initialized to zero. And `0x200000000068` holds the value of `sq_off.user_addr`. So, is that `sq_off.user_addr` zero? Yep, it is. Since the memory was `mmap`ed with `MAP_ANONYMOUS`, it's zeroed out.
Now, here's a thought: What if `io_uring_setup` fails, but somehow the file descriptor leaks? I need to double-check `io_uring_create`. I see that `io_allocate_scq_urings` is called, and if it fails, it goes to `err` which calls `io_ring_ctx_wait_and_kill(ctx)`. Wait a second... the `file` pointer is allocated *after* `io_allocate_scq_urings`! If the allocation fails, the `file` is never actually allocated! So it doesn't leak that way.
Okay, so if it's not `io_uring`, what's leaking this file descriptor? Looking at the syzbot report, it looks like the relevant call stack is: `alloc_empty_file`, `path_openat`, `do_file_open`, and finally `do_sys_openat2`. That's `openat`! And the reproducer uses `open("/dev/vbi3", O_RDWR, 0)`.
Here's a thought though. If `open` returns a valid file descriptor and the process just exits, the file should be closed, right? Why would it leak? Is it possible that the file is somehow passed to another process? No, there is no `fork` or `sendmsg` calls with `SCM_RIGHTS`. So not that. Could this file descriptor be attached to some global state? Wait, `/dev/vbi3` is a V4L2 device, right? Does `v4l2_open` itself leak this file descriptor? Let's check `v4l2_open`.
|
| 67/2 |
2026/06/12 22:25 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/media/v4l2-core/v4l2-dev.c Name:v4l2_open]
Results: map[SourceCode: 410: /* Override for the open function */
411: static int v4l2_open(struct inode *inode, struct file *filp)
412: {
413: struct video_device *vdev;
414: int ret;
415:
416: /* Check if the video device is available */
417: mutex_lock(&videodev_lock);
418: vdev = video_devdata(filp);
419: /* return ENODEV if the video device has already been removed. */
420: if (vdev == NULL || !video_is_registered(vdev)) {
421: mutex_unlock(&videodev_lock);
422: return -ENODEV;
423: }
424: /* and increase the device refcount */
425: video_get(vdev);
426: mutex_unlock(&videodev_lock);
427:
428: if (!video_is_registered(vdev)) {
429: ret = -ENODEV;
430: goto done;
431: }
432:
433: ret = vdev->fops->open(filp);
434: if (ret)
435: goto done;
436:
437: /* All drivers must use v4l2_fh. */
438: if (WARN_ON(!test_bit(V4L2_FL_USES_V4L2_FH, &vdev->flags))) {
439: vdev->fops->release(filp);
440: ret = -ENODEV;
441: }
442:
443: done:
444: if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
445: dprintk("%s: open (%d)\n",
446: video_device_node_name(vdev), ret);
447:
448: /* decrease the refcount in case of an error */
449: if (ret)
450: video_put(vdev);
451: return ret;
452: }
SourceFile:drivers/media/v4l2-core/v4l2-dev.c]
|
| 68/2 |
2026/06/12 22:25 |
llm |
expert |
0m
Model:
Tokens:
input: 125149
output: 24
thoughts: 1528
Thoughts: **Unraveling a Potential File Descriptor Leak via io_uring**
Okay, so I'm diving into this issue. First, I see that `vdev->fops->open(filp)` is called. My mind immediately jumps to figuring out the `vdev->fops->open` function for `/dev/vbi3`. Is it the `vivid` driver? `v4l2-loopback`? Something else? Then, I note that `syz_open_dev` is used to open `/dev/vbi3`, and in syzkaller, this is typically associated with the `vivid` driver. My immediate thought is, does `vivid` have a file descriptor leak?
I check: `v4l2_open` returning 0 indicates a successful file opening, meaning the file descriptor ends up in the file descriptor table. Then, when the process exits, `exit_files` is supposed to call `fput` on that file, which in turn calls `fops->release` (specifically `v4l2_release`), and then `vdev->fops->release(filp)`. If this release function doesn't leak, then the file should be freed.
But wait a minute…what if `fput` isn't called? If the file's reference count is incremented *somewhere else*, `fput` will never reach zero. So I need to find who is doing that incrementing! I notice the reproducer calls `prctl(PR_SET_MM_MAP, ...)` with `exe_fd = -1`, which is pointless, and `sendmsg` with `fd = -1` which returns `-EBADF`. These do nothing.
Then, there's `io_uring_setup` with `flags = 0x1c080`. *Wait a second*, what if that *doesn't* fail? I need to re-examine `io_allocate_scq_urings`. Specifically, this block:
```c
if (ctx->flags & IORING_SETUP_NO_MMAP) {
rd.user_addr = p->cq_off.user_addr;
rd.flags |= IORING_MEM_REGION_TYPE_USER;
}
```
Okay, `p->cq_off.user_addr` is a `__u64`. I need to track how the reproducer sets the relevant memory.
Looking at the reproducer:
```c
*(uint32_t*)0x200000000044 = 0x3cb1; // cq_entries
*(uint32_t*)0x200000000048 = 0x1c080; // flags
*(uint32_t*)0x20000000004c = 0xa; // sq_thread_cpu
*(uint32_t*)0x200000000050 = 0x20002f7; // sq_thread_idle
*(uint32_t*)0x200000000058 = -1; // wq_fd
```
`0x200000000040` is `p`. So, `p->sq_off` is at offset `0x28`. `p->cq_off` is at `0x50`. The code is doing a series of write operations.
So, `0x200000000040 + 0x28 = 0x200000000068` and `0x200000000040 + 0x50 = 0x200000000090`. But then the reproducer does:
```c
*(uint64_t*)0x200000000080 = 0;
*(uint32_t*)0x200000000088 = 0;
*(uint64_t*)0x200000000090 = 0;
*(uint64_t*)0x200000000098 = 1;
*(uint64_t*)0x2000000000a0 = 0;
*(uint64_t*)0x2000000000a8 = 0
|
| 69/2 |
2026/06/12 22:26 |
tool |
codesearch-struct-layout |
0m
Args: map[Name:io_sqring_offsets]
Results: map[Fields:[map[Name:head OffsetBits:0 SizeBits:32] map[Name:tail OffsetBits:32 SizeBits:32] map[Name:ring_mask OffsetBits:64 SizeBits:32] map[Name:ring_entries OffsetBits:96 SizeBits:32] map[Name:flags OffsetBits:128 SizeBits:32] map[Name:dropped OffsetBits:160 SizeBits:32] map[Name:array OffsetBits:192 SizeBits:32] map[Name:resv1 OffsetBits:224 SizeBits:32] map[Name:user_addr OffsetBits:256 SizeBits:64]]]
|
| 70/2 |
2026/06/12 22:26 |
llm |
expert |
0m
Model:
Tokens:
input: 127914
output: 41
thoughts: 1238
Thoughts: **Analyzing the io_uring Setup and Potential Vulnerability**
Okay, let's break this down step by step. I'm looking at how `user_addr` is handled within `io_uring_setup`, and how it interacts with the `sendmsg` call.
First, I see that `user_addr` is at an offset of 32 bytes (0x20) within the struct. Therefore, `p->sq_off.user_addr` will be at `0x28 + 0x20 = 0x48`. Considering the base address of the struct (`0x200000000040`), the actual address is `0x200000000088`.
The reproducer attempts to set this address. Initially, it sets a 32-bit value at 0x88 to 0. But then, it sets a 64-bit value at 0x88 (using prctl) to `0x200000ff1000`. So, the upper 32 bits are `0x00002000` from the `mmap`. The following `sendmsg` syscall only clears the lower 32 bits and leaves the upper 32 bits unchanged from the `mmap`. This means `p->sq_off.user_addr` ends up being `0x200000000000`.
This address `0x200000000000` corresponds precisely to the start of the second `mmap` call. So, this value is valid. Thus, `io_uring_setup` WILL NOT return `-EFAULT` because the address is valid. It looks like syzkaller generated a valid `user_addr` by overlapping the structs!
I'm starting to see that `p->cq_off.user_addr` at `0x2000000000b0` undergoes a similar initialization. The calculations are the same, and eventually, the address becomes `0x200000000000`. This means both `p->sq_off.user_addr` and `p->cq_off.user_addr` are valid and point to the same address, which is the start of the second `mmap` region.
Now, if `io_uring_setup` succeeds (likely returning a file descriptor), it returns an index. Let's assume the index is 0. Then, the program calls `io_uring_enter` with `fd = 0`. But this would be stdin. However, `io_uring_enter` checks if the `fd` is a valid io_uring descriptor, and stdin isn't, so it should return `-EOPNOTSUPP`.
But if the program returns an `fd = 0` and is not closed, the program exits. Where's the leak?
I know that on exit, there is a call to `__io_uring_cancel` which calls `io_uring_unreg_ringfd`. This looks like it does `fput` on the registered ring. This must be the important step. Let me check the code for `io_uring_unreg_ringfd`.
|
| 71/2 |
2026/06/12 22:26 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/tctx.c Name:io_uring_unreg_ringfd]
Results: map[SourceCode: 257: void io_uring_unreg_ringfd(void)
258: {
259: struct io_uring_task *tctx = current->io_uring;
260: int i;
261:
262: for (i = 0; i < IO_RINGFD_REG_MAX; i++) {
263: if (tctx->registered_rings[i]) {
264: fput(tctx->registered_rings[i]);
265: tctx->registered_rings[i] = NULL;
266: }
267: }
268: }
SourceFile:io_uring/tctx.c]
|
| 72/2 |
2026/06/12 22:26 |
llm |
expert |
0m
Model:
Tokens:
input: 130122
output: 37
thoughts: 43
Thoughts: Here's my take on the thought process:
**Diving into the Cancellation Mechanism**
Okay, so I'm digging into how `io_uring` handles cancellations, and I've hit a key point: `io_uring_unreg_ringfd` is called from within `__io_uring_cancel(bool cancel_all)`. Hmm, that's interesting. It means that unregistering the ring file descriptor is tied into the cancellation process itself. I need to understand that relationship better. Let me jump into `__io_uring_cancel` and see what's happening in there. I'm especially interested in when and why that `io_uring_unreg_ringfd` call is triggered within that function.
|
| 73/2 |
2026/06/12 22:26 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/cancel.c Name:__io_uring_cancel]
Results: map[SourceCode: 437: void __io_uring_cancel(bool cancel_all)
438: {
439: io_uring_unreg_ringfd();
440: io_uring_cancel_generic(cancel_all, NULL);
441: }
SourceFile:io_uring/cancel.c]
|
| 74/2 |
2026/06/12 22:26 |
llm |
expert |
0m
Model:
Tokens:
input: 130464
output: 40
thoughts: 22
Thoughts: Here's my take on those thoughts, focusing on the implications:
**Deep Dive into IO_URing Cancellation**
Okay, so I'm digging into the `io_uring` codebase again, and I just noticed something that's got my attention. It looks like the `__io_uring_cancel` function is being invoked directly from `io_uring_files_cancel`. That's interesting, and it has some implications I need to consider, especially in the context of file-based operations.
My first thought is, why this direct connection? Is it a performance optimization? Does it bypass any higher-level cancellation logic for file descriptors, assuming these calls are special? Or maybe this means we're dealing with a lower-level function that provides more control over the cancellation process.
The significance here is that whatever mechanism is used by `io_uring_files_cancel` *must* be correctly integrated with the broader cancellation scheme of `io_uring`. I immediately start thinking about potential race conditions. We need to be absolutely sure that file-specific cancellation doesn't lead to any unexpected behaviors, like prematurely releasing resources or leaving the ring in an inconsistent state. Are there potential scenarios where the internal cancelation is mismanaged and a file can't be opened again in the same or future instances?
I need to trace the call paths and analyze the conditions that trigger this interaction. I also need to verify this against the current kernel, and any proposed patch sets. I'm going to have to test corner cases to make sure we don't have problems when a file descriptor is cancelled while being used. And, as always, I need to keep performance in mind - does this direct approach lead to any measurable performance improvements or regressions compared to alternative cancellation approaches?
|
| 75/2 |
2026/06/12 22:26 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:include/linux/io_uring.h Name:io_uring_files_cancel]
Results: map[SourceCode: 17: static inline void io_uring_files_cancel(void)
18: {
19: if (current->io_uring)
20: __io_uring_cancel(false);
21: }
SourceFile:include/linux/io_uring.h]
|
| 76/2 |
2026/06/12 22:26 |
llm |
expert |
0m
Model:
Tokens:
input: 130988
output: 23
thoughts: 916
Thoughts: **Analyzing an io_uring File Descriptor Leak**
Okay, so I'm looking at this issue, and the first thing that jumps out is the call to `__io_uring_cancel(false)`. Does that call `io_uring_unreg_ringfd`? Yes, it does. Okay, then that means the io_uring file descriptor should be freed because `io_uring_unreg_ringfd()` calls `fput` on `tctx->registered_rings[i]`. So, the io_uring file *is* freed! But wait... the syzbot report is about a leaked file. What if the *leaked* file isn't the io_uring file itself?
The syzbot report specifically mentions `alloc_empty_file` from `path_openat`. `path_openat` is used for regular files, like `/dev/vbi3`. Aha! The leaked file is actually `/dev/vbi3`! Now, why would *that* be leaked?
Let's look at the `io_uring_setup` parameters; specifically, I notice `IORING_SETUP_SQPOLL` is set. The code in the reproducer shows `0x1c080` being used. Let's unpack this: `0x1c080` translates to `IORING_SETUP_NO_SQARRAY | IORING_SETUP_REGISTERED_FD_ONLY | IORING_SETUP_NO_MMAP | IORING_SETUP_SUBMIT_ALL`. Hold on, `IORING_SETUP_SQPOLL` is `0x2`, and this value does not have `0x2`! `SQPOLL` is *not* set. I can decompose this further. It's `0x10000` (NO_SQARRAY) + `0x8000` (REGISTERED_FD_ONLY) + `0x4000` (NO_MMAP) + `0x80` (SUBMIT_ALL). This confirms that `SQPOLL` is *not* enabled.
Now, what if `io_uring_enter` doesn't fail? `io_uring_enter` is called with `fd = r[0]`. If `r[0]` is 0, the file descriptor is 0. But that's stdin. What if `io_uring_enter` *is* called with `fd = 0`, but `fd 0` is an io_uring file descriptor? No, the reproducer didn't close and replace `fd 0`.
Okay, the `sys_io_uring_enter` system call takes an `fd`. If that `fd` is an index into a registered ring, how does it know? Wait, no, `io_uring_enter` takes a *real* file descriptor. If we are using `IORING_SETUP_REGISTERED_FD_ONLY`, you *cannot* use the ring's index.
Aha! `io_uring_enter` has a flag: `IORING_ENTER_REGISTERED_RING`. Let's check the reproducer. It's calling `io_uring_enter` with `fd = r[0]`, and `flags = 0x16`. This translates to `IORING_ENTER_REGISTERED_RING | IORING_ENTER_SQ_WAIT | IORING_ENTER_SQ_WAKEUP`. `IORING_ENTER_REGISTERED_RING` is `0x10`. That's the key! Now I need to check `IORING_ENTER_REGISTERED_RING`.
|
| 77/2 |
2026/06/12 22:26 |
tool |
grepper |
0m
Args: map[Expression:IORING_ENTER_REGISTERED_RING]
Results: map[Output:include/uapi/linux/io_uring.h=580=struct io_cqring_offsets {
--
include/uapi/linux/io_uring.h-605-#define IORING_ENTER_EXT_ARG (1U << 3)
include/uapi/linux/io_uring.h:606:#define IORING_ENTER_REGISTERED_RING (1U << 4)
include/uapi/linux/io_uring.h-607-#define IORING_ENTER_ABS_TIMER (1U << 5)
--
io_uring/io_uring.c=2600=SYSCALL_DEFINE6(io_uring_enter, unsigned int, fd, u32, to_submit,
--
io_uring/io_uring.c-2610-
io_uring/io_uring.c:2611: file = io_uring_ctx_get_file(fd, flags & IORING_ENTER_REGISTERED_RING);
io_uring/io_uring.c-2612- if (IS_ERR(file))
--
io_uring/io_uring.c-2707-out:
io_uring/io_uring.c:2708: if (!(flags & IORING_ENTER_REGISTERED_RING))
io_uring/io_uring.c-2709- fput(file);
--
io_uring/io_uring.h=29=struct io_ctx_config {
--
io_uring/io_uring.h-79- IORING_ENTER_EXT_ARG |\
io_uring/io_uring.h:80: IORING_ENTER_REGISTERED_RING |\
io_uring/io_uring.h-81- IORING_ENTER_ABS_TIMER |\
--
tools/include/uapi/linux/io_uring.h=454=struct io_cqring_offsets {
--
tools/include/uapi/linux/io_uring.h-479-#define IORING_ENTER_EXT_ARG (1U << 3)
tools/include/uapi/linux/io_uring.h:480:#define IORING_ENTER_REGISTERED_RING (1U << 4)
tools/include/uapi/linux/io_uring.h-481-
]
|
| 78/2 |
2026/06/12 22:26 |
llm |
expert |
0m
Model:
Tokens:
input: 133313
output: 42
thoughts: 98
Thoughts: Okay, here's my interpretation of these thoughts, as if they were my own:
**Unpacking the io_uring_enter Logic**
Right, so I'm digging into `io_uring_enter` and *finally* it's clicking! Yes, the documentation is clear, but I just had to visualize the internals to be certain: `io_uring_enter` *does* support `IORING_ENTER_REGISTERED_RING`. That's the key. This means that, when that flag is set, it's going to bypass the typical file descriptor lookup. It's not going through the file descriptor table, it is using `tctx->registered_rings[fd]`. Got it.
And this means something crucial: It's *not* going to call `fput(file)` at the end of the operation! That's a huge performance win, avoiding the overhead of potentially releasing the file's resources. That was a potential bottleneck I was worried about.
Now, a related question pops up. Looking back, I can see that `io_uring_ctx_get_file` is actually the function that gets the file from the `tctx->registered_rings[fd]` structure, which the enter path uses. The thing is, does `io_uring_ctx_get_file` increment the reference count of the file? I need to verify that it's handling the file's lifetime correctly – that's critical to avoid memory corruption or resource leaks. I need to go back and check the implementation of that function *carefully*.
|
| 79/2 |
2026/06/12 22:26 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_uring_ctx_get_file]
Results: map[SourceCode:2565: /*
2566: * Given an 'fd' value, return the ctx associated with if. If 'registered' is
2567: * true, then the registered index is used. Otherwise, the normal fd table.
2568: * Caller must call fput() on the returned file if it isn't a registered file,
2569: * unless it's an ERR_PTR.
2570: */
2571: struct file *io_uring_ctx_get_file(unsigned int fd, bool registered)
2572: {
2573: struct file *file;
2574:
2575: if (registered) {
2576: /*
2577: * Ring fd has been registered via IORING_REGISTER_RING_FDS, we
2578: * need only dereference our task private array to find it.
2579: */
2580: struct io_uring_task *tctx = current->io_uring;
2581:
2582: if (unlikely(!tctx || fd >= IO_RINGFD_REG_MAX))
2583: return ERR_PTR(-EINVAL);
2584: fd = array_index_nospec(fd, IO_RINGFD_REG_MAX);
2585: file = tctx->registered_rings[fd];
2586: } else {
2587: file = fget(fd);
2588: }
2589:
2590: if (unlikely(!file))
2591: return ERR_PTR(-EBADF);
2592: if (io_is_uring_fops(file))
2593: return file;
2594: if (!registered)
2595: fput(file);
2596: return ERR_PTR(-EOPNOTSUPP);
2597: }
SourceFile:io_uring/io_uring.c]
|
| 80/2 |
2026/06/12 22:26 |
llm |
expert |
0m
Model:
Tokens:
input: 134326
output: 19
thoughts: 1525
Thoughts: **Analyzing the io_uring Vulnerability**
Okay, let's break this down. Initially, I was concerned about a potential reference count leak, but it seems `io_uring_ctx_get_file` doesn't increment the refcount if `registered` is true, and `io_uring_enter` doesn't `fput` in that case either, so the leak isn't there. Good.
Now, what about the scenario where `io_uring_enter` *does* submit a request? The reproducer is calling `io_uring_enter` with `IORING_ENTER_REGISTERED_RING`. The `to_submit` value is set to `0x1203`, and with `IORING_ENTER_SQ_WAIT|IORING_ENTER_SQ_WAKEUP` flags, I need to figure out what's being submitted. The user provided SQ and CQ ring addresses are both `0x200000000000`, a mmap'd region with `PROT_WRITE|PROT_READ|PROT_EXEC`, size `0x1000000`. And the reproducer writes `/dev/vbi#\000` to the beginning of this mapped region!
This is where things get interesting. This address, `0x200000000000` is the start of the SQ ring, which contains the ring metadata: `head`, `tail`, `ring_mask`, `ring_entries`, `flags`, `dropped`, `array`, `resv1`, and `user_addr`. The reproducer uses `IORING_SETUP_NO_SQARRAY`, so the SQEs are directly addressed, which means they are in-place in memory.
Now, I dig deeper into `io_allocate_scq_urings`. I see that both `sq_region` and `ring_region` are created using `0x200000000000` as the user address. The `io_create_region` function is used, which eventually calls `io_region_pin_pages`. Can *two* regions pin the same user pages? I know `pin_user_pages` allows multiple calls for the same pages. Bingo.
So `ctx->rings` and `ctx->sq_sqes` are pointing to the *same* memory! `ctx->rings` is a `struct io_rings`, and `ctx->sq_sqes` is an array of `struct io_uring_sqe`. If they overlap, then the SQEs are right there on top of the ring metadata. The key is in `io_uring_enter`. It reads `ctx->rings->sq.head` and `ctx->rings->sq.tail`. Since `/dev/vbi#\000` is at the beginning of the mapped region, these values are being read from that data!
Let's do the math. `/dev/vbi#\000` is `2f 64 65 76 2f 76 62 69 23 00`. Remember that little endian. `head` is at offset 0, so it's `0x7665642f` (1986356271). `tail` is at offset 4, which makes it `0x6962762f` (1768060463). Now the critical calculation: `tail - head`. Unsigned arithmetic, it is `4076671488`.
`io_uring_enter` will *try* to submit this number of SQEs, which is insane. However, the `to_submit` argument is only `0x1203`, or 4611, so that's the *actual* amount submitted.
The SQEs themselves are at `ctx->sq_sqes`, which is *also* at `0x200000000000`. That's where it all overlaps. The first SQE starts right where the ring data is. The `opcode` is at offset 0, which means it starts with `0x2f`. So what is op code 47? Need to check the definitions! This is almost certainly a vulnerability.
|
| 81/2 |
2026/06/12 22:27 |
tool |
grepper |
0m
Args: map[Expression:IORING_OP_]
Results: map[Output:
Full output is too long, showing 500 out of 1080 lines.
Use more precise expression if possible.
Documentation/filesystems/fuse/fuse-io-uring.rst=27=In order to set up fuse-over-io-uring fuse-server (user-space)
Documentation/filesystems/fuse/fuse-io-uring.rst:28:needs to submit SQEs (opcode = IORING_OP_URING_CMD) to the /dev/fuse
Documentation/filesystems/fuse/fuse-io-uring.rst-29-connection file descriptor. Initial submit is with the sub command
--
Documentation/filesystems/fuse/fuse-io-uring.rst=42=Initial SQE
--
Documentation/filesystems/fuse/fuse-io-uring.rst-47- | | >io_uring_submit()
Documentation/filesystems/fuse/fuse-io-uring.rst:48: | | IORING_OP_URING_CMD /
Documentation/filesystems/fuse/fuse-io-uring.rst-49- | | FUSE_URING_CMD_REGISTER
--
Documentation/filesystems/fuse/fuse-io-uring.rst=58=Sending requests with CQEs
--
Documentation/filesystems/fuse/fuse-io-uring.rst-80- | | >io_uring_submit()
Documentation/filesystems/fuse/fuse-io-uring.rst:81: | | IORING_OP_URING_CMD/
Documentation/filesystems/fuse/fuse-io-uring.rst-82- | | FUSE_URING_CMD_COMMIT_AND_FETCH
--
Documentation/networking/iou-zcrx.rst=156=Prepare a zero copy recv request::
--
Documentation/networking/iou-zcrx.rst-160- sqe = io_uring_get_sqe(ring);
Documentation/networking/iou-zcrx.rst:161: io_uring_prep_rw(IORING_OP_RECV_ZC, sqe, fd, NULL, 0, 0);
Documentation/networking/iou-zcrx.rst-162- sqe->ioprio |= IORING_RECV_MULTISHOT;
--
fs/fuse/dev_uring.c=1080=static int fuse_uring_register(struct io_uring_cmd *cmd,
--
fs/fuse/dev_uring.c-1125- * Entry function from io_uring to handle the given passthrough command
fs/fuse/dev_uring.c:1126: * (op code IORING_OP_URING_CMD)
fs/fuse/dev_uring.c-1127- */
--
fs/fuse/inode.c=1514=static struct fuse_init_args *fuse_new_init(struct fuse_mount *fm)
--
fs/fuse/inode.c-1551- * This is just an information flag for fuse server. No need to check
fs/fuse/inode.c:1552: * the reply - server is either sending IORING_OP_URING_CMD or not.
fs/fuse/inode.c-1553- */
--
include/linux/io_uring_types.h=235=struct io_restriction {
include/linux/io_uring_types.h-236- DECLARE_BITMAP(register_op, IORING_REGISTER_LAST);
include/linux/io_uring_types.h:237: DECLARE_BITMAP(sqe_op, IORING_OP_LAST);
include/linux/io_uring_types.h-238- struct io_bpf_filters *bpf_filters;
--
include/linux/io_uring_types.h-242- u8 sqe_flags_required;
include/linux/io_uring_types.h:243: /* IORING_OP_* restrictions exist */
include/linux/io_uring_types.h-244- bool op_registered;
--
include/linux/io_uring_types.h=707=struct io_kiocb {
--
include/linux/io_uring_types.h-764- /*
include/linux/io_uring_types.h:765: * for polled requests, i.e. IORING_OP_POLL_ADD and async armed
include/linux/io_uring_types.h-766- * poll
--
include/uapi/linux/blkdev.h-8-/*
include/uapi/linux/blkdev.h:9: * io_uring block file commands, see IORING_OP_URING_CMD.
include/uapi/linux/blkdev.h-10- * It's a different number space from ioctl(), reuse the block's code 0x12.
--
include/uapi/linux/bsg.h=69=struct bsg_uring_cmd {
--
include/uapi/linux/bsg.h-90-#ifdef __KERNEL__
include/uapi/linux/bsg.h:91:/* Must match IORING_OP_URING_CMD payload size (e.g. SQE128). */
include/uapi/linux/bsg.h-92-static_assert(sizeof(struct bsg_uring_cmd) == 80);
--
include/uapi/linux/bsg.h-99- * When using BSG_PROTOCOL_SCSI + BSG_SUB_PROTOCOL_SCSI_CMD with
include/uapi/linux/bsg.h:100: * IORING_OP_URING_CMD, the completion queue entry (CQE) contains:
include/uapi/linux/bsg.h-101- * - result: errno (0 on success)
--
include/uapi/linux/io_uring.h=255=enum io_uring_op {
include/uapi/linux/io_uring.h:256: IORING_OP_NOP,
include/uapi/linux/io_uring.h:257: IORING_OP_READV,
include/uapi/linux/io_uring.h:258: IORING_OP_WRITEV,
include/uapi/linux/io_uring.h:259: IORING_OP_FSYNC,
include/uapi/linux/io_uring.h:260: IORING_OP_READ_FIXED,
include/uapi/linux/io_uring.h:261: IORING_OP_WRITE_FIXED,
include/uapi/linux/io_uring.h:262: IORING_OP_POLL_ADD,
include/uapi/linux/io_uring.h:263: IORING_OP_POLL_REMOVE,
include/uapi/linux/io_uring.h:264: IORING_OP_SYNC_FILE_RANGE,
include/uapi/linux/io_uring.h:265: IORING_OP_SENDMSG,
include/uapi/linux/io_uring.h:266: IORING_OP_RECVMSG,
include/uapi/linux/io_uring.h:267: IORING_OP_TIMEOUT,
include/uapi/linux/io_uring.h:268: IORING_OP_TIMEOUT_REMOVE,
include/uapi/linux/io_uring.h:269: IORING_OP_ACCEPT,
include/uapi/linux/io_uring.h:270: IORING_OP_ASYNC_CANCEL,
include/uapi/linux/io_uring.h:271: IORING_OP_LINK_TIMEOUT,
include/uapi/linux/io_uring.h:272: IORING_OP_CONNECT,
include/uapi/linux/io_uring.h:273: IORING_OP_FALLOCATE,
include/uapi/linux/io_uring.h:274: IORING_OP_OPENAT,
include/uapi/linux/io_uring.h:275: IORING_OP_CLOSE,
include/uapi/linux/io_uring.h:276: IORING_OP_FILES_UPDATE,
include/uapi/linux/io_uring.h:277: IORING_OP_STATX,
include/uapi/linux/io_uring.h:278: IORING_OP_READ,
include/uapi/linux/io_uring.h:279: IORING_OP_WRITE,
include/uapi/linux/io_uring.h:280: IORING_OP_FADVISE,
include/uapi/linux/io_uring.h:281: IORING_OP_MADVISE,
include/uapi/linux/io_uring.h:282: IORING_OP_SEND,
include/uapi/linux/io_uring.h:283: IORING_OP_RECV,
include/uapi/linux/io_uring.h:284: IORING_OP_OPENAT2,
include/uapi/linux/io_uring.h:285: IORING_OP_EPOLL_CTL,
include/uapi/linux/io_uring.h:286: IORING_OP_SPLICE,
include/uapi/linux/io_uring.h:287: IORING_OP_PROVIDE_BUFFERS,
include/uapi/linux/io_uring.h:288: IORING_OP_REMOVE_BUFFERS,
include/uapi/linux/io_uring.h:289: IORING_OP_TEE,
include/uapi/linux/io_uring.h:290: IORING_OP_SHUTDOWN,
include/uapi/linux/io_uring.h:291: IORING_OP_RENAMEAT,
include/uapi/linux/io_uring.h:292: IORING_OP_UNLINKAT,
include/uapi/linux/io_uring.h:293: IORING_OP_MKDIRAT,
include/uapi/linux/io_uring.h:294: IORING_OP_SYMLINKAT,
include/uapi/linux/io_uring.h:295: IORING_OP_LINKAT,
include/uapi/linux/io_uring.h:296: IORING_OP_MSG_RING,
include/uapi/linux/io_uring.h:297: IORING_OP_FSETXATTR,
include/uapi/linux/io_uring.h:298: IORING_OP_SETXATTR,
include/uapi/linux/io_uring.h:299: IORING_OP_FGETXATTR,
include/uapi/linux/io_uring.h:300: IORING_OP_GETXATTR,
include/uapi/linux/io_uring.h:301: IORING_OP_SOCKET,
include/uapi/linux/io_uring.h:302: IORING_OP_URING_CMD,
include/uapi/linux/io_uring.h:303: IORING_OP_SEND_ZC,
include/uapi/linux/io_uring.h:304: IORING_OP_SENDMSG_ZC,
include/uapi/linux/io_uring.h:305: IORING_OP_READ_MULTISHOT,
include/uapi/linux/io_uring.h:306: IORING_OP_WAITID,
include/uapi/linux/io_uring.h:307: IORING_OP_FUTEX_WAIT,
include/uapi/linux/io_uring.h:308: IORING_OP_FUTEX_WAKE,
include/uapi/linux/io_uring.h:309: IORING_OP_FUTEX_WAITV,
include/uapi/linux/io_uring.h:310: IORING_OP_FIXED_FD_INSTALL,
include/uapi/linux/io_uring.h:311: IORING_OP_FTRUNCATE,
include/uapi/linux/io_uring.h:312: IORING_OP_BIND,
include/uapi/linux/io_uring.h:313: IORING_OP_LISTEN,
include/uapi/linux/io_uring.h:314: IORING_OP_RECV_ZC,
include/uapi/linux/io_uring.h:315: IORING_OP_EPOLL_WAIT,
include/uapi/linux/io_uring.h:316: IORING_OP_READV_FIXED,
include/uapi/linux/io_uring.h:317: IORING_OP_WRITEV_FIXED,
include/uapi/linux/io_uring.h:318: IORING_OP_PIPE,
include/uapi/linux/io_uring.h:319: IORING_OP_NOP128,
include/uapi/linux/io_uring.h:320: IORING_OP_URING_CMD128,
include/uapi/linux/io_uring.h-321-
include/uapi/linux/io_uring.h-322- /* this goes last, obviously */
include/uapi/linux/io_uring.h:323: IORING_OP_LAST,
include/uapi/linux/io_uring.h-324-};
--
include/uapi/linux/io_uring.h-460-/*
include/uapi/linux/io_uring.h:461: * IORING_OP_MSG_RING command types, stored in sqe->addr
include/uapi/linux/io_uring.h-462- */
include/uapi/linux/io_uring.h=463=enum io_uring_msg_ring_flags {
--
include/uapi/linux/io_uring.h-468-/*
include/uapi/linux/io_uring.h:469: * IORING_OP_MSG_RING flags (sqe->msg_ring_flags)
include/uapi/linux/io_uring.h-470- *
--
include/uapi/linux/io_uring.h-478-/*
include/uapi/linux/io_uring.h:479: * IORING_OP_FIXED_FD_INSTALL flags (sqe->install_fd_flags)
include/uapi/linux/io_uring.h-480- *
--
include/uapi/linux/io_uring.h-485-/*
include/uapi/linux/io_uring.h:486: * IORING_OP_NOP flags (sqe->nop_flags)
include/uapi/linux/io_uring.h-487- *
--
include/uapi/linux/io_uring.h=1027=struct io_uring_recvmsg_out {
--
include/uapi/linux/io_uring.h-1034-/*
include/uapi/linux/io_uring.h:1035: * Argument for IORING_OP_URING_CMD when file is a socket
include/uapi/linux/io_uring.h-1036- */
--
include/uapi/linux/io_uring/query.h=31=struct io_uring_query_opcode {
include/uapi/linux/io_uring/query.h:32: /* The number of supported IORING_OP_* opcodes */
include/uapi/linux/io_uring/query.h-33- __u32 nr_request_opcodes;
--
include/uapi/linux/ublk_cmd.h=90=struct ublk_shmem_buf_reg {
--
include/uapi/linux/ublk_cmd.h-217- * SQEs can now be submitted to the io_uring to read/write the request's buffer
include/uapi/linux/ublk_cmd.h:218: * by enabling fixed buffers (e.g. using IORING_OP_{READ,WRITE}_FIXED or
include/uapi/linux/ublk_cmd.h-219- * IORING_URING_CMD_FIXED) and passing the registered buffer index in buf_index.
--
io_uring/bpf_filter.c=97=static void io_free_bpf_filters(struct rcu_head *head)
--
io_uring/bpf_filter.c-109-
io_uring/bpf_filter.c:110: for (i = 0; i < IORING_OP_LAST; i++) {
io_uring/bpf_filter.c-111- struct io_bpf_filter *f;
--
io_uring/bpf_filter.c=151=static struct io_bpf_filters *io_new_bpf_filters(void)
--
io_uring/bpf_filter.c-158-
io_uring/bpf_filter.c:159: filters->filters = kzalloc_objs(struct io_bpf_filter *, IORING_OP_LAST,
io_uring/bpf_filter.c-160- GFP_KERNEL_ACCOUNT);
--
io_uring/bpf_filter.c=266=static struct io_bpf_filters *io_bpf_filter_cow(struct io_restriction *src)
--
io_uring/bpf_filter.c-283- rcu_read_lock();
io_uring/bpf_filter.c:284: for (i = 0; i < IORING_OP_LAST; i++) {
io_uring/bpf_filter.c-285- srcf = rcu_dereference(src->bpf_filters->filters[i]);
--
io_uring/bpf_filter.c=313=static int io_bpf_filter_import(struct io_uring_bpf *reg,
--
io_uring/bpf_filter.c-325-
io_uring/bpf_filter.c:326: if (reg->filter.opcode >= IORING_OP_LAST)
io_uring/bpf_filter.c-327- return -EINVAL;
--
io_uring/bpf_filter.c-337- /* Verify filter size */
io_uring/bpf_filter.c:338: def = &io_issue_defs[array_index_nospec(reg->filter.opcode, IORING_OP_LAST)];
io_uring/bpf_filter.c-339-
--
io_uring/bpf_filter.c=359=int io_register_bpf_filter(struct io_restriction *res,
--
io_uring/bpf_filter.c-437- if (reg.filter.flags & IO_URING_BPF_FILTER_DENY_REST) {
io_uring/bpf_filter.c:438: for (int i = 0; i < IORING_OP_LAST; i++) {
io_uring/bpf_filter.c-439- if (i == reg.filter.opcode)
--
io_uring/cancel.c=140=int io_async_cancel_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
--
io_uring/cancel.c-164- op = READ_ONCE(sqe->len);
io_uring/cancel.c:165: if (op >= IORING_OP_LAST)
io_uring/cancel.c-166- return -EINVAL;
--
io_uring/fdinfo.c=60=static void __io_uring_show_fdinfo(struct io_ring_ctx *ctx, struct seq_file *m)
--
io_uring/fdinfo.c-109- opcode = READ_ONCE(sqe->opcode);
io_uring/fdinfo.c:110: if (opcode >= IORING_OP_LAST)
io_uring/fdinfo.c-111- continue;
io_uring/fdinfo.c:112: opcode = array_index_nospec(opcode, IORING_OP_LAST);
io_uring/fdinfo.c-113- if (sq_shift) {
--
io_uring/futex.c=92=static bool __io_futex_cancel(struct io_kiocb *req)
--
io_uring/futex.c-94- /* futex wake already done or in progress */
io_uring/futex.c:95: if (req->opcode == IORING_OP_FUTEX_WAIT) {
io_uring/futex.c-96- struct io_futex_data *ifd = req->async_data;
--
io_uring/io_uring.c=1734=static int io_init_req(struct io_ring_ctx *ctx, struct io_kiocb *req,
--
io_uring/io_uring.c-1752-
io_uring/io_uring.c:1753: if (unlikely(req->opcode >= IORING_OP_LAST)) {
io_uring/io_uring.c-1754- req->opcode = 0;
--
io_uring/io_uring.c-1756- }
io_uring/io_uring.c:1757: req->opcode = array_index_nospec(req->opcode, IORING_OP_LAST);
io_uring/io_uring.c-1758-
--
io_uring/io_uring.h=560=static inline bool io_is_uring_cmd(const struct io_kiocb *req)
io_uring/io_uring.h-561-{
io_uring/io_uring.h:562: return req->opcode == IORING_OP_URING_CMD ||
io_uring/io_uring.h:563: req->opcode == IORING_OP_URING_CMD128;
io_uring/io_uring.h-564-}
--
io_uring/kbuf.c=570=static int __io_manage_buffers_legacy(struct io_kiocb *req,
--
io_uring/kbuf.c-576- if (!bl) {
io_uring/kbuf.c:577: if (req->opcode != IORING_OP_PROVIDE_BUFFERS)
io_uring/kbuf.c-578- return -ENOENT;
--
io_uring/kbuf.c-592- return -EINVAL;
io_uring/kbuf.c:593: if (req->opcode == IORING_OP_PROVIDE_BUFFERS)
io_uring/kbuf.c-594- return io_add_buffers(req->ctx, p, bl);
--
io_uring/msg_ring.c=83=static void io_msg_remote_post(struct io_ring_ctx *ctx, struct io_kiocb *req,
--
io_uring/msg_ring.c-85-{
io_uring/msg_ring.c:86: req->opcode = IORING_OP_NOP;
io_uring/msg_ring.c-87- req->cqe.user_data = user_data;
--
io_uring/msg_ring.c=176=static int io_msg_install_complete(struct io_kiocb *req, unsigned int issue_flags)
--
io_uring/msg_ring.c-198- * completes with -EOVERFLOW, then the sender must ensure that a
io_uring/msg_ring.c:199: * later IORING_OP_MSG_RING delivers the message.
io_uring/msg_ring.c-200- */
--
io_uring/net.c=423=int io_sendmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
--
io_uring/net.c-439- if (sr->flags & IORING_RECVSEND_BUNDLE) {
io_uring/net.c:440: if (req->opcode == IORING_OP_SENDMSG)
io_uring/net.c-441- return -EINVAL;
--
io_uring/net.c-450- return -ENOMEM;
io_uring/net.c:451: if (req->opcode != IORING_OP_SENDMSG)
io_uring/net.c-452- return io_send_setup(req, sqe);
--
io_uring/net.c=759=static int io_recvmsg_prep_setup(struct io_kiocb *req)
--
io_uring/net.c-767-
io_uring/net.c:768: if (req->opcode == IORING_OP_RECV) {
io_uring/net.c-769- kmsg->msg.msg_name = NULL;
--
io_uring/net.c=790=int io_recvmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
--
io_uring/net.c-818- return -EINVAL;
io_uring/net.c:819: if (req->opcode == IORING_OP_RECV) {
io_uring/net.c-820- sr->mshot_len = sr->len;
--
io_uring/net.c-832- if (sr->flags & IORING_RECVSEND_BUNDLE) {
io_uring/net.c:833: if (req->opcode == IORING_OP_RECVMSG)
io_uring/net.c-834- return -EINVAL;
--
io_uring/net.c=1336=int io_send_zc_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
--
io_uring/net.c-1390-
io_uring/net.c:1391: if (req->opcode == IORING_OP_SEND_ZC) {
io_uring/net.c-1392- ret = io_send_setup(req, sqe);
--
io_uring/net.c=1489=int io_sendmsg_zc(struct io_kiocb *req, unsigned int issue_flags)
--
io_uring/net.c-1519-
io_uring/net.c:1520: if (req->opcode == IORING_OP_SEND_ZC) {
io_uring/net.c-1521- msg_flags &= ~MSG_INTERNAL_SENDMSG_FLAGS;
--
io_uring/net.c=1560=void io_sendrecv_fail(struct io_kiocb *req)
--
io_uring/net.c-1567- if ((req->flags & REQ_F_NEED_CLEANUP) &&
io_uring/net.c:1568: (req->opcode == IORING_OP_SEND_ZC || req->opcode == IORING_OP_SENDMSG_ZC))
io_uring/net.c-1569- req->cqe.flags |= IORING_CQE_F_MORE;
--
io_uring/notif.c=114=struct io_kiocb *io_alloc_notif(struct io_ring_ctx *ctx)
--
io_uring/notif.c-122- notif->ctx = ctx;
io_uring/notif.c:123: notif->opcode = IORING_OP_NOP;
io_uring/notif.c-124- notif->flags = 0;
--
io_uring/opdef.c=54=const struct io_issue_def io_issue_defs[] = {
io_uring/opdef.c:55: [IORING_OP_NOP] = {
io_uring/opdef.c-56- .audit_skip = 1,
--
io_uring/opdef.c-60- },
io_uring/opdef.c:61: [IORING_OP_READV] = {
io_uring/opdef.c-62- .needs_file = 1,
--
io_uring/opdef.c-74- },
io_uring/opdef.c:75: [IORING_OP_WRITEV] = {
io_uring/opdef.c-76- .needs_file = 1,
--
io_uring/opdef.c-88- },
io_uring/opdef.c:89: [IORING_OP_FSYNC] = {
io_uring/opdef.c-90- .needs_file = 1,
--
io_uring/opdef.c-94- },
io_uring/opdef.c:95: [IORING_OP_READ_FIXED] = {
io_uring/opdef.c-96- .needs_file = 1,
--
io_uring/opdef.c-106- },
io_uring/opdef.c:107: [IORING_OP_WRITE_FIXED] = {
io_uring/opdef.c-108- .needs_file = 1,
--
io_uring/opdef.c-119- },
io_uring/opdef.c:120: [IORING_OP_POLL_ADD] = {
io_uring/opdef.c-121- .needs_file = 1,
--
io_uring/opdef.c-126- },
io_uring/opdef.c:127: [IORING_OP_POLL_REMOVE] = {
io_uring/opdef.c-128- .audit_skip = 1,
--
io_uring/opdef.c-131- },
io_uring/opdef.c:132: [IORING_OP_SYNC_FILE_RANGE] = {
io_uring/opdef.c-133- .needs_file = 1,
--
io_uring/opdef.c-137- },
io_uring/opdef.c:138: [IORING_OP_SENDMSG] = {
io_uring/opdef.c-139- .needs_file = 1,
--
io_uring/opdef.c-150- },
io_uring/opdef.c:151: [IORING_OP_RECVMSG] = {
io_uring/opdef.c-152- .needs_file = 1,
--
io_uring/opdef.c-164- },
io_uring/opdef.c:165: [IORING_OP_TIMEOUT] = {
io_uring/opdef.c-166- .audit_skip = 1,
--
io_uring/opdef.c-170- },
io_uring/opdef.c:171: [IORING_OP_TIMEOUT_REMOVE] = {
io_uring/opdef.c-172- /* used by timeout updates' prep() */
--
io_uring/opdef.c-176- },
io_uring/opdef.c:177: [IORING_OP_ACCEPT] = {
io_uring/opdef.c-178- .needs_file = 1,
--
io_uring/opdef.c-189- },
io_uring/opdef.c:190: [IORING_OP_ASYNC_CANCEL] = {
io_uring/opdef.c-191- .audit_skip = 1,
--
io_uring/opdef.c-194- },
io_uring/opdef.c:195: [IORING_OP_LINK_TIMEOUT] = {
io_uring/opdef.c-196- .audit_skip = 1,
--
io_uring/opdef.c-200- },
io_uring/opdef.c:201: [IORING_OP_CONNECT] = {
io_uring/opdef.c-202- .needs_file = 1,
--
io_uring/opdef.c-212- },
io_uring/opdef.c:213: [IORING_OP_FALLOCATE] = {
io_uring/opdef.c-214- .needs_file = 1,
--
io_uring/opdef.c-218- },
io_uring/opdef.c:219: [IORING_OP_OPENAT] = {
io_uring/opdef.c-220- .filter_pdu_size = sizeof_field(struct io_uring_bpf_ctx, open),
--
io_uring/opdef.c-224- },
io_uring/opdef.c:225: [IORING_OP_CLOSE] = {
io_uring/opdef.c-226- .prep = io_close_prep,
--
io_uring/opdef.c-228- },
io_uring/opdef.c:229: [IORING_OP_FILES_UPDATE] = {
io_uring/opdef.c-230- .audit_skip = 1,
--
io_uring/opdef.c-234- },
io_uring/opdef.c:235: [IORING_OP_STATX] = {
io_uring/opdef.c-236- .audit_skip = 1,
--
io_uring/opdef.c-239- },
io_uring/opdef.c:240: [IORING_OP_READ] = {
io_uring/opdef.c-241- .needs_file = 1,
--
io_uring/opdef.c-252- },
io_uring/opdef.c:253: [IORING_OP_WRITE] = {
io_uring/opdef.c-254- .needs_file = 1,
--
io_uring/opdef.c-265- },
io_uring/opdef.c:266: [IORING_OP_FADVISE] = {
io_uring/opdef.c-267- .needs_file = 1,
--
io_uring/opdef.c-271- },
io_uring/opdef.c:272: [IORING_OP_MADVISE] = {
io_uring/opdef.c-273- .audit_skip = 1,
--
io_uring/opdef.c-276- },
io_uring/opdef.c:277: [IORING_OP_SEND] = {
io_uring/opdef.c-278- .needs_file = 1,
--
io_uring/opdef.c-291- },
io_uring/opdef.c:292: [IORING_OP_RECV] = {
io_uring/opdef.c-293- .needs_file = 1,
--
io_uring/opdef.c-306- },
io_uring/opdef.c:307: [IORING_OP_OPENAT2] = {
io_uring/opdef.c-308- .filter_pdu_size = sizeof_field(struct io_uring_bpf_ctx, open),
--
io_uring/opdef.c-312- },
io_uring/opdef.c:313: [IORING_OP_EPOLL_CTL] = {
io_uring/opdef.c-314- .unbound_nonreg_file = 1,
--
io_uring/opdef.c-322- },
io_uring/opdef.c:323: [IORING_OP_SPLICE] = {
io_uring/opdef.c-324- .needs_file = 1,
--
io_uring/opdef.c-330- },
io_uring/opdef.c:331: [IORING_OP_PROVIDE_BUFFERS] = {
io_uring/opdef.c-332- .audit_skip = 1,
--
io_uring/opdef.c-336- },
io_uring/opdef.c:337: [IORING_OP_REMOVE_BUFFERS] = {
io_uring/opdef.c-338- .audit_skip = 1,
--
io_uring/opdef.c-342- },
io_uring/opdef.c:343: [IORING_OP_TEE] = {
io_uring/opdef.c-344- .needs_file = 1,
--
io_uring/opdef.c-350- },
io_uring/opdef.c:351: [IORING_OP_SHUTDOWN] = {
io_uring/opdef.c-352- .needs_file = 1,
--
io_uring/opdef.c-359- },
io_uring/opdef.c:360: [IORING_OP_RENAMEAT] = {
io_uring/opdef.c-361- .prep = io_renameat_prep,
--
io_uring/opdef.c-363- },
io_uring/opdef.c:364: [IORING_OP_UNLINKAT] = {
io_uring/opdef.c-365- .prep = io_unlinkat_prep,
--
io_uring/opdef.c-367- },
io_uring/opdef.c:368: [IORING_OP_MKDIRAT] = {
io_uring/opdef.c-369- .prep = io_mkdirat_prep,
--
io_uring/opdef.c-371- },
io_uring/opdef.c:372: [IORING_OP_SYMLINKAT] = {
io_uring/opdef.c-373- .prep = io_symlinkat_prep,
--
io_uring/opdef.c-375- },
io_uring/opdef.c:376: [IORING_OP_LINKAT] = {
io_uring/opdef.c-377- .prep = io_linkat_prep,
--
io_uring/opdef.c-379- },
io_uring/opdef.c:380: [IORING_OP_MSG_RING] = {
io_uring/opdef.c-381- .needs_file = 1,
--
io_uring/opdef.c-385- },
io_uring/opdef.c:386: [IORING_OP_FSETXATTR] = {
io_uring/opdef.c-387- .needs_file = 1,
--
io_uring/opdef.c-390- },
io_uring/opdef.c:391: [IORING_OP_SETXATTR] = {
io_uring/opdef.c-392- .prep = io_setxattr_prep,
--
io_uring/opdef.c-394- },
io_uring/opdef.c:395: [IORING_OP_FGETXATTR] = {
io_uring/opdef.c-396- .needs_file = 1,
--
io_uring/opdef.c-399- },
io_uring/opdef.c:400: [IORING_OP_GETXATTR] = {
io_uring/opdef.c-401- .prep = io_getxattr_prep,
--
io_uring/opdef.c-403- },
io_uring/opdef.c:404: [IORING_OP_SOCKET] = {
io_uring/opdef.c-405- .audit_skip = 1,
--
io_uring/opdef.c-414- },
io_uring/opdef.c:415: [IORING_OP_URING_CMD] = {
io_uring/opdef.c-416- .buffer_select = 1,
--
io_uring/opdef.c-423- },
io_uring/opdef.c:424: [IORING_OP_SEND_ZC] = {
io_uring/opdef.c-425- .needs_file = 1,
]
|
| 82/2 |
2026/06/12 22:27 |
llm |
expert |
0m
Model:
Tokens:
input: 147144
output: 49
thoughts: 2276
Thoughts: **Analyzing a Potential Kernel File Descriptor Leak**
Okay, so I'm diving into this issue. First, I'm checking the `io_uring` opcode table to make sure I'm interpreting things correctly. `IORING_OP_SEND_ZC` (47) uses a file descriptor (`fd`). I'm looking at the provided data and confirm the `fd` value (1768060463) isn't valid. This will result in an `-EBADF` error. However, a series of NOPs follow, which will succeed. There are 4611 SQEs.
Initially, I thought `/dev/vbi3` could be leaked via `io_uring`, but the SQEs don't directly reference it. The backtrace shows `alloc_empty_file` and `path_openat`. This suggests the leak comes from the initial `syz_open_dev` call, where `/dev/vbi3` is opened. The `sendmsg` call is concerning because it's using `-1` as the `fd` in the C reproducer. Syzkaller might have a different file descriptor here, potentially `sock_nl_route` resource. The comment in the syzkaller program mentions `sock_nl_route` for the `fd`. If that socket *was* created, the `sendmsg` might succeed!
I reviewed the TC filter configuration done by `sendmsg`. Actions like `pedit`, `police`, `ct`, and `gact` don't seem to hold a file reference. But the backtrace *only* points to `path_openat`, not `sock_alloc_file`. This means the leaked file is from `syz_open_dev`, and the reproducer suggests the file is `/dev/vbi3`.
Now, I need to focus on why `/dev/vbi3` might be leaked, focusing on the `vivid` driver's `open` and `release` functions, specifically, `v4l2_open` and `v4l2_release` and how they manage `video_get` and the file operation structure (`fops`). Is there a potential reference count problem?
|
| 83/2 |
2026/06/12 22:27 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/media/v4l2-core/v4l2-dev.c Name:v4l2_release]
Results: map[SourceCode: 454: /* Override for the release function */
455: static int v4l2_release(struct inode *inode, struct file *filp)
456: {
457: struct video_device *vdev = video_devdata(filp);
458: int ret;
459:
460: /*
461: * We need to serialize the release() with queueing new requests.
462: * The release() may trigger the cancellation of a streaming
463: * operation, and that should not be mixed with queueing a new
464: * request at the same time.
465: */
466: if (v4l2_device_supports_requests(vdev->v4l2_dev)) {
467: mutex_lock(&vdev->v4l2_dev->mdev->req_queue_mutex);
468: ret = vdev->fops->release(filp);
469: mutex_unlock(&vdev->v4l2_dev->mdev->req_queue_mutex);
470: } else {
471: ret = vdev->fops->release(filp);
472: }
473:
474: if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
475: dprintk("%s: release\n",
476: video_device_node_name(vdev));
477:
478: /* decrease the refcount unconditionally since the release()
479: return value is ignored. */
480: video_put(vdev);
481: return ret;
482: }
SourceFile:drivers/media/v4l2-core/v4l2-dev.c]
|
| 84/2 |
2026/06/12 22:27 |
llm |
expert |
0m
Model:
Tokens:
input: 150459
output: 34
thoughts: 3760
Thoughts: **Analyzing the Kernel Bug: An io_uring and File Descriptor Conundrum**
Okay, so `v4l2_release` is just a thin wrapper that calls the file operation release function. It doesn't actually touch the reference count, which is crucial. If a file is leaked, it means the `fput` didn't decrement the count to zero. This, in turn, suggests `v4l2_release` wasn't called. The question is, why? There's got to be something holding a reference to the `/dev/vbi3` file.
Let's dissect the reproducer step by step. I see the usual suspects: `mmap`, `prctl`, and `sendmsg`. The interesting part is the `io_uring` calls. `io_uring_enter` processes those submission queue entries (SQEs), and those SQEs are mapped at address `0x200000000000`. `syz_open_dev` returns a file descriptor, let's say 3. I'm focusing on whether any of the SQEs use fd 3.
I'm systematically going through the SQEs, examining the `opcode` and `fd` fields. Most of them are NOPs (no-ops) or use different file descriptors. Wait, there's a large section of zeroed memory, which means those SQEs will effectively be NOPs, so that's nothing important. The `sendmsg` payload has a lot of data, so I have to carefully parse that as well.
I start to see some interesting SQEs towards the end. There's a `IORING_OP_SPLICE`, a `IORING_OP_FADVISE` - but nothing that obviously leaks a file. I keep looking.
I'm thinking, could a `IORING_OP_POLL_ADD` with `fd = 3` be the culprit? If it poll adds `/dev/vbi3` with an `io_uring` context it could hold a reference. I check the `sendmsg` payload where the SQEs are constructed, but I don't see anything explicitly setting `fd` to 3 at first. I start looking at the individual SQEs, and I find a lot of them. I'm carefully going through each SQE and their `fd` entries.
Finally, bingo! At offset `0x6580` in the payload, I find an SQE with an `fd` of `3`! The `opcode` is `IORING_OP_WRITEV` and the `fd` is `/dev/vbi3` which means that the `io_uring` context is now holding a reference. This is a potential leak. Let's see how `io_uring` interacts with `IORING_OP_WRITEV`! I need to consult the `io_write` function in `io_uring/rw.c` to confirm my findings and understand if this is a real problem.
|
| 85/2 |
2026/06/12 22:27 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/rw.c Name:io_write]
Results: map[SourceCode:1126: int io_write(struct io_kiocb *req, unsigned int issue_flags)
1127: {
1128: bool force_nonblock = issue_flags & IO_URING_F_NONBLOCK;
1129: struct io_rw *rw = io_kiocb_to_cmd(req, struct io_rw);
1130: struct io_async_rw *io = req->async_data;
1131: struct kiocb *kiocb = &rw->kiocb;
1132: ssize_t ret, ret2;
1133: loff_t *ppos;
1134:
1135: if (req->flags & REQ_F_IMPORT_BUFFER) {
1136: ret = io_rw_import_reg_vec(req, io, ITER_SOURCE, issue_flags);
1137: if (unlikely(ret))
1138: return ret;
1139: }
1140:
1141: ret = io_rw_init_file(req, FMODE_WRITE, WRITE);
1142: if (unlikely(ret))
1143: return ret;
1144: req->cqe.res = iov_iter_count(&io->iter);
1145:
1146: if (force_nonblock) {
1147: /* If the file doesn't support async, just async punt */
1148: if (unlikely(!io_file_supports_nowait(req, EPOLLOUT)))
1149: goto ret_eagain;
1150:
1151: /* Check if we can support NOWAIT. */
1152: if (!(kiocb->ki_flags & IOCB_DIRECT) &&
1153: !(req->file->f_op->fop_flags & FOP_BUFFER_WASYNC) &&
1154: (req->flags & REQ_F_ISREG))
1155: goto ret_eagain;
1156:
1157: kiocb->ki_flags |= IOCB_NOWAIT;
1158: } else {
1159: /* Ensure we clear previously set non-block flag */
1160: kiocb->ki_flags &= ~IOCB_NOWAIT;
1161: }
1162:
1163: ppos = io_kiocb_update_pos(req);
1164:
1165: ret = rw_verify_area(WRITE, req->file, ppos, req->cqe.res);
1166: if (unlikely(ret))
1167: return ret;
1168:
1169: if (unlikely(!io_kiocb_start_write(req, kiocb)))
1170: return -EAGAIN;
1171: kiocb->ki_flags |= IOCB_WRITE;
1172:
1173: if (likely(req->file->f_op->write_iter))
1174: ret2 = req->file->f_op->write_iter(kiocb, &io->iter);
1175: else if (req->file->f_op->write)
1176: ret2 = loop_rw_iter(WRITE, rw, &io->iter);
1177: else
1178: ret2 = -EINVAL;
1179:
1180: /*
1181: * Raw bdev writes will return -EOPNOTSUPP for IOCB_NOWAIT. Just
1182: * retry them without IOCB_NOWAIT.
1183: */
1184: if (ret2 == -EOPNOTSUPP && (kiocb->ki_flags & IOCB_NOWAIT))
1185: ret2 = -EAGAIN;
1186: /* no retry on NONBLOCK nor RWF_NOWAIT */
1187: if (ret2 == -EAGAIN && (req->flags & REQ_F_NOWAIT))
1188: goto done;
1189: if (!force_nonblock || ret2 != -EAGAIN) {
1190: /* IOPOLL retry should happen for io-wq threads */
1191: if (ret2 == -EAGAIN && (req->flags & REQ_F_IOPOLL))
1192: goto ret_eagain;
1193:
1194: if (ret2 != req->cqe.res && ret2 >= 0 && need_complete_io(req)) {
1195: trace_io_uring_short_write(req->ctx, kiocb->ki_pos - ret2,
1196: req->cqe.res, ret2);
1197:
1198: /* This is a partial write. The file pos has already been
1199: * updated, setup the async struct to complete the request
1200: * in the worker. Also update bytes_done to account for
1201: * the bytes already written.
1202: */
1203: iov_iter_save_state(&io->iter, &io->iter_state);
1204: io->bytes_done += ret2;
1205:
1206: if (kiocb->ki_flags & IOCB_WRITE)
1207: io_req_end_write(req);
1208: return -EAGAIN;
1209: }
1210: done:
1211: return kiocb_done(req, ret2, NULL, issue_flags);
1212: } else {
1213: ret_eagain:
1214: iov_iter_restore(&io->iter, &io->iter_state);
1215: io_meta_restore(io, kiocb);
1216: if (kiocb->ki_flags & IOCB_WRITE)
1217: io_req_end_write(req);
1218: return -EAGAIN;
1219: }
1220: }
SourceFile:io_uring/rw.c]
|
| 86/2 |
2026/06/12 22:27 |
llm |
expert |
0m
Model:
Tokens:
input: 156572
output: 32
thoughts: 922
Thoughts: **Analyzing Potential File Descriptor Leaks in `io_uring`**
Okay, let's break this down. My initial thought was about file descriptor leaks, specifically focusing on how writes are handled within the `io_uring` framework. The call stack *should* be clean: `io_write` calls `io_req_end_write`, which in turn calls `kiocb_end_write`, which finally calls `file_end_write`. `file_end_write` then calls `__sb_end_write`, and it *seems* like this doesn't directly leak the file descriptor.
But, a nagging question immediately arises: could `io_uring` itself be the source of a leak at the request level? My reasoning follows a path that needs to consider every stage of a request's lifecycle. If an `io_uring` request is leaked, it retains a reference to the file via `req->file`. So, where could a request get "lost"? Submitting a request through `io_uring_enter` puts it on a queue, potentially `io_wq`, for asynchronous execution. When a process exits, a cleanup procedure is triggered using `io_uring_cancel_generic` – this is supposed to cancel all pending requests.
The key question is: what if `io_uring_cancel_generic` fails? Suppose a request is stuck in `io_wq`. Does this create a leak? Thankfully, `io_uring_cancel_generic` appears to wait for these requests to finish. Excellent, so requests stuck in `io_wq` are unlikely to be the root of a file descriptor leak in this context. But, what if the request isn't in `io_wq` but in `tctx->task_list`? That is also canceled by `io_uring_cancel_generic`, so that looks safe too!
Now, the lightbulb moment: I remember a known bug with `IORING_SETUP_REGISTERED_FD_ONLY` potentially leaking the ring file descriptor itself. Time to investigate `io_uring_unreg_ringfd`. That function iterates through registered rings and calls `fput` on each one, unregistering them. *This* looks promising.
Now, where is `io_uring_unreg_ringfd` called from? It's called by `__io_uring_cancel`, which is called by `io_uring_files_cancel` and `io_uring_task_cancel`. And the critical part here is when those are called. `io_uring_files_cancel` is triggered *before* `exit_files(tsk)` within `do_exit`. This is good, because it means we're unregistering the rings before the file descriptor table is cleaned up!
A closer look at `do_exit` shows that `io_uring_files_cancel()` is indeed called *before* `exit_files()`. This means that within `io_uring_files_cancel`, `__io_uring_cancel(false)` is invoked. This in turn calls `io_uring_unreg_ringfd()`, which should correctly `fput` any registered ring file descriptors. That's a huge piece of the puzzle and helps close a potential leak.
Another question: what if `io_uring_task_cancel` is called instead? Let me check `do_exit` again to make sure of the call order.
|
| 87/2 |
2026/06/12 22:28 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:kernel/exit.c Name:do_exit]
Results: map[SourceCode: 896: void __noreturn do_exit(long code)
897: {
898: struct task_struct *tsk = current;
899: struct kthread *kthread;
900: int group_dead;
901:
902: WARN_ON(irqs_disabled());
903: WARN_ON(tsk->plug);
904:
905: kthread = tsk_is_kthread(tsk);
906: if (unlikely(kthread))
907: kthread_do_exit(kthread, code);
908:
909: kcov_task_exit(tsk);
910: kmsan_task_exit(tsk);
911:
912: synchronize_group_exit(tsk, code);
913: ptrace_event(PTRACE_EVENT_EXIT, code);
914: user_events_exit(tsk);
915:
916: io_uring_files_cancel();
917: sched_mm_cid_exit(tsk);
918: exit_signals(tsk); /* sets PF_EXITING */
919:
920: seccomp_filter_release(tsk);
921:
922: acct_update_integrals(tsk);
923: group_dead = atomic_dec_and_test(&tsk->signal->live);
924: if (group_dead) {
925: /*
926: * If the last thread of global init has exited, panic
927: * immediately to get a useable coredump.
928: */
929: if (unlikely(is_global_init(tsk)))
930: panic("Attempted to kill init! exitcode=0x%08x\n",
931: tsk->signal->group_exit_code ?: (int)code);
932:
933: #ifdef CONFIG_POSIX_TIMERS
934: hrtimer_cancel(&tsk->signal->real_timer);
935: exit_itimers(tsk);
936: #endif
937: if (tsk->mm)
938: setmax_mm_hiwater_rss(&tsk->signal->maxrss, tsk->mm);
939: }
940: acct_collect(code, group_dead);
941: if (group_dead)
942: tty_audit_exit();
943: audit_free(tsk);
944:
945: tsk->exit_code = code;
946: taskstats_exit(tsk, group_dead);
947: trace_sched_process_exit(tsk, group_dead);
948:
949: /*
950: * Since sampling can touch ->mm, make sure to stop everything before we
951: * tear it down.
952: *
953: * Also flushes inherited counters to the parent - before the parent
954: * gets woken up by child-exit notifications.
955: */
956: perf_event_exit_task(tsk);
957: /*
958: * PF_EXITING (above) ensures unwind_deferred_request() will no
959: * longer add new unwinds. While exit_mm() (below) will destroy the
960: * abaility to do unwinds. So flush any pending unwinds here.
961: */
962: unwind_deferred_task_exit(tsk);
963:
964: exit_mm();
965:
966: if (group_dead)
967: acct_process();
968:
969: exit_sem(tsk);
970: exit_shm(tsk);
971: exit_files(tsk);
972: exit_fs(tsk);
973: if (group_dead)
974: disassociate_ctty(1);
975: exit_nsproxy_namespaces(tsk);
976: exit_task_work(tsk);
977: exit_thread(tsk);
978:
979: sched_autogroup_exit_task(tsk);
980: cgroup_task_exit(tsk);
981:
982: /*
983: * FIXME: do that only when needed, using sched_exit tracepoint
984: */
985: flush_ptrace_hw_breakpoint(tsk);
986:
987: exit_tasks_rcu_start();
988: exit_notify(tsk, group_dead);
989: proc_exit_connector(tsk);
990: mpol_put_task_policy(tsk);
991: #ifdef CONFIG_FUTEX
992: if (unlikely(current->pi_state_cache))
993: kfree(current->pi_state_cache);
994: #endif
995: /*
996: * Make sure we are holding no locks:
997: */
998: debug_check_no_locks_held();
999:
1000: if (tsk->io_context)
1001: exit_io_context(tsk);
1002:
1003: if (tsk->splice_pipe)
1004: free_pipe_info(tsk->splice_pipe);
1005:
1006: if (tsk->task_frag.page)
1007: put_page(tsk->task_frag.page);
1008:
1009: exit_task_stack_account(tsk);
1010:
1011: check_stack_usage();
1012: preempt_disable();
1013: if (tsk->nr_dirtied)
1014: __this_cpu_add(dirty_throttle_leaks, tsk->nr_dirtied);
1015: exit_rcu();
1016: exit_tasks_rcu_finish();
1017:
1018: lockdep_free_task(tsk);
1019: do_task_dead();
1020: }
SourceFile:kernel/exit.c]
|
| 88/2 |
2026/06/12 22:28 |
llm |
expert |
0m
Model:
Tokens:
input: 160041
output: 38
thoughts: 616
Thoughts: **My Analysis of the `io_uring` File Descriptor Leak**
Okay, let's break this down. Line 916 has `io_uring_files_cancel()`. Line 971 and 976 call `exit_files(tsk)` and `exit_task_work(tsk)`, respectively. `io_uring_files_cancel` seems to call `__io_uring_cancel(false)`, which in turn calls `io_uring_unreg_ringfd()`. This appears to `fput` `tctx->registered_rings[i]`. Hold on! That `fput` adds the file to `task_work`, delaying the actual `__fput` call to when `exit_task_work(tsk)` is invoked, on line 976. This seems to mean that the function call `__fput` is called at line 976.
So, `__fput` gets executed at 976, which will call `io_uring_release`. And `io_uring_release` then calls `io_ring_ctx_wait_and_kill(ctx)`. Wait, that function waits for *all* requests to finish! But hang on, `io_uring_files_cancel` *cancels* requests. But, if a request isn't cancelled...?
The reproducer uses `IORING_OP_WRITEV` on fd 3. FD 3 is `/dev/vbi3`. `IORING_OP_WRITEV` uses fd 3. Does it use the registered fd table or the normal? The SQE has `flags = 0`, so it uses the normal table! `io_issue_sqe` calls `io_req_set_file`, which gets the file descriptor from the normal FD table, calling `fget(3)`.
So, the request holds a reference to `/dev/vbi3`. Okay. When is the request freed? It's freed when it completes. What if the request NEVER completes? If it doesn't complete, we leak the request, and the request leaks the file!
Why would a `IORING_OP_WRITEV` on `/dev/vbi3` never complete? Because `/dev/vbi3` is a V4L2 device. Writing to a V4L2 device could block *forever*. If it blocks forever, shouldn't `io_uring_cancel_generic` cancel it? Time to look at `io_uring_cancel_generic`... this looks like a possible leak!
|
| 89/2 |
2026/06/12 22:28 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/cancel.c Name:io_uring_cancel_generic]
Results: map[SourceCode: 580: /*
581: * Find any io_uring ctx that this task has registered or done IO on, and cancel
582: * requests. @sqd should be not-null IFF it's an SQPOLL thread cancellation.
583: */
584: __cold void io_uring_cancel_generic(bool cancel_all, struct io_sq_data *sqd)
585: {
586: struct io_uring_task *tctx = current->io_uring;
587: struct io_ring_ctx *ctx;
588: struct io_tctx_node *node;
589: unsigned long index;
590: s64 inflight;
591: DEFINE_WAIT(wait);
592:
593: WARN_ON_ONCE(sqd && sqpoll_task_locked(sqd) != current);
594:
595: if (!current->io_uring)
596: return;
597: if (tctx->io_wq)
598: io_wq_exit_start(tctx->io_wq);
599:
600: atomic_inc(&tctx->in_cancel);
601: do {
602: bool loop = false;
603:
604: io_uring_drop_tctx_refs(current);
605: if (!tctx_inflight(tctx, !cancel_all))
606: break;
607:
608: /* read completions before cancelations */
609: inflight = tctx_inflight(tctx, false);
610: if (!inflight)
611: break;
612:
613: if (!sqd) {
614: xa_for_each(&tctx->xa, index, node) {
615: /* sqpoll task will cancel all its requests */
616: if (node->ctx->sq_data)
617: continue;
618: loop |= io_uring_try_cancel_requests(node->ctx,
619: current->io_uring,
620: cancel_all,
621: false);
622: }
623: } else {
624: list_for_each_entry(ctx, &sqd->ctx_list, sqd_list)
625: loop |= io_uring_try_cancel_requests(ctx,
626: current->io_uring,
627: cancel_all,
628: true);
629: }
630:
631: if (loop) {
632: cond_resched();
633: continue;
634: }
635:
636: prepare_to_wait(&tctx->wait, &wait, TASK_INTERRUPTIBLE);
637: io_run_task_work();
638: io_uring_drop_tctx_refs(current);
639: xa_for_each(&tctx->xa, index, node) {
640: if (io_local_work_pending(node->ctx)) {
641: WARN_ON_ONCE(node->ctx->submitter_task &&
642: node->ctx->submitter_task != current);
643: goto end_wait;
644: }
645: }
646: /*
647: * If we've seen completions, retry without waiting. This
648: * avoids a race where a completion comes in before we did
649: * prepare_to_wait().
650: */
651: if (inflight == tctx_inflight(tctx, !cancel_all))
652: schedule();
653: end_wait:
654: finish_wait(&tctx->wait, &wait);
655: } while (1);
656:
657: io_uring_clean_tctx(tctx);
658: if (cancel_all) {
659: /*
660: * We shouldn't run task_works after cancel, so just leave
661: * ->in_cancel set for normal exit.
662: */
663: atomic_dec(&tctx->in_cancel);
664: /* for exec all current's requests should be gone, kill tctx */
665: __io_uring_free(current);
666: }
667: }
SourceFile:io_uring/cancel.c]
|
| 90/2 |
2026/06/12 22:28 |
llm |
expert |
0m
Model:
Tokens:
input: 162561
output: 38
thoughts: 5279
Thoughts: **Analyzing a Memory Leak in io_uring with a Focus on File Descriptor Management**
Okay, so I'm diving into this syzbot report about a memory leak, which is pointing at a problem with file descriptor (fd) management in `io_uring`. The report indicates that the process exits successfully, but memory isn't freed, which is definitely NOT a "hung task" or "RCU stall." That narrows it down to something that *completed* but still leaked.
The first clue leads me to `io_uring_cancel_generic`. I initially assumed it was getting stuck in an infinite loop, but the report doesn't support this. It *must* have finished, meaning `tctx_inflight` must have become zero. Therefore, all requests should have completed and freed their file references. If that's the case, then why am I still seeing a leak of `/dev/vbi3`? I have to consider the possibility that it's *not* `/dev/vbi3` that's leaking, but the `io_uring` file itself!
I begin to trace back the creation of the `io_uring` file, noting that it's created via `anon_inode_create_getfile`, which then goes through `alloc_file_pseudo` and `alloc_empty_file`. Then I check the backtrace in the report. This points to `path_openat`. However, since `anon_inode_create_getfile` doesn't directly call `path_openat`, I'm pretty sure now that the leaked file is `/dev/vbi3`.
To solidify this point, I see if there's any other `openat` call in the reproducer, and there is: `syz_open_dev`, which calls `open("/dev/vbi3", O_RDWR, 0)`. Thus, `/dev/vbi3` is the leaked file. So, the question remains: why?
I then check `sendmsg`. Since `sendmsg` with `fd = -1` shouldn't work, I need to know if it's called with a valid fd. Indeed, syzkaller shows that there's a valid fd: `sock_nl_route (resource)`. If it did get created, then `sendmsg` would succeed. The reproducer calls `sendmsg` to configure TC filters, which is unlikely to leak a file, so it's not the TC filter configuration itself. What if there's an fd in the `sendmsg` payload? I see several "3"s in the payload, but not fds for TC filters.
Next, I look into `io_uring` specifically. `io_uring_enter` is called with `fd = r[0]`, where `r[0]` is the registered fd (like 0) if `io_uring_setup` succeeds. So it will use the io_uring file itself. Then `io_uring_enter` checks whether `fd` is a io_uring fd, which is valid. Since the reproducer uses `IORING_ENTER_REGISTERED_RING`, then `io_uring_enter` *will* use `tctx->registered_rings[0]`, which *is* the `io_uring` file. The SQEs get processed after this point.
I examined the SQEs, particularly looking for fds that might be problematic. I find `IORING_OP_SEND_ZC` with `fd = 1768060463`, which fails with `-EBADF` and that's expected. Then I analyze the remaining SQEs. There's `IORING_OP_SPLICE` and others that return `-EBADF`, but those are fine. Then I search for `IORING_OP_FIXED_FD_INSTALL` which uses a fixed fd. However, there's no `0x2e` in the payload which means that's not the leak.
I examine the contents of the `sendmsg` payload, and realize that the relevant SQEs are stored within the truncated byte array starting from `0x6080` onwards. I go through each opcode and each `fd` value. I find `0x6580`, which contains `IORING_OP_WRITEV` with `fd = 3`. Wait, `fd = 3`! And `syz_open_dev` returns `3`! This means `IORING_OP_WRITEV` *is* being called on `/dev/vbi3`! That's interesting, and is probably the source of the leak!
I begin thinking of the implications of calling `writev` on `/dev/vbi3`, a V4L2 device.
|
| 91/2 |
2026/06/12 22:28 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_init_req]
Results: map[SourceCode:1734: static int io_init_req(struct io_ring_ctx *ctx, struct io_kiocb *req,
1735: const struct io_uring_sqe *sqe, unsigned int *left)
1736: __must_hold(&ctx->uring_lock)
1737: {
1738: const struct io_issue_def *def;
1739: unsigned int sqe_flags;
1740: int personality;
1741:
1742: req->ctx = ctx;
1743: req->opcode = READ_ONCE(sqe->opcode);
1744: /* same numerical values with corresponding REQ_F_*, safe to copy */
1745: sqe_flags = READ_ONCE(sqe->flags);
1746: req->flags = (__force io_req_flags_t) sqe_flags;
1747: req->cqe.user_data = READ_ONCE(sqe->user_data);
1748: req->file = NULL;
1749: req->tctx = current->io_uring;
1750: req->cancel_seq_set = false;
1751: req->async_data = NULL;
1752:
1753: if (unlikely(req->opcode >= IORING_OP_LAST)) {
1754: req->opcode = 0;
1755: return io_init_fail_req(req, -EINVAL);
1756: }
1757: req->opcode = array_index_nospec(req->opcode, IORING_OP_LAST);
1758:
1759: def = &io_issue_defs[req->opcode];
1760: if (def->is_128 && !(ctx->flags & IORING_SETUP_SQE128)) {
1761: /*
1762: * A 128b op on a non-128b SQ requires mixed SQE support as
1763: * well as 2 contiguous entries.
1764: */
1765: if (!(ctx->flags & IORING_SETUP_SQE_MIXED) || *left < 2 ||
1766: (unsigned)(sqe - ctx->sq_sqes) >= ctx->sq_entries - 1)
1767: return io_init_fail_req(req, -EINVAL);
1768: /*
1769: * A 128b operation on a mixed SQ uses two entries, so we have
1770: * to increment the head and cached refs, and decrement what's
1771: * left.
1772: */
1773: current->io_uring->cached_refs++;
1774: ctx->cached_sq_head++;
1775: (*left)--;
1776: }
1777:
1778: if (unlikely(sqe_flags & ~SQE_COMMON_FLAGS)) {
1779: /* enforce forwards compatibility on users */
1780: if (sqe_flags & ~SQE_VALID_FLAGS)
1781: return io_init_fail_req(req, -EINVAL);
1782: if (sqe_flags & IOSQE_BUFFER_SELECT) {
1783: if (!def->buffer_select)
1784: return io_init_fail_req(req, -EOPNOTSUPP);
1785: req->buf_index = READ_ONCE(sqe->buf_group);
1786: }
1787: if (sqe_flags & IOSQE_CQE_SKIP_SUCCESS)
1788: ctx->int_flags |= IO_RING_F_DRAIN_DISABLED;
1789: if (sqe_flags & IOSQE_IO_DRAIN) {
1790: if (ctx->int_flags & IO_RING_F_DRAIN_DISABLED)
1791: return io_init_fail_req(req, -EOPNOTSUPP);
1792: io_init_drain(ctx);
1793: }
1794: }
1795: if (unlikely(ctx->int_flags & (IO_RING_F_OP_RESTRICTED | IO_RING_F_DRAIN_ACTIVE | IO_RING_F_DRAIN_NEXT))) {
1796: if (!io_check_restriction(ctx, req, sqe_flags))
1797: return io_init_fail_req(req, -EACCES);
1798: /* knock it to the slow queue path, will be drained there */
1799: if (ctx->int_flags & IO_RING_F_DRAIN_ACTIVE)
1800: req->flags |= REQ_F_FORCE_ASYNC;
1801: /* if there is no link, we're at "next" request and need to drain */
1802: if (unlikely(ctx->int_flags & IO_RING_F_DRAIN_NEXT) && !ctx->submit_state.link.head) {
1803: ctx->int_flags &= ~IO_RING_F_DRAIN_NEXT;
1804: ctx->int_flags |= IO_RING_F_DRAIN_ACTIVE;
1805: req->flags |= REQ_F_IO_DRAIN | REQ_F_FORCE_ASYNC;
1806: }
1807: }
1808:
1809: if (!def->ioprio && sqe->ioprio)
1810: return io_init_fail_req(req, -EINVAL);
1811: if (!def->iopoll && (ctx->flags & IORING_SETUP_IOPOLL))
1812: return io_init_fail_req(req, -EINVAL);
1813:
1814: if (def->needs_file) {
1815: struct io_submit_state *state = &ctx->submit_state;
1816:
1817: req->cqe.fd = READ_ONCE(sqe->fd);
1818:
1819: /*
1820: * Plug now if we have more than 2 IO left after this, and the
1821: * target is potentially a read/write to block based storage.
1822: */
1823: if (state->need_plug && def->plug) {
1824: state->plug_started = true;
1825: state->need_plug = false;
1826: blk_start_plug_nr_ios(&state->plug, state->submit_nr);
1827: }
1828: }
1829:
1830: personality = READ_ONCE(sqe->personality);
1831: if (personality) {
1832: int ret;
1833:
1834: req->creds = xa_load(&ctx->personalities, personality);
1835: if (!req->creds)
1836: return io_init_fail_req(req, -EINVAL);
1837: get_cred(req->creds);
1838: ret = security_uring_override_creds(req->creds);
1839: if (ret) {
1840: put_cred(req->creds);
1841: return io_init_fail_req(req, ret);
1842: }
1843: req->flags |= REQ_F_CREDS;
1844: }
1845:
1846: return def->prep(req, sqe);
1847: }
SourceFile:io_uring/io_uring.c]
|
| 92/2 |
2026/06/12 22:28 |
llm |
expert |
1m
Model:
Tokens:
input: 170979
output: 36
thoughts: 10462
Thoughts: **Deep Dive into io_uring and Potential File Descriptor Leaks**
Okay, so I've got this `io_init_req` function in my sights, and specifically how it handles potential errors. I see that if `req->creds` is invalid, we return an `io_init_fail_req` with `-EINVAL`. This function sets `req->file` to `NULL` and the return value is an error code. Here's where it gets interesting: the request's file pointer never gets set because `io_req_set_file` happens *after* `io_init_req`. If `io_init_req` fails, the `io_issue_sqe` function, which *does* call `io_req_set_file`, is never even called! So, my immediate thought is that a failing `io_init_req` prevents any file descriptor from being set, which is good: if `req->file` is NULL, then it cannot leak file descriptors. Specifically, `IORING_OP_WRITEV` with `fd = 3` and a funky personality will fail and *not* leak anything, that much is clear.
However, I've got to be thorough, so I started looking for other possible file descriptor leaks. I need to check for other requests using fd 3. Let's dig! I start by checking through the SQEs for anything else that might use `fd=3`. I'm starting to get a little suspicious now. Checking the memory, I find a bunch of SQEs. Turns out that there are none SQEs with `fd=3` so I can exclude this from my thought process.
I'm checking if `syz_open_dev` might return 0. If it does, `fd = 0`. So, if `syz_open_dev` returns zero, could there be a security issue? I'm looking at all the SQEs. I'm focusing specifically on `IORING_OP_READV` and `fd=0`, and I find it! There is at least one `fd=0` request that will be processed. But then, if `syz_open_dev` returns 6, what requests use 6? There are a bunch using 6! So it turns out `io_uring` *is* actually processing `fd = 6`! It's time to check what requests use `/dev/vbi3`, to check if there are any leaks!
I think I've got a handle on how this thing works, so now I'm going to start checking what operations might leak something. I guess it's time to check how `IORING_OP_FSYNC` behaves. Let's see if this leaks a file descriptor! It's time to deep dive into the code...
|
| 93/2 |
2026/06/12 22:30 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/fsync.c Name:io_fsync]
Results: map[SourceCode: 72: int io_fsync(struct io_kiocb *req, unsigned int issue_flags)
73: {
74: struct io_sync *sync = io_kiocb_to_cmd(req, struct io_sync);
75: loff_t end = sync->off + sync->len;
76: int ret;
77:
78: /* fsync always requires a blocking context */
79: WARN_ON_ONCE(issue_flags & IO_URING_F_NONBLOCK);
80:
81: ret = vfs_fsync_range(req->file, sync->off, end > 0 ? end : LLONG_MAX,
82: sync->flags & IORING_FSYNC_DATASYNC);
83: io_req_set_res(req, ret, 0);
84: return IOU_COMPLETE;
85: }
SourceFile:io_uring/sync.c]
|
| 94/2 |
2026/06/12 22:30 |
llm |
expert |
0m
Model:
Tokens:
input: 182368
output: 37
thoughts: 201
Thoughts: **Analyzing Potential File Descriptor Leaks with io_uring**
Okay, let's break this down. First, the `io_fsync` operation returning `IOU_COMPLETE` immediately triggers the completion of the request via `io_issue_sqe`. Once complete, we know `io_req_complete_post` will be invoked, putting the file, right? So, based on this initial path, using `IORING_OP_FSYNC` *shouldn't* leak any file descriptors. Good.
Now, let's shift focus to `IORING_OP_SENDMSG`. That's where things get interesting. I see `0x6c80`, which I recognize as `IORING_OP_SENDMSG` and the file descriptor is 6. The alarm bells are going off... wait a minute, `/dev/vbi3` isn't a socket! If we try `sendmsg` on something that isn't a socket, `sockfd_lookup_light` will fail. That's a key point.
But, hold on. `io_sendmsg_prep` is the culprit here, since it calls `io_send_setup`. Now, does *that* check for the socketness of the file descriptor? Let's dive into `io_sendmsg_prep` and see what's actually happening. Gotta confirm if that crucial check is present before we can definitively rule out a leak. That's the critical piece of the puzzle.
|
| 95/2 |
2026/06/12 22:30 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/net.c Name:io_sendmsg_prep]
Results: map[SourceCode: 423: int io_sendmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
424: {
425: struct io_sr_msg *sr = io_kiocb_to_cmd(req, struct io_sr_msg);
426:
427: sr->done_io = 0;
428: sr->len = READ_ONCE(sqe->len);
429: if (unlikely(sr->len < 0))
430: return -EINVAL;
431: sr->flags = READ_ONCE(sqe->ioprio);
432: if (sr->flags & ~SENDMSG_FLAGS)
433: return -EINVAL;
434: sr->msg_flags = READ_ONCE(sqe->msg_flags) | MSG_NOSIGNAL;
435: if (sr->msg_flags & MSG_DONTWAIT)
436: req->flags |= REQ_F_NOWAIT;
437: if (req->flags & REQ_F_BUFFER_SELECT)
438: sr->buf_group = req->buf_index;
439: if (sr->flags & IORING_RECVSEND_BUNDLE) {
440: if (req->opcode == IORING_OP_SENDMSG)
441: return -EINVAL;
442: sr->msg_flags |= MSG_WAITALL;
443: req->flags |= REQ_F_MULTISHOT;
444: }
445:
446: if (io_is_compat(req->ctx))
447: sr->msg_flags |= MSG_CMSG_COMPAT;
448:
449: if (unlikely(!io_msg_alloc_async(req)))
450: return -ENOMEM;
451: if (req->opcode != IORING_OP_SENDMSG)
452: return io_send_setup(req, sqe);
453: if (unlikely(sqe->addr2 || sqe->file_index))
454: return -EINVAL;
455: return io_sendmsg_setup(req, sqe);
456: }
SourceFile:io_uring/net.c]
|
| 96/2 |
2026/06/12 22:30 |
llm |
expert |
0m
Model:
Tokens:
input: 183574
output: 35
thoughts: 63
Thoughts: Here's my summary, as I see it:
**Digging into the `io_sendmsg` Plumbing**
Okay, so I'm tracing the execution flow of `io_sendmsg`, and something's bugging me. I see that `io_sendmsg_prep` calls `io_sendmsg_setup`. That's standard enough, a preparation stage. But then I'm looking closer at `io_sendmsg_setup`, and my Spidey-sense is tingling. It's *copying* that `msghdr` from user space, right? That's fine, it *has* to copy it - the `msghdr` struct defines the data to be sent. But I'm not seeing any immediate checks to validate that we're actually dealing with a socket here. This feels... risky. Then the flow moves on to `io_sendmsg` itself, presumably with this unchecked `msghdr`. That seems like it could lead to potential vulnerabilities. I need to investigate how `io_sendmsg` handles this copied data and what assumptions it makes. I should probably focus on where the `msghdr` is being passed further and what protections are employed at that point.
|
| 97/2 |
2026/06/12 22:30 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/net.c Name:io_sendmsg]
Results: map[SourceCode: 550: int io_sendmsg(struct io_kiocb *req, unsigned int issue_flags)
551: {
552: struct io_sr_msg *sr = io_kiocb_to_cmd(req, struct io_sr_msg);
553: struct io_async_msghdr *kmsg = req->async_data;
554: struct socket *sock;
555: unsigned flags;
556: int min_ret = 0;
557: int ret;
558:
559: sock = sock_from_file(req->file);
560: if (unlikely(!sock))
561: return -ENOTSOCK;
562:
563: if (!(req->flags & REQ_F_POLLED) &&
564: (sr->flags & IORING_RECVSEND_POLL_FIRST))
565: return -EAGAIN;
566:
567: flags = sr->msg_flags;
568: if (issue_flags & IO_URING_F_NONBLOCK)
569: flags |= MSG_DONTWAIT;
570: if (flags & MSG_WAITALL)
571: min_ret = iov_iter_count(&kmsg->msg.msg_iter);
572:
573: kmsg->msg.msg_control_user = sr->msg_control;
574:
575: ret = __sys_sendmsg_sock(sock, &kmsg->msg, flags);
576:
577: if (ret < min_ret) {
578: if (ret == -EAGAIN && (issue_flags & IO_URING_F_NONBLOCK))
579: return -EAGAIN;
580: if (ret > 0 && io_net_retry(sock, flags)) {
581: kmsg->msg.msg_controllen = 0;
582: kmsg->msg.msg_control = NULL;
583: sr->done_io += ret;
584: return -EAGAIN;
585: }
586: if (ret == -ERESTARTSYS)
587: ret = -EINTR;
588: req_set_fail(req);
589: }
590: io_req_msg_cleanup(req, issue_flags);
591: if (ret >= 0)
592: ret += sr->done_io;
593: else if (sr->done_io)
594: ret = sr->done_io;
595: io_req_set_res(req, ret, 0);
596: return IOU_COMPLETE;
597: }
SourceFile:io_uring/net.c]
|
| 98/2 |
2026/06/12 22:30 |
llm |
expert |
0m
Model:
Tokens:
input: 184733
output: 19
thoughts: 434
Thoughts: **Analyzing Potential File Descriptor Leaks in io_uring and Beyond**
Okay, let's think this through. My initial concern was about potential file descriptor leaks within the `io_uring` subsystem. Specifically, I was worried about whether operations like `IORING_OP_SENDMSG` or `IORING_OP_WRITE_FIXED` might fail in a way that left file descriptors dangling. I immediately honed in on how these operations handle the file descriptor.
First, with `io_sendmsg`, the path looks like this: the `sock_from_file` call within `io_sendmsg` seems key. If the `req->file` isn't a socket, then a `-ENOTSOCK` error is returned, and `io_issue_sqe` dutifully completes the request with the same `-ENOTSOCK` error. Most importantly, the file should be properly handled. So, that specific `IORING_OP_SENDMSG` flow *shouldn't* leak the file descriptor. Good.
Next, I looked at `IORING_OP_WRITE_FIXED`, and a specific case where `fd = 6` caught my attention. This is a common pattern for writing fixed buffers. However, with `IORING_OP_WRITE_FIXED`, the fixed buffers are *critical*. If there are no fixed buffers registered, `io_write` would return `-EFAULT` or `-EINVAL`. The file then gets put. Thus, again, this particular flow *shouldn't* leak either.
So, it seems like neither of these SQE operations are the primary culprit. Okay, then, where else could it be? If it's not a direct `io_uring` leak, then it's worth exploring if the leak originates *before* the io_uring operations. I need to consider all possibilities and a potential bug in the `vivid` driver seems like it might be the problem.
The reproducer uses `syz_open_dev` on `/dev/vbi#`. Is it possible that the `vivid` driver has a file descriptor leak? Let's quickly research any known leaks in the `vivid` driver.
If it's a `vivid` driver issue, the leak is likely a `vivid` driver bug. But the syzbot report indicates a "memory leak". Let's parse this, and let's check it carefully: "unreferenced object 0xffff88810ac98000 (size 176):". The crucial piece here is "size 176".
Is the size 176 relevant? `struct file` is usually larger than 176 bytes, so what's that actually leaking? It's time to check the actual size of the `struct file` to clarify if the reported leak aligns with the file object size. I'm getting closer to understanding the root cause.
|
| 99/2 |
2026/06/12 22:30 |
tool |
codesearch-struct-layout |
0m
Args:
Results: map[Fields:[map[Name:f_lock OffsetBits:0 SizeBits:32] map[Name:f_mode OffsetBits:32 SizeBits:32] map[Name:f_op OffsetBits:64 SizeBits:64] map[Name:f_mapping OffsetBits:128 SizeBits:64] map[Name:private_data OffsetBits:192 SizeBits:64] map[Name:f_inode OffsetBits:256 SizeBits:64] map[Name:f_flags OffsetBits:320 SizeBits:32] map[Name:f_iocb_flags OffsetBits:352 SizeBits:32] map[Name:f_cred OffsetBits:384 SizeBits:64] map[Name:f_owner OffsetBits:448 SizeBits:64] map[Name: OffsetBits:512 SizeBits:128] map[Name: OffsetBits:640 SizeBits:192] map[Name:f_pos OffsetBits:832 SizeBits:64] map[Name:f_security OffsetBits:896 SizeBits:64] map[Name:f_wb_err OffsetBits:960 SizeBits:32] map[Name:f_sb_err OffsetBits:992 SizeBits:32] map[Name:f_ep OffsetBits:1024 SizeBits:64] map[Name: OffsetBits:1088 SizeBits:256] map[Name:f_ref OffsetBits:1344 SizeBits:64]]]
|
| 100/2 |
2026/06/12 22:30 |
llm |
expert |
0m
Model:
Tokens:
input: 186223
output: 21
thoughts: 1603
Thoughts: **Analyzing a Potential File Leak in io_uring**
Okay, so I've got this memory leak, and it looks like a `struct file`. The `sizeof` check confirms it: 176 bytes, exactly what I expect. And the backtrace points to `alloc_empty_file`, solidifying this. Why is a `struct file` being leaked, though? I need to think this through carefully.
Let's trace the `io_uring` setup. `io_uring_setup` gives us an fd. If `IORING_SETUP_REGISTERED_FD_ONLY` is set, we get an index, and the `struct file` is stored in `tctx->registered_rings[idx]`. `io_uring_setup` calls `io_uring_create`, which in turn calls either `io_ring_add_registered_file` or `io_uring_install_fd`. `io_ring_add_registered_file` returns the index, and `io_uring_create` ultimately returns 0. So far, so good. The critical part is if `sys_io_uring_setup` returns zero but the user program DOESN'T close it.
The user program exits. `do_exit` calls `io_uring_files_cancel()`. This in turn calls `__io_uring_cancel(false)`, which calls `io_uring_unreg_ringfd()`. This looks like the right path to clean up. Inside `io_uring_unreg_ringfd()`, for each registered file, `fput` is called on it, and the file is then set to NULL.
Now, `fput` adds the file to `task_work`, right? There's this conditional check to avoid adding to task_work if the context is interrupt or KTHREAD. Otherwise the file is added and ultimately freed, but I need to make sure this path is taken.
`io_uring_files_cancel` is called pretty early in `do_exit`, and `exit_task_work` will run later. I've got a good feeling about this: `task_work_add` SHOULD succeed, and `____fput` should be executed by `exit_task_work`. Okay, `____fput` calls `__fput`, and that ultimately calls the file's `f_op->release` function, and for io_uring, this is `io_uring_release`.
`io_uring_release` gets the `io_ring_ctx`, sets `file->private_data` to NULL, and calls `io_ring_ctx_wait_and_kill`, and then ultimately returns 0. However, `__fput` also calls `file_free` *after* the `release` function. Okay, so that should free the file. Everything is freed correctly.
Okay, let's explore if `io_uring_unreg_ringfd` isn't called. When could that happen? `io_uring_files_cancel` has a check: `if (current->io_uring)`. If `current->io_uring` is NULL, it's not called. But wait, `current->io_uring` is `tctx`, and that's allocated in `__io_uring_add_tctx_node`... so that should NOT be NULL. What about if it gets freed before the cancel? That could be a problem.
Ah, `current->io_uring` *is* freed in `io_uring_cancel_generic` if `cancel_all` is true. `io_uring_files_cancel` calls `__io_uring_cancel(false)`. So, `cancel_all` is false, and `__io_uring_free(current)` is NOT called at that point. So, the file SHOULD be cleaned up.
So, when IS `__io_uring_free(current)` called? The only call to that function is from `io_uring_task_cancel`, which is called from `begin_new_exec` and `do_exit`! But wait, `do_exit` doesn't call `io_uring_task_cancel`.
I need to recheck `do_exit`. Ah, it only calls `io_uring_files_cancel()`. Okay. It seems like the normal exit path *should* clean up everything. I need to make sure all paths that free the `struct file` are taken. I need to review what calls `io_uring_task_cancel`. I might have found my problem here.
|
| 101/2 |
2026/06/12 22:30 |
tool |
grepper |
0m
Args: map[Expression:io_uring_task_cancel]
Results: map[Output:fs/exec.c=1091=int begin_new_exec(struct linux_binprm * bprm)
--
fs/exec.c-1122- */
fs/exec.c:1123: io_uring_task_cancel();
fs/exec.c-1124-
--
include/linux/io_uring.h=17=static inline void io_uring_files_cancel(void)
--
include/linux/io_uring.h-21-}
include/linux/io_uring.h:22:static inline void io_uring_task_cancel(void)
include/linux/io_uring.h-23-{
--
include/linux/io_uring.h=32=static inline int io_uring_fork(struct task_struct *tsk)
--
include/linux/io_uring.h-39-#else
include/linux/io_uring.h:40:static inline void io_uring_task_cancel(void)
include/linux/io_uring.h-41-{
]
|
| 102/2 |
2026/06/12 22:30 |
llm |
expert |
0m
Model:
Tokens:
input: 189107
output: 30
thoughts: 47
Thoughts: Okay, here's my interpretation of those thoughts, presented as a personal thought process, as requested:
**A Quick Puzzle**
Wait a second... I'm pretty sure I remember the code mentioning that `io_uring_task_cancel` is *only* ever called from `begin_new_exec`. That's a pretty strong constraint. So that means something critical is going on. Then, a follow up is, if this is true, where does the `tctx` get cleaned up when a new execution ends?
Okay, let's stop and think about this for a second. If there's a cancel happening here, and it's isolated to begin_new_exec, the lifecycle of that context seems incomplete. I have a feeling I know where to look, but let's just make sure. Let's not assume anything here. So, the obvious next place to look would be `io_uring_free`. I bet that's where the cleanup happens. Let's go check...
|
| 103/2 |
2026/06/12 22:31 |
tool |
codesearch-find-references |
0m
Args: map[IncludeSnippetLines:0 Name:__io_uring_free]
Results: map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:io_uring_cancel_generic SourceFile:io_uring/cancel.c SourceLine:665] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:io_uring_free SourceFile:include/linux/io_uring.h SourceLine:30]] TruncatedOutput:false]
|
| 104/2 |
2026/06/12 22:31 |
llm |
expert |
0m
Model:
Tokens:
input: 189520
output: 29
thoughts: 11
Thoughts: Okay, here's my attempt at summarizing that thought process, keeping in mind I'm speaking to a fellow expert:
**Investigating `io_uring_free`**
Alright, time to dive in. My mind immediately goes to `io_uring_free`. I need to refresh my understanding of how this function is supposed to work and what areas it touches within the io_uring ecosystem. Specifically, I'm thinking about the memory management aspects, the possible race conditions, and how it interacts with the submission and completion queues. I'm going to quickly review my understanding of the relevant data structures and make sure that any recent changes or discussions that I may have missed didn't impact how `io_uring_free` functions. Gotta ensure everything is sound at the foundational level here.
|
| 105/2 |
2026/06/12 22:31 |
tool |
codesearch-find-references |
0m
Args: map[IncludeSnippetLines:0 Name:io_uring_free]
Results: map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:__put_task_struct SourceFile:kernel/fork.c SourceLine:785] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:copy_process SourceFile:kernel/fork.c SourceLine:2587]] TruncatedOutput:false]
|
| 106/2 |
2026/06/12 22:31 |
llm |
expert |
0m
Model:
Tokens:
input: 189839
output: 38
thoughts: 485
Thoughts: **Analyzing io_uring Task Context Cleanup**
Okay, so I'm digging into this `io_uring` cleanup flow. First thought: `io_uring_free` is definitely called from `__put_task_struct`, which makes sense because the task struct lifecycle dictates when the task context, `tctx`, is freed. That seems right. But hold on, I just remembered that `io_uring_unreg_ringfd` is called from `__io_uring_cancel(false)`. That function is called from `io_uring_files_cancel`, which in turn is called from `do_exit`. So, *yes*, `io_uring_unreg_ringfd` *is* definitely called during process exit.
Now, a potential race condition pops into my head. What if `io_uring_unreg_ringfd` *does* get called, but the associated ring file descriptor isn't cleared from `tctx->registered_rings`? Ah, but I see now: `tctx->registered_rings[i] = NULL;` is right there, ensuring proper nulling. Good.
Next thought: What if `io_uring_setup` returns an index, but that ring fd is not stored in `current->io_uring`? No, no, `tctx` is `current->io_uring`, as expected.
Okay, let's step through a potential edge case. What if `io_uring_setup` fails *after* `io_ring_add_registered_file` has succeeded? I need to check the exact sequence of events. Let's see...
```c
if (p->flags & IORING_SETUP_REGISTERED_FD_ONLY)
ret = io_ring_add_registered_file(tctx, file, 0, IO_RINGFD_REG_MAX);
else
ret = io_uring_install_fd(file);
if (ret < 0)
goto err_fput;
trace_io_uring_create(ret, ctx, p->sq_entries, p->cq_entries, p->flags);
return ret;
err:
io_ring_ctx_wait_and_kill(ctx);
return ret;
err_fput:
fput(file);
return ret;
```
Right, if `io_ring_add_registered_file` succeeds, it returns `ret >= 0`. Then, `io_uring_create` ultimately returns `ret`. So, there's no way to fail *after* `io_ring_add_registered_file` if it succeeded, since the return value is immediately used. No issues there.
Now, what if `sys_io_uring_setup` fails *after* `io_uring_create`? I'm going to have to check `sys_io_uring_setup` and examine the return path there.
|
| 107/2 |
2026/06/12 22:31 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_uring_setup]
Results: map[SourceCode:3106: /*
3107: * Sets up an aio uring context, and returns the fd. Applications asks for a
3108: * ring size, we return the actual sq/cq ring sizes (among other things) in the
3109: * params structure passed in.
3110: */
3111: static long io_uring_setup(u32 entries, struct io_uring_params __user *params)
3112: {
3113: struct io_ctx_config config;
3114:
3115: memset(&config, 0, sizeof(config));
3116:
3117: if (copy_from_user(&config.p, params, sizeof(config.p)))
3118: return -EFAULT;
3119:
3120: if (!mem_is_zero(&config.p.resv, sizeof(config.p.resv)))
3121: return -EINVAL;
3122:
3123: config.p.sq_entries = entries;
3124: config.uptr = params;
3125: return io_uring_create(&config);
3126: }
SourceFile:io_uring/io_uring.c]
|
| 108/2 |
2026/06/12 22:31 |
llm |
expert |
0m
Model:
Tokens:
input: 191357
output: 32
thoughts: 7994
Thoughts: **Analyzing a Potential io_uring File Descriptor Leak**
Okay, so I'm trying to figure out if there's a file descriptor leak in an `io_uring` context, specifically when using `IORING_SETUP_REGISTERED_FD_ONLY`. Let's break this down systematically. First, `io_uring_setup` seems straightforward: it creates the ring and returns a result. No chance of a leak directly after creation. If the setup succeeds and we're using `IORING_SETUP_REGISTERED_FD_ONLY`, the resulting file is in `tctx->registered_rings[idx]`. When the process exits, `io_uring_unreg_ringfd` is called, which then does an `fput` on the file descriptor.
The `fput` call is critical. That `fput` adds it to `task_work`, and the `exit_task_work` will execute `____fput`, which ultimately calls `io_uring_release`. The `io_uring_release` function then *should* free the file. Thus, it looks like, at the initial ring setup, there shouldn't be a leak.
Now, let's consider `/dev/vbi3`. If it's leaked, it means its reference count isn't zero. Where does `/dev/vbi3` come into play? Aha! The reproducer's use of `IORING_OP_WRITEV` on `fd=3`, which maps to `/dev/vbi3` is the key. `io_issue_sqe` calls `io_req_set_file`, which in turn calls `fget(3)`. So the request holds a reference. If the request completes, `io_req_complete_post` calls `io_req_put_rsrc`, which calls `fput(req->file)`. This makes sense.
But what if the request *doesn't* complete? If it's unfinished, it resides in `io_wq` or `tctx->task_list`. On exit, `io_uring_cancel_generic` is called. It cancels requests. What if it *can't* cancel a request? `io_uring_cancel_generic` waits, but the syzbot report is a *memory leak*, which means the process exited. Therefore `io_uring_cancel_generic` *did* finish! Since it finished, it means `tctx_inflight` became 0, all requests completed, and each request has its file put (fput) . This seems to rule out a leak from incomplete requests.
Could any other operations cause a leak? What about `IORING_OP_FIXED_FD_INSTALL`? That's when you install a fixed file. However, this reproducer doesn't use fixed files, it is registering it through `IORING_SETUP_REGISTERED_FD_ONLY`, therefore, there is no chance that the operation is using the fixed file table. Also, let's confirm the operations in the `sendmsg` payload, just to verify if some other fixed file installation occurs. There are a lot of nops, poll_remove, writev, fsync, read_fixed, sync_file_range, sendmsg, link_timeout, and other operations, but no install of a fixed file. So, this route is blocked.
So, it doesn't look like `io_uring` itself is leaking the file. But could `io_uring_setup` itself cause a leak? What if that first call to `io_uring_setup` with `IORING_SETUP_REGISTERED_FD_ONLY` leaks it? But that call is *supposed* to place the file into `tctx->registered_rings[idx]`. And upon exiting, `io_uring_unreg_ringfd` does an `fput` on those. Now, the `fput` function itself. If it calls `init_task_work`, and `task_work_add` fails, then there could be a leak. However, `task_work_add` will fail when the task's work is already set to `&work_exited`, but that happens *after* the `io_uring_files_cancel` and `exit_task_work`. So, `task_work_add` will succeed, putting the file on `task->task_works`. And then `exit_task_work` handles all task works, including `____fput`. In `____fput`, `__fput` then calls the release function, `io_uring_release`. It all seems properly balanced there. What if `task_work_add` fails and the file pointer is still there? If it fails
|
| 109/2 |
2026/06/12 22:32 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:kernel/fork.c Name:copy_process]
Results: map[SourceCode:1961: /*
1962: * This creates a new process as a copy of the old one,
1963: * but does not actually start it yet.
1964: *
1965: * It copies the registers, and all the appropriate
1966: * parts of the process environment (as per the clone
1967: * flags). The actual kick-off is left to the caller.
1968: */
1969: __latent_entropy struct task_struct *copy_process(
1970: struct pid *pid,
1971: int trace,
1972: int node,
1973: struct kernel_clone_args *args)
1974: {
1975: int pidfd = -1, retval;
1976: struct task_struct *p;
1977: struct multiprocess_signals delayed;
1978: struct file *pidfile = NULL;
1979: const u64 clone_flags = args->flags;
1980: struct nsproxy *nsp = current->nsproxy;
1981:
1982: /*
1983: * Don't allow sharing the root directory with processes in a different
1984: * namespace
1985: */
1986: if ((clone_flags & (CLONE_NEWNS|CLONE_FS)) == (CLONE_NEWNS|CLONE_FS))
1987: return ERR_PTR(-EINVAL);
1988:
1989: if ((clone_flags & (CLONE_NEWUSER|CLONE_FS)) == (CLONE_NEWUSER|CLONE_FS))
1990: return ERR_PTR(-EINVAL);
1991:
1992: /*
1993: * Thread groups must share signals as well, and detached threads
1994: * can only be started up within the thread group.
1995: */
1996: if ((clone_flags & CLONE_THREAD) && !(clone_flags & CLONE_SIGHAND))
1997: return ERR_PTR(-EINVAL);
1998:
1999: /*
2000: * Shared signal handlers imply shared VM. By way of the above,
2001: * thread groups also imply shared VM. Blocking this case allows
2002: * for various simplifications in other code.
2003: */
2004: if ((clone_flags & CLONE_SIGHAND) && !(clone_flags & CLONE_VM))
2005: return ERR_PTR(-EINVAL);
2006:
2007: /*
2008: * Siblings of global init remain as zombies on exit since they are
2009: * not reaped by their parent (swapper). To solve this and to avoid
2010: * multi-rooted process trees, prevent global and container-inits
2011: * from creating siblings.
2012: */
2013: if ((clone_flags & CLONE_PARENT) &&
2014: current->signal->flags & SIGNAL_UNKILLABLE)
2015: return ERR_PTR(-EINVAL);
2016:
2017: /*
2018: * If the new process will be in a different pid or user namespace
2019: * do not allow it to share a thread group with the forking task.
2020: */
2021: if (clone_flags & CLONE_THREAD) {
2022: if ((clone_flags & (CLONE_NEWUSER | CLONE_NEWPID)) ||
2023: (task_active_pid_ns(current) != nsp->pid_ns_for_children))
2024: return ERR_PTR(-EINVAL);
2025: }
2026:
2027: if (clone_flags & CLONE_PIDFD) {
2028: /*
2029: * - CLONE_DETACHED is blocked so that we can potentially
2030: * reuse it later for CLONE_PIDFD.
2031: */
2032: if (clone_flags & CLONE_DETACHED)
2033: return ERR_PTR(-EINVAL);
2034: }
2035:
2036: if (clone_flags & CLONE_AUTOREAP) {
2037: if (clone_flags & CLONE_THREAD)
2038: return ERR_PTR(-EINVAL);
2039: if (clone_flags & CLONE_PARENT)
2040: return ERR_PTR(-EINVAL);
2041: if (args->exit_signal)
2042: return ERR_PTR(-EINVAL);
2043: }
2044:
2045: if ((clone_flags & CLONE_PARENT) && current->signal->autoreap)
2046: return ERR_PTR(-EINVAL);
2047:
2048: if (clone_flags & CLONE_NNP) {
2049: if (clone_flags & CLONE_THREAD)
2050: return ERR_PTR(-EINVAL);
2051: }
2052:
2053: if (clone_flags & CLONE_PIDFD_AUTOKILL) {
2054: if (!(clone_flags & CLONE_PIDFD))
2055: return ERR_PTR(-EINVAL);
2056: if (!(clone_flags & CLONE_AUTOREAP))
2057: return ERR_PTR(-EINVAL);
2058: if (clone_flags & CLONE_THREAD)
2059: return ERR_PTR(-EINVAL);
2060: /*
2061: * Without CLONE_NNP the child could escalate privileges
2062: * after being spawned, so require CAP_SYS_ADMIN.
2063: * With CLONE_NNP the child can't gain new privileges,
2064: * so allow unprivileged usage.
2065: */
2066: if (!(clone_flags & CLONE_NNP) &&
2067: !ns_capable(current_user_ns(), CAP_SYS_ADMIN))
2068: return ERR_PTR(-EPERM);
2069: }
2070:
2071: /*
2072: * Force any signals received before this point to be delivered
2073: * before the fork happens. Collect up signals sent to multiple
2074: * processes that happen during the fork and delay them so that
2075: * they appear to happen after the fork.
2076: */
2077: sigemptyset(&delayed.signal);
2078: INIT_HLIST_NODE(&delayed.node);
2079:
2080: spin_lock_irq(¤t->sighand->siglock);
2081: if (!(clone_flags & CLONE_THREAD))
2082: hlist_add_head(&delayed.node, ¤t->signal->multiprocess);
2083: recalc_sigpending();
2084: spin_unlock_irq(¤t->sighand->siglock);
2085: retval = -ERESTARTNOINTR;
2086: if (task_sigpending(current))
2087: goto fork_out;
2088:
2089: retval = -ENOMEM;
2090: p = dup_task_struct(current, node);
2091: if (!p)
2092: goto fork_out;
2093: p->flags &= ~PF_KTHREAD;
2094: if (args->kthread)
2095: p->flags |= PF_KTHREAD;
2096: if (args->user_worker) {
2097: /*
2098: * Mark us a user worker, and block any signal that isn't
2099: * fatal or STOP
2100: */
2101: p->flags |= PF_USER_WORKER;
2102: siginitsetinv(&p->blocked, sigmask(SIGKILL)|sigmask(SIGSTOP));
2103: }
2104: if (args->io_thread)
2105: p->flags |= PF_IO_WORKER;
2106:
2107: if (args->name)
2108: strscpy_pad(p->comm, args->name, sizeof(p->comm));
2109:
2110: p->set_child_tid = (clone_flags & CLONE_CHILD_SETTID) ? args->child_tid : NULL;
2111: /*
2112: * TID is cleared in mm_release() when the task exits
2113: */
2114: p->clear_child_tid = (clone_flags & CLONE_CHILD_CLEARTID) ? args->child_tid : NULL;
2115:
2116: ftrace_graph_init_task(p);
2117:
2118: rt_mutex_init_task(p);
2119: raw_spin_lock_init(&p->blocked_lock);
2120:
2121: lockdep_assert_irqs_enabled();
2122: #ifdef CONFIG_PROVE_LOCKING
2123: DEBUG_LOCKS_WARN_ON(!p->softirqs_enabled);
2124: #endif
2125: retval = copy_creds(p, clone_flags);
2126: if (retval < 0)
2127: goto bad_fork_free;
2128:
2129: retval = -EAGAIN;
2130: if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
2131: if (p->real_cred->user != INIT_USER &&
2132: !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
2133: goto bad_fork_cleanup_count;
2134: }
2135: current->flags &= ~PF_NPROC_EXCEEDED;
2136:
2137: /*
2138: * If multiple threads are within copy_process(), then this check
2139: * triggers too late. This doesn't hurt, the check is only there
2140: * to stop root fork bombs.
2141: */
2142: retval = -EAGAIN;
2143: if (data_race(nr_threads >= max_threads))
2144: goto bad_fork_cleanup_count;
2145:
2146: delayacct_tsk_init(p); /* Must remain after dup_task_struct() */
2147: p->flags &= ~(PF_SUPERPRIV | PF_WQ_WORKER | PF_IDLE | PF_NO_SETAFFINITY);
2148: p->flags |= PF_FORKNOEXEC;
2149: INIT_LIST_HEAD(&p->children);
2150: INIT_LIST_HEAD(&p->sibling);
2151: rcu_copy_process(p);
2152: p->vfork_done = NULL;
2153: spin_lock_init(&p->alloc_lock);
2154:
2155: init_sigpending(&p->pending);
2156:
2157: p->utime = p->stime = p->gtime = 0;
2158: #ifdef CONFIG_ARCH_HAS_SCALED_CPUTIME
2159: p->utimescaled = p->stimescaled = 0;
2160: #endif
2161: prev_cputime_init(&p->prev_cputime);
2162:
2163: #ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
2164: seqcount_init(&p->vtime.seqcount);
2165: p->vtime.starttime = 0;
2166: p->vtime.state = VTIME_INACTIVE;
2167: #endif
2168:
2169: #ifdef CONFIG_IO_URING
2170: p->io_uring = NULL;
2171: retval = io_uring_fork(p);
2172: if (unlikely(retval))
2173: goto bad_fork_cleanup_delayacct;
2174: retval = -EAGAIN;
2175: #endif
2176:
2177: p->default_timer_slack_ns = current->timer_slack_ns;
2178:
2179: #ifdef CONFIG_PSI
2180: p->psi_flags = 0;
2181: #endif
2182:
2183: task_io_accounting_init(&p->ioac);
2184: acct_clear_integrals(p);
2185:
2186: posix_cputimers_init(&p->posix_cputimers);
2187: tick_dep_init_task(p);
2188:
2189: p->io_context = NULL;
2190: audit_set_context(p, NULL);
2191: cgroup_fork(p);
2192: if (args->kthread) {
2193: if (!set_kthread_struct(p))
2194: goto bad_fork_cleanup_delayacct;
2195: }
2196: #ifdef CONFIG_NUMA
2197: p->mempolicy = mpol_dup(p->mempolicy);
2198: if (IS_ERR(p->mempolicy)) {
2199: retval = PTR_ERR(p->mempolicy);
2200: p->mempolicy = NULL;
2201: goto bad_fork_cleanup_delayacct;
2202: }
2203: #endif
2204: #ifdef CONFIG_CPUSETS
2205: p->cpuset_mem_spread_rotor = NUMA_NO_NODE;
2206: seqcount_spinlock_init(&p->mems_allowed_seq, &p->alloc_lock);
2207: #endif
2208: #ifdef CONFIG_TRACE_IRQFLAGS
2209: memset(&p->irqtrace, 0, sizeof(p->irqtrace));
2210: p->irqtrace.hardirq_disable_ip = _THIS_IP_;
2211: p->irqtrace.softirq_enable_ip = _THIS_IP_;
2212: p->softirqs_enabled = 1;
2213: p->softirq_context = 0;
2214: #endif
2215:
2216: p->pagefault_disabled = 0;
2217:
2218: lockdep_init_task(p);
2219:
2220: p->blocked_on = NULL; /* not blocked yet */
2221:
2222: #ifdef CONFIG_BCACHE
2223: p->sequential_io = 0;
2224: p->sequential_io_avg = 0;
2225: #endif
2226: #ifdef CONFIG_BPF_SYSCALL
2227: RCU_INIT_POINTER(p->bpf_storage, NULL);
2228: p->bpf_ctx = NULL;
2229: #endif
2230:
2231: unwind_task_init(p);
2232:
2233: /* Perform scheduler related setup. Assign this task to a CPU. */
2234: retval = sched_fork(clone_flags, p);
2235: if (retval)
2236: goto bad_fork_cleanup_policy;
2237:
2238: retval = perf_event_init_task(p, clone_flags);
2239: if (retval)
2240: goto bad_fork_sched_cancel_fork;
2241: retval = audit_alloc(p);
2242: if (retval)
2243: goto bad_fork_cleanup_perf;
2244: /* copy all the process information */
2245: shm_init_task(p);
2246: retval = security_task_alloc(p, clone_flags);
2247: if (retval)
2248: goto bad_fork_cleanup_audit;
2249: retval = copy_semundo(clone_flags, p);
2250: if (retval)
2251: goto bad_fork_cleanup_security;
2252: retval = copy_files(clone_flags, p, args->no_files);
2253: if (retval)
2254: goto bad_fork_cleanup_semundo;
2255: retval = copy_fs(clone_flags, p);
2256: if (retval)
2257: goto bad_fork_cleanup_files;
2258: retval = copy_sighand(clone_flags, p);
2259: if (retval)
2260: goto bad_fork_cleanup_fs;
2261: retval = copy_signal(clone_flags, p);
2262: if (retval)
2263: goto bad_fork_cleanup_sighand;
2264: retval = copy_mm(clone_flags, p);
2265: if (retval)
2266: goto bad_fork_cleanup_signal;
2267: retval = copy_namespaces(clone_flags, p);
2268: if (retval)
2269: goto bad_fork_cleanup_mm;
2270: retval = copy_io(clone_flags, p);
2271: if (retval)
2272: goto bad_fork_cleanup_namespaces;
2273: retval = copy_thread(p, args);
2274: if (retval)
2275: goto bad_fork_cleanup_io;
2276:
2277: stackleak_task_init(p);
2278:
2279: if (pid != &init_struct_pid) {
2280: pid = alloc_pid(p->nsproxy->pid_ns_for_children, args->set_tid,
2281: args->set_tid_size);
2282: if (IS_ERR(pid)) {
2283: retval = PTR_ERR(pid);
2284: goto bad_fork_cleanup_thread;
2285: }
2286: }
2287:
2288: /*
2289: * This has to happen after we've potentially unshared the file
2290: * descriptor table (so that the pidfd doesn't leak into the child
2291: * if the fd table isn't shared).
2292: */
2293: if (clone_flags & CLONE_PIDFD) {
2294: unsigned flags = PIDFD_STALE;
2295:
2296: if (clone_flags & CLONE_THREAD)
2297: flags |= PIDFD_THREAD;
2298: if (clone_flags & CLONE_PIDFD_AUTOKILL)
2299: flags |= PIDFD_AUTOKILL;
2300:
2301: /*
2302: * Note that no task has been attached to @pid yet indicate
2303: * that via CLONE_PIDFD.
2304: */
2305: retval = pidfd_prepare(pid, flags, &pidfile);
2306: if (retval < 0)
2307: goto bad_fork_free_pid;
2308: pidfd = retval;
2309:
2310: retval = put_user(pidfd, args->pidfd);
2311: if (retval)
2312: goto bad_fork_put_pidfd;
2313: }
2314:
2315: #ifdef CONFIG_BLOCK
2316: p->plug = NULL;
2317: #endif
2318: futex_init_task(p);
2319:
2320: /*
2321: * sigaltstack should be cleared when sharing the same VM
2322: */
2323: if ((clone_flags & (CLONE_VM|CLONE_VFORK)) == CLONE_VM)
2324: sas_ss_reset(p);
2325:
2326: /*
2327: * Syscall tracing and stepping should be turned off in the
2328: * child regardless of CLONE_PTRACE.
2329: */
2330: user_disable_single_step(p);
2331: clear_task_syscall_work(p, SYSCALL_TRACE);
2332: #if defined(CONFIG_GENERIC_ENTRY) || defined(TIF_SYSCALL_EMU)
2333: clear_task_syscall_work(p, SYSCALL_EMU);
2334: #endif
2335: clear_tsk_latency_tracing(p);
2336:
2337: /* ok, now we should be set up.. */
2338: p->pid = pid_nr(pid);
2339: if (clone_flags & CLONE_THREAD) {
2340: p->group_leader = current->group_leader;
2341: p->tgid = current->tgid;
2342: } else {
2343: p->group_leader = p;
2344: p->tgid = p->pid;
2345: }
2346:
2347: p->nr_dirtied = 0;
2348: p->nr_dirtied_pause = 128 >> (PAGE_SHIFT - 10);
2349: p->dirty_paused_when = 0;
2350:
2351: p->pdeath_signal = 0;
2352: p->task_works = NULL;
2353: clear_posix_cputimers_work(p);
2354:
2355: #ifdef CONFIG_KRETPROBES
2356: p->kretprobe_instances.first = NULL;
2357: #endif
2358: #ifdef CONFIG_RETHOOK
2359: p->rethooks.first = NULL;
2360: #endif
2361:
2362: /*
2363: * Ensure that the cgroup subsystem policies allow the new process to be
2364: * forked. It should be noted that the new process's css_set can be changed
2365: * between here and cgroup_post_fork() if an organisation operation is in
2366: * progress.
2367: */
2368: retval = cgroup_can_fork(p, args);
2369: if (retval)
2370: goto bad_fork_put_pidfd;
2371:
2372: /*
2373: * Now that the cgroups are pinned, re-clone the parent cgroup and put
2374: * the new task on the correct runqueue. All this *before* the task
2375: * becomes visible.
2376: *
2377: * This isn't part of ->can_fork() because while the re-cloning is
2378: * cgroup specific, it unconditionally needs to place the task on a
2379: * runqueue.
2380: */
2381: retval = sched_cgroup_fork(p, args);
2382: if (retval)
2383: goto bad_fork_cancel_cgroup;
2384:
2385: if (need_futex_hash_allocate_default(clone_flags)) {
2386: retval = futex_hash_allocate_default();
2387: if (retval)
2388: goto bad_fork_cancel_cgroup;
2389: /*
2390: * If we fail beyond this point we don't free the allocated
2391: * futex hash map. We assume that another thread will be created
2392: * and makes use of it. The hash map will be freed once the main
2393: * thread terminates.
2394: */
2395: }
2396: /*
2397: * From this point on we must avoid any synchronous user-space
2398: * communication until we take the tasklist-lock. In particular, we do
2399: * not want user-space to be able to predict the process start-time by
2400: * stalling fork(2) after we recorded the start_time but before it is
2401: * visible to the system.
2402: */
2403:
2404: p->start_time = ktime_get_ns();
2405: p->start_boottime = ktime_get_boottime_ns();
2406:
2407: /*
2408: * Make it visible to the rest of the system, but dont wake it up yet.
2409: * Need tasklist lock for parent etc handling!
2410: */
2411: write_lock_irq(&tasklist_lock);
2412:
2413: /* CLONE_PARENT re-uses the old parent */
2414: if (clone_flags & (CLONE_PARENT|CLONE_THREAD)) {
2415: p->real_parent = current->real_parent;
2416: p->parent_exec_id = current->parent_exec_id;
2417: if (clone_flags & CLONE_THREAD)
2418: p->exit_signal = -1;
2419: else
2420: p->exit_signal = current->group_leader->exit_signal;
2421: } else {
2422: p->real_parent = current;
2423: p->parent_exec_id = current->self_exec_id;
2424: p->exit_signal = args->exit_signal;
2425: }
2426:
2427: klp_copy_process(p);
2428:
2429: sched_core_fork(p);
2430:
2431: spin_lock(¤t->sighand->siglock);
2432:
2433: rv_task_fork(p);
2434:
2435: rseq_fork(p, clone_flags);
2436:
2437: /*
2438: * If zap_pid_ns_processes() was called after alloc_pid(), the new
2439: * child missed SIGKILL. If current is not in the same namespace,
2440: * we can't rely on fatal_signal_pending() below.
2441: */
2442: if (unlikely(!(ns_of_pid(pid)->pid_allocated & PIDNS_ADDING))) {
2443: retval = -ENOMEM;
2444: goto bad_fork_core_free;
2445: }
2446:
2447: /* Let kill terminate clone/fork in the middle */
2448: if (fatal_signal_pending(current)) {
2449: retval = -EINTR;
2450: goto bad_fork_core_free;
2451: }
2452:
2453: /* No more failure paths after this point. */
2454:
2455: /*
2456: * Copy seccomp details explicitly here, in case they were changed
2457: * before holding sighand lock.
2458: */
2459: copy_seccomp(p);
2460:
2461: if (clone_flags & CLONE_NNP)
2462: task_set_no_new_privs(p);
2463:
2464: init_task_pid_links(p);
2465: if (likely(p->pid)) {
2466: ptrace_init_task(p, (clone_flags & CLONE_PTRACE) || trace);
2467:
2468: init_task_pid(p, PIDTYPE_PID, pid);
2469: if (thread_group_leader(p)) {
2470: init_task_pid(p, PIDTYPE_TGID, pid);
2471: init_task_pid(p, PIDTYPE_PGID, task_pgrp(current));
2472: init_task_pid(p, PIDTYPE_SID, task_session(current));
2473:
2474: if (is_child_reaper(pid)) {
2475: struct pid_namespace *ns = ns_of_pid(pid);
2476:
2477: ASSERT_EXCLUSIVE_WRITER(ns->child_reaper);
2478: WRITE_ONCE(ns->child_reaper, p);
2479: p->signal->flags |= SIGNAL_UNKILLABLE;
2480: }
2481: p->signal->shared_pending.signal = delayed.signal;
2482: p->signal->tty = tty_kref_get(current->signal->tty);
2483: /*
2484: * Inherit has_child_subreaper flag under the same
2485: * tasklist_lock with adding child to the process tree
2486: * for propagate_has_child_subreaper optimization.
2487: */
2488: p->signal->has_child_subreaper = p->real_parent->signal->has_child_subreaper ||
2489: p->real_parent->signal->is_child_subreaper;
2490: if (clone_flags & CLONE_AUTOREAP)
2491: p->signal->autoreap = 1;
2492: list_add_tail(&p->sibling, &p->real_parent->children);
2493: list_add_tail_rcu(&p->tasks, &init_task.tasks);
2494: attach_pid(p, PIDTYPE_TGID);
2495: attach_pid(p, PIDTYPE_PGID);
2496: attach_pid(p, PIDTYPE_SID);
2497: __this_cpu_inc(process_counts);
2498: } else {
2499: current->signal->nr_threads++;
2500: current->signal->quick_threads++;
2501: atomic_inc(¤t->signal->live);
2502: refcount_inc(¤t->signal->sigcnt);
2503: task_join_group_stop(p);
2504: list_add_tail_rcu(&p->thread_node,
2505: &p->signal->thread_head);
2506: }
2507: attach_pid(p, PIDTYPE_PID);
2508: nr_threads++;
2509: }
2510: total_forks++;
2511: hlist_del_init(&delayed.node);
2512: spin_unlock(¤t->sighand->siglock);
2513: syscall_tracepoint_update(p);
2514: write_unlock_irq(&tasklist_lock);
2515:
2516: if (pidfile)
2517: fd_install(pidfd, pidfile);
2518:
2519: proc_fork_connector(p);
2520: /*
2521: * sched_ext needs @p to be associated with its cgroup in its post_fork
2522: * hook. cgroup_post_fork() should come before sched_post_fork().
2523: */
2524: cgroup_post_fork(p, args);
2525: sched_post_fork(p);
2526: perf_event_fork(p);
2527:
2528: trace_task_newtask(p, clone_flags);
2529: uprobe_copy_process(p, clone_flags);
2530: user_events_fork(p, clone_flags);
2531:
2532: copy_oom_score_adj(clone_flags, p);
2533:
2534: return p;
2535:
2536: bad_fork_core_free:
2537: sched_core_free(p);
2538: spin_unlock(¤t->sighand->siglock);
2539: write_unlock_irq(&tasklist_lock);
2540: bad_fork_cancel_cgroup:
2541: cgroup_cancel_fork(p, args);
2542: bad_fork_put_pidfd:
2543: if (clone_flags & CLONE_PIDFD) {
2544: fput(pidfile);
2545: put_unused_fd(pidfd);
2546: }
2547: bad_fork_free_pid:
2548: if (pid != &init_struct_pid)
2549: free_pid(pid);
2550: bad_fork_cleanup_thread:
2551: exit_thread(p);
2552: bad_fork_cleanup_io:
2553: if (p->io_context)
2554: exit_io_context(p);
2555: bad_fork_cleanup_namespaces:
2556: exit_nsproxy_namespaces(p);
2557: bad_fork_cleanup_mm:
2558: if (p->mm) {
2559: mm_clear_owner(p->mm, p);
2560: mmput(p->mm);
2561: }
2562: bad_fork_cleanup_signal:
2563: if (!(clone_flags & CLONE_THREAD))
2564: free_signal_struct(p->signal);
2565: bad_fork_cleanup_sighand:
2566: __cleanup_sighand(p->sighand);
2567: bad_fork_cleanup_fs:
2568: exit_fs(p); /* blocking */
2569: bad_fork_cleanup_files:
2570: exit_files(p); /* blocking */
2571: bad_fork_cleanup_semundo:
2572: exit_sem(p);
2573: bad_fork_cleanup_security:
2574: security_task_free(p);
2575: bad_fork_cleanup_audit:
2576: audit_free(p);
2577: bad_fork_cleanup_perf:
2578: perf_event_free_task(p);
2579: bad_fork_sched_cancel_fork:
2580: sched_cancel_fork(p);
2581: bad_fork_cleanup_policy:
2582: lockdep_free_task(p);
2583: #ifdef CONFIG_NUMA
2584: mpol_put(p->mempolicy);
2585: #endif
2586: bad_fork_cleanup_delayacct:
2587: io_uring_free(p);
2588: delayacct_tsk_free(p);
2589: bad_fork_cleanup_count:
2590: dec_rlimit_ucounts(task_ucounts(p), UCOUNT_RLIMIT_NPROC, 1);
2591: exit_cred_namespaces(p);
2592: exit_creds(p);
2593: bad_fork_free:
2594: WRITE_ONCE(p->__state, TASK_DEAD);
2595: exit_task_stack_account(p);
2596: put_task_stack(p);
2597: delayed_free_task(p);
2598: fork_out:
2599: spin_lock_irq(¤t->sighand->siglock);
2600: hlist_del_init(&delayed.node);
2601: spin_unlock_irq(¤t->sighand->siglock);
2602: return ERR_PTR(retval);
2603: }
SourceFile:kernel/fork.c]
|
| 110/2 |
2026/06/12 22:32 |
llm |
expert |
0m
Model:
Tokens:
input: 210384
output: 38
thoughts: 103
Thoughts: **Analyzing the `copy_process` Function**
Okay, so I'm looking at `copy_process` and immediately see something interesting related to `io_uring`. It appears that if `CONFIG_IO_URING` is defined, which implies IO_URING support is compiled into the kernel, the code initializes `p->io_uring` to `NULL` and then calls `io_uring_fork(p)`. The return value of that call is then checked, and if it's unsuccessful, it jumps to `bad_fork_cleanup_delayacct`. Right, and a return value of `-EAGAIN` is then set. That's odd.
My immediate question is, what's happening within `io_uring_fork`? I need to understand what's going on within that function call to fully grasp the significance of this section of code and its error handling. Let's dive into the implementation of `io_uring_fork` to understand its behavior and why `-EAGAIN` might be returned.
|
| 111/2 |
2026/06/12 22:32 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_uring_fork]
Results: map[SourceCode: 32: static inline int io_uring_fork(struct task_struct *tsk)
33: {
34: if (tsk->io_uring_restrict)
35: return __io_uring_fork(tsk);
36:
37: return 0;
38: }
SourceFile:include/linux/io_uring.h]
|
| 112/2 |
2026/06/12 22:32 |
llm |
expert |
0m
Model:
Tokens:
input: 210860
output: 40
thoughts: 888
Thoughts: **Analyzing a Potential File Descriptor Leak**
Okay, first things first, let's break down this `io_uring` and file descriptor situation. It looks like `io_uring_fork` is only relevant if `tsk->io_uring_restrict` is set, and it *doesn't* copy the current context (`tctx`). So, the child process gets a `NULL` `io_uring` context. Therefore, the child *doesn't* inherit the registered rings. This means the child *can't* use that registered ring file descriptor. If the child can't use it, the registered ring FD is solely accessible to the parent.
But what happens if the parent exits? Then `io_uring_unreg_ringfd` gets called, and the ring FD is cleaned up with `fput`. Since the child doesn't have a reference, the FD is freed. So, there shouldn't be a leak *there*.
Alright, so if it's not `io_uring` directly, where *is* the leak? Let's go back to the syzbot report and re-evaluate the clues. The stack trace shows the leak happening during an `openat` call, specifically `/dev/vbi3`, and a `sendmsg` operation on a netlink socket. The netlink message configures a TC filter – a 'basic' filter with actions like `pedit`, `police`, `ct`, and `gact`.
My initial thought was maybe the `sendmsg` payload contains a file descriptor, maybe a `TCA_POLICE_RATE64` thing? But TC filters *don't* take file descriptors, do they? Then, could the payload be *something other* than a TC filter? The comment says it's `netlink_msg_route_sched`. Could this be a BPF-related leak? But the reproducer doesn't seem to have any BPF involved.
Now, a completely different tack: could `io_uring`'s `IORING_OP_WRITEV` on `/dev/vbi3` be the culprit? If that operation blocks, the io_uring worker thread might block too. `io_uring_cancel_generic` will wait, but does it *really* wait for it to finish? Wait, doesn't it wait for `tctx_inflight` to reach zero? Now, if the request is blocking forever, it would hang in `io_uring_cancel_generic`, but syzbot reports a memory leak, not a hung task! That means `io_uring_cancel_generic` *did* complete! If it completed, the request must have also completed. If it completed, it must have released the file reference... so the file reference should be 0. So why is there a leak? Is it possible that `io_req_set_file` takes a reference, but `io_req_complete_post` *doesn't* release it? This is worth digging into. I need to check `io_req_complete_post`.
|
| 113/2 |
2026/06/12 22:32 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_req_complete_post]
Results: map[SourceCode: 918: static void io_req_complete_post(struct io_kiocb *req, unsigned issue_flags)
919: {
920: struct io_ring_ctx *ctx = req->ctx;
921: bool completed = true;
922:
923: /*
924: * All execution paths but io-wq use the deferred completions by
925: * passing IO_URING_F_COMPLETE_DEFER and thus should not end up here.
926: */
927: if (WARN_ON_ONCE(!(issue_flags & IO_URING_F_IOWQ)))
928: return;
929:
930: /*
931: * Handle special CQ sync cases via task_work. DEFER_TASKRUN requires
932: * the submitter task context, IOPOLL protects with uring_lock.
933: */
934: if ((ctx->int_flags & IO_RING_F_LOCKLESS_CQ) || (req->flags & REQ_F_REISSUE)) {
935: defer_complete:
936: req->io_task_work.func = io_req_task_complete;
937: io_req_task_work_add(req);
938: return;
939: }
940:
941: io_cq_lock(ctx);
942: if (!(req->flags & REQ_F_CQE_SKIP))
943: completed = io_fill_cqe_req(ctx, req);
944: io_cq_unlock_post(ctx);
945:
946: if (!completed)
947: goto defer_complete;
948:
949: /*
950: * We don't free the request here because we know it's called from
951: * io-wq only, which holds a reference, so it cannot be the last put.
952: */
953: req_ref_put(req);
954: }
SourceFile:io_uring/io_uring.c]
|
| 114/2 |
2026/06/12 22:32 |
llm |
expert |
0m
Model:
Tokens:
input: 213051
output: 34
thoughts: 1199
Thoughts: **Analyzing a Potential File Descriptor Leak**
Okay, first things first, let's nail down what's happening with these request structures. Wait, I see it now: `io_req_complete_post` *doesn't* free the request directly! It just decrements the reference count with `req_ref_put(req)`. The actual freeing occurs when the reference count drops to zero. Got it. Now, `io_req_task_complete`... ah, that’s the one that eventually calls `io_req_complete_defer`. And *that's* the function that actually handles the cleanup, calling `io_req_put_rsrc` and then `io_req_free`. Right, `io_req_put_rsrc` then puts the file, using `io_req_fput`, and frees the request.
So, if `io_req_complete_post` is called, but the request isn't immediately freed because something else holds a reference (like `io-wq`), there's no leak. `io-wq` eventually finishes with the request, puts its reference, and *then* the request is freed, along with the file. Good, that eliminates a possible source of the leak!
Hmm, let's back up. If it's not `io_uring`, where *is* it? Time to revisit the reproducer code. Okay, let's see. This `mmap` call... I recognize this, but this is a red herring. It's mapping memory, then we have `prctl(PR_SET_MM_MAP)`. *That* call sets the memory map boundaries and could be interesting... Could `prctl(PR_SET_MM_MAP)` possibly leak a file? But wait, the reproducer sets `exe_fd = -1`, so `prctl_set_mm_exe_file` is *not* called. No file leak there, either.
Okay, let's pivot. What about the sequence of events? Could opening `/dev/vbi3` with `syz_open_dev`, then sending a netlink message to trigger a module load, cause it? Maybe, but the syzbot report lists `comm "syz.0.19"`. That means the leak is happening within the `syz.0.19` process, and that makes it unlikely to be a side effect.
Hold on... Could the sockets themselves be the issue? The reproducer code has a `socket` call. Let's look:
```c
syscall(__NR_socket, /*domain=*/0x10ul, /*type=*/3ul, /*proto=*/0x10);
syscall(__NR_socket, /*domain=AF_INET*/2ul, /*type=SOCK_RAW*/3ul, /*proto=*/0x67);
```
These are sockets. Sockets are created by `sock_alloc_file`, which calls `alloc_file_pseudo`, which in turn calls `alloc_empty_file`. Aha! `sock_alloc_file` calls `alloc_file_pseudo`. I think we're onto something. Let's dig deeper into the code of `sock_alloc_file`.
|
| 115/2 |
2026/06/12 22:32 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:net/socket.c Name:sock_alloc_file]
Results: map[SourceCode: 536: struct file *sock_alloc_file(struct socket *sock, int flags, const char *dname)
537: {
538: struct file *file;
539:
540: if (!dname)
541: dname = sock->sk ? sock->sk->sk_prot_creator->name : "";
542:
543: file = alloc_file_pseudo(SOCK_INODE(sock), sock_mnt, dname,
544: O_RDWR | (flags & O_NONBLOCK),
545: &socket_file_ops);
546: if (IS_ERR(file)) {
547: sock_release(sock);
548: return file;
549: }
550:
551: file->f_mode |= FMODE_NOWAIT;
552: sock->file = file;
553: file->private_data = sock;
554: stream_open(SOCK_INODE(sock), file);
555: /*
556: * Disable permission and pre-content events, but enable legacy
557: * inotify events for legacy users.
558: */
559: file_set_fsnotify_mode(file, FMODE_NONOTIFY_PERM);
560: return file;
561: }
SourceFile:net/socket.c]
|
| 116/2 |
2026/06/12 22:32 |
llm |
expert |
0m
Model:
Tokens:
input: 215399
output: 36
thoughts: 4272
Thoughts: **Analyzing a Potential File Descriptor Leak in the Kernel**
Okay, so I'm digging into this syzbot report, and the backtrace points towards a file descriptor leak originating from `path_openat`. However, I know `sock_alloc_file` doesn't call `path_openat`, which is a key observation. That leak must be tied to a call to `openat`, which then leads me to `syz_open_dev` and the `/dev/vbi3` device.
My mind immediately jumps to the io_uring subsystem, thinking maybe there's a sneaky `IORING_OP_OPENAT` or `IORING_OP_OPENAT2` operation being used. I quickly check the `sendmsg` payload for those opcodes (18 and 28). No luck; they're nowhere to be found. So, it appears the leak *is* coming directly from the open call to `/dev/vbi3`.
Now, is this a problem with the `vivid` driver? I know that `/dev/vbiX` is accessible to unprivileged users, and the syzkaller setup does load the driver. My working hypothesis at this point is that the `vivid` driver is responsible.
I go through the potential edge cases in io_uring to be sure it's not the root cause, but everything looks correct there. `io_uring_unreg_ringfd` does `fput`, and it looks like the registered ring is cleared as well. I consider how `execve` might play a role, but that scenario looks like it would cancel and release file descriptors.
I'm now hunting for any potential io_uring flaws specifically related to `IORING_SETUP_REGISTERED_FD_ONLY`. I review how the system handles `-EBUSY` when adding a registered file. That should be safe because the fput is called. Similarly, I check the failure cases related to `copy_to_user` and other errors, but those handle the file descriptor release properly.
Then it hits me! I'm seeing a possible flaw within `io_uring_ctx_get_file`. If a file descriptor is registered via `IORING_ENTER_REGISTERED_RING`, then the reference count for the file is *not* incremented and then potentially lost. If an io_uring request references a registered FD, there is no corresponding `fput` in `io_uring_enter`. The code *should* be balanced, but the `fput` in the non-registered case is not applied in this other scenario.
I'm thinking, okay, let's say `io_uring_enter` uses `fd = 3`, and the operation is `IORING_OP_WRITEV` on `/dev/vbi3`. The request is set up, queued, and then the process exits. `do_exit` will call `io_uring_files_cancel()`. That looks safe, because it cancels everything, but wait... is it? What if those file requests aren't *fully* cleaned up?
I need to understand what triggers the file to be freed. Looking at the logic in `io_uring_cancel_generic`, the code *should* wait for requests to finish, but I need to see if the requests are actually *counted* in `tctx_inflight`. That's where I need to focus my attention. It could be that the request isn't counted correctly there, which is what's letting that reference to `/dev/vbi3` leak out.
|
| 117/2 |
2026/06/12 22:33 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/cancel.c Name:tctx_inflight]
Results: map[SourceCode: 573: static s64 tctx_inflight(struct io_uring_task *tctx, bool tracked)
574: {
575: if (tracked)
576: return atomic_read(&tctx->inflight_tracked);
577: return percpu_counter_sum(&tctx->inflight);
578: }
SourceFile:io_uring/cancel.c]
|
| 118/2 |
2026/06/12 22:33 |
llm |
expert |
0m
Model:
Tokens:
input: 220595
output: 41
thoughts: 50
Thoughts: Okay, let me think this through.
**Analyzing the Inflight Counter**
Hmm, so `tctx_inflight` gives me the sum of `tctx->inflight`, which is a per-CPU counter. That's good, I can get a total inflight count. But... when exactly is that `tctx->inflight` value being *incremented*? I need to know the origin of the counter updates to fully understand the flow. Ah, right, I remember! It's in `io_req_track_inflight`. Okay, that makes sense. Now I can start to understand the complete picture of how this inflight tracking works.
|
| 119/2 |
2026/06/12 22:33 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_req_track_inflight]
Results: map[SourceCode: 331: /*
332: * Mark the request as inflight, so that file cancelation will find it.
333: * Can be used if the file is an io_uring instance, or if the request itself
334: * relies on ->mm being alive for the duration of the request.
335: */
336: inline void io_req_track_inflight(struct io_kiocb *req)
337: {
338: if (!(req->flags & REQ_F_INFLIGHT)) {
339: req->flags |= REQ_F_INFLIGHT;
340: atomic_inc(&req->tctx->inflight_tracked);
341: }
342: }
SourceFile:io_uring/io_uring.c]
|
| 120/2 |
2026/06/12 22:33 |
llm |
expert-compressor |
3m
Model:
Reply: Here is a comprehensive summary of the current state of the workspace and the investigation:
### 1. Approaches Tried & Results
- **`io_uring` Ring File Registration Analysis (Likely Dead-End):** The reproducer calls `io_uring_setup` with `IORING_SETUP_REGISTERED_FD_ONLY`, which registers the ring file directly into the task's `tctx->registered_rings` array instead of the normal fd table. The AI extensively traced the creation (`io_uring_create`, `io_ring_add_registered_file`) and cleanup (`io_uring_unreg_ringfd`, `__io_uring_cancel`, `do_exit`) of these registered files. The cleanup paths correctly call `fput()` on all registered ring files when the task exits.
- **File Allocation Path Verification:** The AI traced `io_uring_get_file` and confirmed it uses `anon_inode_create_getfile`. This is a critical finding because the bug report's memory leak backtrace explicitly shows `alloc_empty_file` being called from `path_openat`. This proves the leaked file is a path-based file (like `/dev/vbi#`), NOT an anonymous inode (like `io_uring` or `socket`).
- **V4L2 Device Open/Release Analysis:** Since the reproducer explicitly opens `/dev/vbi#` (a Video4Linux device), the AI examined `v4l2_open` and `v4l2_release`. It verified that `v4l2_open` delegates to the driver's `fops->open` and handles errors by dropping the `video_device` refcount. No obvious `struct file` refcount leaks were found in the generic V4L2 layer yet.
- **Other Reproducer Syscalls:** The AI briefly checked `prctl(PR_SET_MM_MAP)` (which can manipulate `exe_fd`, but the reproducer passes `-1`) and `sendmsg` paths, finding no immediate evidence of file descriptor leaks.
### 2. Current Hypotheses & Active Lines of Investigation
- **Hypothesis 1: The leak is in the V4L2/vivid subsystem.** Since the leaked file is opened via `path_openat`, it is almost certainly the `/dev/vbi#` device opened by the reproducer. The investigation needs to focus on whether the specific V4L2 driver (likely `vivid`, commonly used by syzkaller) takes an extra reference to the `struct file` during open/ioctl/mmap and fails to release it.
- **Hypothesis 2: `io_uring` leaks a registered target file.** While the ring file itself isn't leaking, the AI might need to investigate if the `/dev/vbi#` file descriptor is being passed to `io_uring` (e.g., via fixed files or SQEs) and leaked there. However, the reproducer's `io_uring_setup` likely fails with `-EFAULT` anyway because `IORING_SETUP_NO_MMAP` is set but `user_addr` is `0`.
- **Hypothesis 3: Netlink/TC action leak.** The reproducer sends a complex netlink message configuring traffic control (`tc`) actions (`pedit`, `police`, `ct`, `gact`). While TC actions don't typically hold file references, it remains a background possibility if the V4L2 hypothesis falls through.
### 3. Critical Code Snippets & Details to Remember
- **Bug Report Backtrace:**
```c
alloc_empty_file+0x57/0x180 fs/file_table.c:262
path_openat+0x44/0x1e20 fs/namei.c:4844
```
*(Remember: This guarantees the leak is a path-based file, ruling out anonymous inodes).*
- **io_uring Cleanup Path:**
```c
void io_uring_unreg_ringfd(void) {
for (i = 0; i < IO_RINGFD_REG_MAX; i++) {
if (tctx->registered_rings[i]) {
fput(tctx->registered_rings[i]);
tctx->registered_rings[i] = NULL;
}
}
}
```
- **V4L2 Open Hook (`drivers/media/v4l2-core/v4l2-dev.c`):**
```c
static int v4l2_open(struct inode *inode, struct file *filp) {
// ...
ret = vdev->fops->open(filp);
// ...
}
```
### 4. Potential Reasoning Loops & Dead-Ends
- **Repetitive focus on `io_uring` ring file leaks:** The AI spent a lot of time analyzing `IORING_SETUP_REGISTERED_FD_ONLY` and `io_uring_task_cancel`. **This is a dead-end.** The backtrace (`path_openat`) definitively proves the leaked object is not the `io_uring` ring file. The investigation MUST pivot away from `io_uring` ring file lifecycle and focus on how a standard file opened via `path_openat` (specifically `/dev/vbi#`) can have its refcount elevated and leaked.
Tokens:
input: 156006
output: 1189
thoughts: 23472
|
| 121/2 |
2026/06/12 22:36 |
llm |
expert |
0m
Model:
Tokens:
input: 67803
output: 22
thoughts: 874
Thoughts: **Analyzing a Memory Leak with io_uring Setup**
Okay, so I'm looking at a potential memory leak involving `struct file` instances, specifically those allocated within `alloc_empty_file` from `path_openat`. The reproducer is interesting, it uses a sequence of system calls that I'll need to dissect. It starts with an `mmap`, then creates three sockets: a `NETLINK_ROUTE`, an `INET`, and then makes a `prctl` call. The interesting part is `PR_SET_MM_MAP` with `exe_fd = -1`, followed by a `sendmsg` on that same invalid file descriptor; that's unusual, and probably the key to this. Now we have the `io_uring_setup` call.
I'm seeing `IORING_SETUP_REGISTERED_FD_ONLY`, `IORING_SETUP_NO_MMAP`, `IORING_SETUP_SQPOLL` and `IORING_SETUP_CQSIZE` flags. Let me break down these flags. The setup call's `flags` is `0x1c080`, and that needs a closer look. *Wait*, something's off here. `IORING_SETUP_REGISTERED_FD_ONLY` is `1U << 16` (0x10000), `IORING_SETUP_NO_MMAP` is `1U << 15` (0x8000), and `IORING_SETUP_SQPOLL` is `1U << 1` (0x2). However, `0x1c080` seems to be `0x10000 | 0x8000 | 0x4000 | 0x80`. That means the `flags` value is inconsistent with the explicit flags mentioned.
Let me refresh my memory on these `io_uring_setup_flags`: `IORING_SETUP_IOPOLL`, `IORING_SETUP_SQPOLL`, `IORING_SETUP_SQ_AFF`, `IORING_SETUP_CQSIZE`, `IORING_SETUP_CLAMP`, `IORING_SETUP_ATTACH_WQ`, `IORING_SETUP_R_DISABLED`, `IORING_SETUP_SUBMIT_ALL`, `IORING_SETUP_COOP_TASKRUN`, `IORING_SETUP_TASKRUN_FLAG`, `IORING_SETUP_SQE128`, `IORING_SETUP_CQE32`, `IORING_SETUP_SINGLE_ISSUER`, `IORING_SETUP_DEFER_TASKRUN`, `IORING_SETUP_NO_MMAP`, `IORING_SETUP_REGISTERED_FD_ONLY`, `IORING_SETUP_NO_SQARRAY`.
Okay, so `0x1c080` decodes to `IORING_SETUP_NO_SQARRAY`, `IORING_SETUP_REGISTERED_FD_ONLY`, `IORING_SETUP_NO_MMAP`, and `IORING_SETUP_SUBMIT_ALL`. So the flags are indeed 0x10000 | 0x8000 | 0x4000 | 0x80. Now, I have to make sure that the mapping for `IORING_SETUP_REGISTERED_FD_ONLY` is correctly set to 0x10000. Something is not adding up...let me verify.
|
| 122/2 |
2026/06/12 22:36 |
tool |
grepper |
0m
Args: map[Expression:#define IORING_SETUP_]
Results: map[Output:include/uapi/linux/io_uring.h=143=enum io_uring_sqe_flags_bit {
--
include/uapi/linux/io_uring.h-173- */
include/uapi/linux/io_uring.h:174:#define IORING_SETUP_IOPOLL (1U << 0) /* io_context is polled */
include/uapi/linux/io_uring.h:175:#define IORING_SETUP_SQPOLL (1U << 1) /* SQ poll thread */
include/uapi/linux/io_uring.h:176:#define IORING_SETUP_SQ_AFF (1U << 2) /* sq_thread_cpu is valid */
include/uapi/linux/io_uring.h:177:#define IORING_SETUP_CQSIZE (1U << 3) /* app defines CQ size */
include/uapi/linux/io_uring.h:178:#define IORING_SETUP_CLAMP (1U << 4) /* clamp SQ/CQ ring sizes */
include/uapi/linux/io_uring.h:179:#define IORING_SETUP_ATTACH_WQ (1U << 5) /* attach to existing wq */
include/uapi/linux/io_uring.h:180:#define IORING_SETUP_R_DISABLED (1U << 6) /* start with ring disabled */
include/uapi/linux/io_uring.h:181:#define IORING_SETUP_SUBMIT_ALL (1U << 7) /* continue submit on error */
include/uapi/linux/io_uring.h-182-/*
--
include/uapi/linux/io_uring.h-188- */
include/uapi/linux/io_uring.h:189:#define IORING_SETUP_COOP_TASKRUN (1U << 8)
include/uapi/linux/io_uring.h-190-/*
--
include/uapi/linux/io_uring.h-195- */
include/uapi/linux/io_uring.h:196:#define IORING_SETUP_TASKRUN_FLAG (1U << 9)
include/uapi/linux/io_uring.h:197:#define IORING_SETUP_SQE128 (1U << 10) /* SQEs are 128 byte */
include/uapi/linux/io_uring.h:198:#define IORING_SETUP_CQE32 (1U << 11) /* CQEs are 32 byte */
include/uapi/linux/io_uring.h-199-/*
--
include/uapi/linux/io_uring.h-201- */
include/uapi/linux/io_uring.h:202:#define IORING_SETUP_SINGLE_ISSUER (1U << 12)
include/uapi/linux/io_uring.h-203-
--
include/uapi/linux/io_uring.h-208- */
include/uapi/linux/io_uring.h:209:#define IORING_SETUP_DEFER_TASKRUN (1U << 13)
include/uapi/linux/io_uring.h-210-
--
include/uapi/linux/io_uring.h-213- */
include/uapi/linux/io_uring.h:214:#define IORING_SETUP_NO_MMAP (1U << 14)
include/uapi/linux/io_uring.h-215-
--
include/uapi/linux/io_uring.h-220- */
include/uapi/linux/io_uring.h:221:#define IORING_SETUP_REGISTERED_FD_ONLY (1U << 15)
include/uapi/linux/io_uring.h-222-
--
include/uapi/linux/io_uring.h-225- */
include/uapi/linux/io_uring.h:226:#define IORING_SETUP_NO_SQARRAY (1U << 16)
include/uapi/linux/io_uring.h-227-
include/uapi/linux/io_uring.h-228-/* Use hybrid poll in iopoll process */
include/uapi/linux/io_uring.h:229:#define IORING_SETUP_HYBRID_IOPOLL (1U << 17)
include/uapi/linux/io_uring.h-230-
--
include/uapi/linux/io_uring.h-234- */
include/uapi/linux/io_uring.h:235:#define IORING_SETUP_CQE_MIXED (1U << 18)
include/uapi/linux/io_uring.h-236-
--
include/uapi/linux/io_uring.h-240- */
include/uapi/linux/io_uring.h:241:#define IORING_SETUP_SQE_MIXED (1U << 19)
include/uapi/linux/io_uring.h-242-
--
include/uapi/linux/io_uring.h-252- */
include/uapi/linux/io_uring.h:253:#define IORING_SETUP_SQ_REWIND (1U << 20)
include/uapi/linux/io_uring.h-254-
--
io_uring/io_uring.h=29=struct io_ctx_config {
--
io_uring/io_uring.h-53-
io_uring/io_uring.h:54:#define IORING_SETUP_FLAGS (IORING_SETUP_IOPOLL |\
io_uring/io_uring.h-55- IORING_SETUP_SQPOLL |\
--
tools/include/uapi/linux/io_uring.h=117=enum {
--
tools/include/uapi/linux/io_uring.h-147- */
tools/include/uapi/linux/io_uring.h:148:#define IORING_SETUP_IOPOLL (1U << 0) /* io_context is polled */
tools/include/uapi/linux/io_uring.h:149:#define IORING_SETUP_SQPOLL (1U << 1) /* SQ poll thread */
tools/include/uapi/linux/io_uring.h:150:#define IORING_SETUP_SQ_AFF (1U << 2) /* sq_thread_cpu is valid */
tools/include/uapi/linux/io_uring.h:151:#define IORING_SETUP_CQSIZE (1U << 3) /* app defines CQ size */
tools/include/uapi/linux/io_uring.h:152:#define IORING_SETUP_CLAMP (1U << 4) /* clamp SQ/CQ ring sizes */
tools/include/uapi/linux/io_uring.h:153:#define IORING_SETUP_ATTACH_WQ (1U << 5) /* attach to existing wq */
tools/include/uapi/linux/io_uring.h:154:#define IORING_SETUP_R_DISABLED (1U << 6) /* start with ring disabled */
tools/include/uapi/linux/io_uring.h:155:#define IORING_SETUP_SUBMIT_ALL (1U << 7) /* continue submit on error */
tools/include/uapi/linux/io_uring.h-156-/*
--
tools/include/uapi/linux/io_uring.h-162- */
tools/include/uapi/linux/io_uring.h:163:#define IORING_SETUP_COOP_TASKRUN (1U << 8)
tools/include/uapi/linux/io_uring.h-164-/*
--
tools/include/uapi/linux/io_uring.h-168- */
tools/include/uapi/linux/io_uring.h:169:#define IORING_SETUP_TASKRUN_FLAG (1U << 9)
tools/include/uapi/linux/io_uring.h:170:#define IORING_SETUP_SQE128 (1U << 10) /* SQEs are 128 byte */
tools/include/uapi/linux/io_uring.h:171:#define IORING_SETUP_CQE32 (1U << 11) /* CQEs are 32 byte */
tools/include/uapi/linux/io_uring.h-172-/*
--
tools/include/uapi/linux/io_uring.h-174- */
tools/include/uapi/linux/io_uring.h:175:#define IORING_SETUP_SINGLE_ISSUER (1U << 12)
tools/include/uapi/linux/io_uring.h-176-
--
tools/include/uapi/linux/io_uring.h-181- */
tools/include/uapi/linux/io_uring.h:182:#define IORING_SETUP_DEFER_TASKRUN (1U << 13)
tools/include/uapi/linux/io_uring.h-183-
--
tools/include/uapi/linux/io_uring.h-186- */
tools/include/uapi/linux/io_uring.h:187:#define IORING_SETUP_NO_MMAP (1U << 14)
tools/include/uapi/linux/io_uring.h-188-
--
tools/include/uapi/linux/io_uring.h-193- */
tools/include/uapi/linux/io_uring.h:194:#define IORING_SETUP_REGISTERED_FD_ONLY (1U << 15)
tools/include/uapi/linux/io_uring.h-195-
--
tools/include/uapi/linux/io_uring.h-198- */
tools/include/uapi/linux/io_uring.h:199:#define IORING_SETUP_NO_SQARRAY (1U << 16)
tools/include/uapi/linux/io_uring.h-200-
]
|
| 123/2 |
2026/06/12 22:36 |
llm |
expert |
0m
Model:
Tokens:
input: 72045
output: 23
thoughts: 842
Thoughts: **Analyzing a Potential File Descriptor Leak in an io_uring Context**
Okay, let's break this down. First, I see the `IORING_SETUP_REGISTERED_FD_ONLY` flag, which is equivalent to `0x8000`. Now, I'm looking at these `flags = 0x1c080`. That's `0x10000 | 0x8000 | 0x4000 | 0x80`. Right, `0x10000` is `IORING_SETUP_NO_SQARRAY`, `0x8000` is `IORING_SETUP_REGISTERED_FD_ONLY`, `0x4000` is `IORING_SETUP_NO_MMAP`, and `0x80` is `IORING_SETUP_SUBMIT_ALL`. So the setup registers the ring as a file descriptor.
Then, `syz_open_dev` opens `/dev/vbi#` which becomes something like `/dev/vbi3`, and immediately after a `sendmsg` fails on `fd=-1`. Following that, `io_uring_enter` is called with the registered fd (from the ring creation), a large `to_submit` value, a substantial `min_complete`, some `flags = 0x16` (`IORING_ENTER_REGISTERED_RING | IORING_ENTER_SQ_WAIT | IORING_ENTER_SQ_WAKEUP`), and a gigantic `size=0xffffffffffffff02`.
My attention is drawn to the memory leak, which is a `struct file` allocated by `alloc_empty_file` from `path_openat`. The only `path_openat` in the trace is in the `syz_open_dev` call. So, I'm thinking the leaked file *is* `/dev/vbi3`.
Why is this file being leaked? Does `syz_open_dev` return the fd, and then the program exits? When a program exits, all the open file descriptors should be automatically closed. So if there's a leak, it means the refcount of the file wasn't decremented. Could `io_uring_enter` be messing with the `/dev/vbi3` fd somehow? That's what I need to understand.
Wait, `io_uring_enter` *processes* SQEs (Submission Queue Entries). But the reproducer doesn't seem to write any SQEs!
Ah, right! `IORING_SETUP_NO_MMAP` means the ring isn't mmapped. Instead, the user provides the memory for the rings via `user_addr` in `io_uring_params`. Okay, so let's look at what's provided:
```c
*(uint32_t*)0x200000000044 = 0x3cb1; // cq_entries
*(uint32_t*)0x200000000048 = 0x1c080; // flags
*(uint32_t*)0x20000000004c = 0xa; // sq_thread_cpu
*(uint32_t*)0x200000000050 = 0x20002f7; // sq_thread_idle
*(uint32_t*)0x200000000058 = -1; // wq_fd
memset((void*)0x20000000005c, 0, 12); // resv
```
Now, where is `user_addr` in relation to all of this? I'm getting a little turned around; I thought it was at `0x80` offset? No, `sq_off.user_addr` is at `0x28` inside `sq_off`. I need to review the `io_uring_params` structure layout. Let's start there.
|
| 124/2 |
2026/06/12 22:36 |
tool |
codesearch-struct-layout |
0m
Args: map[Name:io_uring_params]
Results: map[Fields:[map[Name:sq_entries OffsetBits:0 SizeBits:32] map[Name:cq_entries OffsetBits:32 SizeBits:32] map[Name:flags OffsetBits:64 SizeBits:32] map[Name:sq_thread_cpu OffsetBits:96 SizeBits:32] map[Name:sq_thread_idle OffsetBits:128 SizeBits:32] map[Name:features OffsetBits:160 SizeBits:32] map[Name:wq_fd OffsetBits:192 SizeBits:32] map[Name:resv OffsetBits:224 SizeBits:96] map[Name:sq_off OffsetBits:320 SizeBits:320] map[Name:cq_off OffsetBits:640 SizeBits:320]]]
|
| 125/2 |
2026/06/12 22:36 |
llm |
expert |
0m
Model:
Tokens:
input: 74037
output: 24
thoughts: 358
Thoughts: **Analyzing Memory Offsets and the Reproducer**
Okay, let's break this down. First, I see that `sq_off` is located 320 bits, or 40 bytes, into the structure. And `cq_off` is at 640 bits, or 80 bytes. That's a key starting point.
Now, looking at the reproducer, it seems to be writing to specific offsets within a memory region starting at `0x200000000040`. Specifically, I can see assignments to `cq_entries`, `flags`, `sq_thread_cpu`, `sq_thread_idle`, and `wq_fd`, plus a `memset` for some reserved space, all at the addresses described.
Hmm, this is interesting... It seems like `user_addr` is located within both the `sq_off` and `cq_off` structures. My immediate thought is to determine the exact offset for `sq_off.user_addr`, which seems critical for understanding the vulnerability. I'm assuming that it is 40 (sq_off) + 24 (offset, but I'll double check) = 64. I should verify this by consulting the `io_sqring_offsets` structure definition immediately. Gotta be sure.
|
| 126/2 |
2026/06/12 22:37 |
tool |
codesearch-struct-layout |
0m
Args: map[Name:io_sqring_offsets]
Results: map[Fields:[map[Name:head OffsetBits:0 SizeBits:32] map[Name:tail OffsetBits:32 SizeBits:32] map[Name:ring_mask OffsetBits:64 SizeBits:32] map[Name:ring_entries OffsetBits:96 SizeBits:32] map[Name:flags OffsetBits:128 SizeBits:32] map[Name:dropped OffsetBits:160 SizeBits:32] map[Name:array OffsetBits:192 SizeBits:32] map[Name:resv1 OffsetBits:224 SizeBits:32] map[Name:user_addr OffsetBits:256 SizeBits:64]]]
|
| 127/2 |
2026/06/12 22:37 |
llm |
expert |
0m
Model:
Tokens:
input: 74891
output: 38
thoughts: 119
Thoughts: **Analyzing Potential io_uring Setup Failure**
Okay, so `user_addr` is located 32 bytes into `sq_off`, and `sq_off` itself starts at offset 40 bytes. That means `sq_off.user_addr` begins at byte 72. Crucially, the reproducer code doesn't initialize `user_addr`. Therefore, it's set to zero. Given that, I suspect that calling `io_uring_setup` with `IORING_SETUP_NO_MMAP` and a `user_addr` of zero is very likely going to lead to an error, probably either `-EFAULT` or `-EINVAL`. Time to dive into the `io_uring_setup` implementation itself to verify this hypothesis. I need to understand exactly how the kernel handles this scenario.
|
| 128/2 |
2026/06/12 22:37 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_uring_setup]
Results: map[SourceCode:3106: /*
3107: * Sets up an aio uring context, and returns the fd. Applications asks for a
3108: * ring size, we return the actual sq/cq ring sizes (among other things) in the
3109: * params structure passed in.
3110: */
3111: static long io_uring_setup(u32 entries, struct io_uring_params __user *params)
3112: {
3113: struct io_ctx_config config;
3114:
3115: memset(&config, 0, sizeof(config));
3116:
3117: if (copy_from_user(&config.p, params, sizeof(config.p)))
3118: return -EFAULT;
3119:
3120: if (!mem_is_zero(&config.p.resv, sizeof(config.p.resv)))
3121: return -EINVAL;
3122:
3123: config.p.sq_entries = entries;
3124: config.uptr = params;
3125: return io_uring_create(&config);
3126: }
SourceFile:io_uring/io_uring.c]
|
| 129/2 |
2026/06/12 22:37 |
llm |
expert |
0m
Model:
Tokens:
input: 75575
output: 38
thoughts: 11
Thoughts: Okay, here's my attempt at summarizing that thought process, keeping in mind I'm speaking to a fellow expert:
**Diving into `io_uring_create`**
Alright, time to dig into this. First thing's first: let's get a handle on `io_uring_create`. This is where it all begins, the cornerstone function, the primordial soup if you will. I'm going to run through its internals, focusing on the ring buffer setup, shared memory mapping, and any potential gotchas with resource allocation, security implications and performance optimization. I want to see if there's anything I've overlooked in my current implementation that this function might illuminate. Are there any clever tricks I can borrow? Any known issues with specific kernel versions I should be mindful of? Let's get cracking, let's explore this core function and find out what secrets it holds.
|
| 130/2 |
2026/06/12 22:37 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_uring_create]
Results: map[SourceCode:2978: static __cold int io_uring_create(struct io_ctx_config *config)
2979: {
2980: struct io_uring_params *p = &config->p;
2981: struct io_ring_ctx *ctx;
2982: struct io_uring_task *tctx;
2983: struct file *file;
2984: int ret;
2985:
2986: ret = io_prepare_config(config);
2987: if (ret)
2988: return ret;
2989:
2990: ctx = io_ring_ctx_alloc(p);
2991: if (!ctx)
2992: return -ENOMEM;
2993:
2994: ctx->clockid = CLOCK_MONOTONIC;
2995: ctx->clock_offset = 0;
2996:
2997: if (!(ctx->flags & IORING_SETUP_NO_SQARRAY))
2998: static_branch_deferred_inc(&io_key_has_sqarray);
2999:
3000: if ((ctx->flags & IORING_SETUP_DEFER_TASKRUN) &&
3001: !(ctx->flags & IORING_SETUP_IOPOLL))
3002: ctx->int_flags |= IO_RING_F_TASK_COMPLETE;
3003:
3004: if ((ctx->int_flags & IO_RING_F_TASK_COMPLETE) ||
3005: (ctx->flags & IORING_SETUP_IOPOLL))
3006: ctx->int_flags |= IO_RING_F_LOCKLESS_CQ;
3007:
3008: /*
3009: * lazy poll_wq activation relies on ->task_complete for synchronisation
3010: * purposes, see io_activate_pollwq()
3011: */
3012: if (!(ctx->int_flags & IO_RING_F_TASK_COMPLETE))
3013: ctx->int_flags |= IO_RING_F_POLL_ACTIVATED;
3014:
3015: /*
3016: * When SETUP_IOPOLL and SETUP_SQPOLL are both enabled, user
3017: * space applications don't need to do io completion events
3018: * polling again, they can rely on io_sq_thread to do polling
3019: * work, which can reduce cpu usage and uring_lock contention.
3020: */
3021: if (ctx->flags & IORING_SETUP_IOPOLL &&
3022: !(ctx->flags & IORING_SETUP_SQPOLL))
3023: ctx->int_flags |= IO_RING_F_SYSCALL_IOPOLL;
3024:
3025: if (in_compat_syscall())
3026: ctx->int_flags |= IO_RING_F_COMPAT;
3027: if (!ns_capable_noaudit(&init_user_ns, CAP_IPC_LOCK))
3028: ctx->user = get_uid(current_user());
3029:
3030: /*
3031: * For SQPOLL, we just need a wakeup, always. For !SQPOLL, if
3032: * COOP_TASKRUN is set, then IPIs are never needed by the app.
3033: */
3034: if (ctx->flags & (IORING_SETUP_SQPOLL|IORING_SETUP_COOP_TASKRUN))
3035: ctx->notify_method = TWA_SIGNAL_NO_IPI;
3036: else
3037: ctx->notify_method = TWA_SIGNAL;
3038:
3039: /*
3040: * If the current task has restrictions enabled, then copy them to
3041: * our newly created ring and mark it as registered.
3042: */
3043: if (current->io_uring_restrict)
3044: io_ctx_restriction_clone(ctx, current->io_uring_restrict);
3045:
3046: /*
3047: * This is just grabbed for accounting purposes. When a process exits,
3048: * the mm is exited and dropped before the files, hence we need to hang
3049: * on to this mm purely for the purposes of being able to unaccount
3050: * memory (locked/pinned vm). It's not used for anything else.
3051: */
3052: mmgrab(current->mm);
3053: ctx->mm_account = current->mm;
3054:
3055: ret = io_allocate_scq_urings(ctx, config);
3056: if (ret)
3057: goto err;
3058:
3059: ret = io_sq_offload_create(ctx, p);
3060: if (ret)
3061: goto err;
3062:
3063: p->features = IORING_FEAT_FLAGS;
3064:
3065: if (copy_to_user(config->uptr, p, sizeof(*p))) {
3066: ret = -EFAULT;
3067: goto err;
3068: }
3069:
3070: if (ctx->flags & IORING_SETUP_SINGLE_ISSUER
3071: && !(ctx->flags & IORING_SETUP_R_DISABLED))
3072: ctx->submitter_task = get_task_struct(current);
3073:
3074: file = io_uring_get_file(ctx);
3075: if (IS_ERR(file)) {
3076: ret = PTR_ERR(file);
3077: goto err;
3078: }
3079:
3080: ret = __io_uring_add_tctx_node(ctx);
3081: if (ret)
3082: goto err_fput;
3083: tctx = current->io_uring;
3084:
3085: /*
3086: * Install ring fd as the very last thing, so we don't risk someone
3087: * having closed it before we finish setup
3088: */
3089: if (p->flags & IORING_SETUP_REGISTERED_FD_ONLY)
3090: ret = io_ring_add_registered_file(tctx, file, 0, IO_RINGFD_REG_MAX);
3091: else
3092: ret = io_uring_install_fd(file);
3093: if (ret < 0)
3094: goto err_fput;
3095:
3096: trace_io_uring_create(ret, ctx, p->sq_entries, p->cq_entries, p->flags);
3097: return ret;
3098: err:
3099: io_ring_ctx_wait_and_kill(ctx);
3100: return ret;
3101: err_fput:
3102: fput(file);
3103: return ret;
3104: }
SourceFile:io_uring/io_uring.c]
|
| 131/2 |
2026/06/12 22:37 |
llm |
expert |
0m
Model:
Tokens:
input: 77828
output: 42
thoughts: 42
Thoughts: Okay, let's see. My mind's jumping through this code... **Digging into io_uring Creation**
Right, so `io_uring_create` is the function that kicks off the whole uring setup. And *that* calls `io_allocate_scq_urings(ctx, config)`. Hmm, that sounds like the core memory allocation for the structures. I need to understand that function better. That's where things are probably initialized at a low level, so understanding that is crucial to the whole thing. Let's trace through `io_allocate_scq_urings` and see what it's really doing under the hood. It's time to dive into that function and understand its role.
|
| 132/2 |
2026/06/12 22:37 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_allocate_scq_urings]
Results: map[SourceCode:2731: static __cold int io_allocate_scq_urings(struct io_ring_ctx *ctx,
2732: struct io_ctx_config *config)
2733: {
2734: struct io_uring_params *p = &config->p;
2735: struct io_rings_layout *rl = &config->layout;
2736: struct io_uring_region_desc rd;
2737: struct io_rings *rings;
2738: int ret;
2739:
2740: /* make sure these are sane, as we already accounted them */
2741: ctx->sq_entries = p->sq_entries;
2742: ctx->cq_entries = p->cq_entries;
2743:
2744: memset(&rd, 0, sizeof(rd));
2745: rd.size = PAGE_ALIGN(rl->rings_size);
2746: if (ctx->flags & IORING_SETUP_NO_MMAP) {
2747: rd.user_addr = p->cq_off.user_addr;
2748: rd.flags |= IORING_MEM_REGION_TYPE_USER;
2749: }
2750: ret = io_create_region(ctx, &ctx->ring_region, &rd, IORING_OFF_CQ_RING);
2751: if (ret)
2752: return ret;
2753: ctx->rings = rings = io_region_get_ptr(&ctx->ring_region);
2754: rcu_assign_pointer(ctx->rings_rcu, rings);
2755: if (!(ctx->flags & IORING_SETUP_NO_SQARRAY))
2756: ctx->sq_array = (u32 *)((char *)rings + rl->sq_array_offset);
2757:
2758: memset(&rd, 0, sizeof(rd));
2759: rd.size = PAGE_ALIGN(rl->sq_size);
2760: if (ctx->flags & IORING_SETUP_NO_MMAP) {
2761: rd.user_addr = p->sq_off.user_addr;
2762: rd.flags |= IORING_MEM_REGION_TYPE_USER;
2763: }
2764: ret = io_create_region(ctx, &ctx->sq_region, &rd, IORING_OFF_SQES);
2765: if (ret) {
2766: io_rings_free(ctx);
2767: return ret;
2768: }
2769: ctx->sq_sqes = io_region_get_ptr(&ctx->sq_region);
2770:
2771: memset(rings, 0, sizeof(*rings));
2772: WRITE_ONCE(rings->sq_ring_mask, ctx->sq_entries - 1);
2773: WRITE_ONCE(rings->cq_ring_mask, ctx->cq_entries - 1);
2774: WRITE_ONCE(rings->sq_ring_entries, ctx->sq_entries);
2775: WRITE_ONCE(rings->cq_ring_entries, ctx->cq_entries);
2776: return 0;
2777: }
SourceFile:io_uring/io_uring.c]
|
| 133/2 |
2026/06/12 22:37 |
llm |
expert |
0m
Model:
Tokens:
input: 78978
output: 34
thoughts: 581
Thoughts: **Debugging the Reproducer: A Deep Dive**
Okay, let's break this down systematically. My initial thought was that the `io_create_region` call using `IORING_MEM_REGION_TYPE_USER` might be the culprit. Specifically, the concern was that if `user_addr` was zero, it would try to pin pages at address zero. Since the reproducer doesn't map anything there, that'd result in an `-EFAULT` from `io_create_region`. I double-checked the memory map, confirming it's not mapped at address zero, but instead at addresses that are quite high. So, the `io_uring_setup` call failing seemed logical, resulting in -1.
But, wait... if `io_uring_setup` fails, then `r[0]` remains `0xffffffffffffffff`. This leads to `io_uring_enter` being called with `fd = -1`, which *should* then fail with `-EBADF`. Thus, the `io_uring` calls *appear* to be irrelevant to the problem, they're likely not causing the error. I went back to the reproducer and checked again to make sure:
```c
res = syscall(__NR_io_uring_setup, /*entries=*/0x523, /*params=*/0x200000000040ul);
if (res != -1)
r[0] = res;
// ...
syscall(__NR_io_uring_enter, /*fd=*/r[0], /*to_submit=*/0x1203, /*min_complete=*/0x109c, /*flags=IORING_ENTER_REGISTERED_RING|IORING_ENTER_SQ_WAIT|IORING_ENTER_SQ_WAKEUP*/0x16ul, /*sigmask=*/0ul, /*size=*/0xffffffffffffff02ul);
```
So `io_uring_setup` failing means `r[0]` is `-1`, confirming the assumption that `io_uring` is a red herring. The reproducer is calling it, but it appears to be unrelated to the root cause of the bug.
Now, let's switch gears and focus on `sendmsg`. The reproducer calls `sendmsg` with `fd = -1`, and that's concerning. If `fd` is -1, it'll fail in `sockfd_lookup_light` immediately with `-EBADF`. That's where I need to look closer. Let's dig into `__sys_sendmsg`.
|
| 134/2 |
2026/06/12 22:37 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:net/socket.c Name:__sys_sendmsg]
Results: map[SourceCode:2768: long __sys_sendmsg(int fd, struct user_msghdr __user *msg, unsigned int flags,
2769: bool forbid_cmsg_compat)
2770: {
2771: struct msghdr msg_sys;
2772: struct socket *sock;
2773:
2774: if (forbid_cmsg_compat && (flags & MSG_CMSG_COMPAT))
2775: return -EINVAL;
2776:
2777: CLASS(fd, f)(fd);
2778:
2779: if (fd_empty(f))
2780: return -EBADF;
2781: sock = sock_from_file(fd_file(f));
2782: if (unlikely(!sock))
2783: return -ENOTSOCK;
2784:
2785: return ___sys_sendmsg(sock, msg, &msg_sys, flags, NULL, 0);
2786: }
SourceFile:net/socket.c]
|
| 135/2 |
2026/06/12 22:37 |
llm |
expert |
0m
Model:
Tokens:
input: 80474
output: 19
thoughts: 1435
Thoughts: **Analyzing the System Call Sequence**
Okay, so I'm looking at this sequence. The first thing that jumps out is that `fd_empty(f)` will indeed be true when `fd = -1`, which is returning `-EBADF`. That's expected. Then, I see the first `sendmsg` call is also using `fd = -1`. So, it's pretty clear both `sendmsg` calls are going to fail with `-EBADF`. That's not the interesting part, likely just a side effect.
Next up, the `prctl` call catches my eye. It's using `PR_SET_MM` with `PR_SET_MM_MAP`. The struct `prctl_mm_map` seems to be initialized with some memory addresses. Okay, looks like it's setting memory map information for various regions like `start_code`, `end_code`, etc. I see `exe_fd` is initialized to -1. So, it doesn't set an executable file descriptor. It's likely related to process address space layout, but again, not the key issue.
So, the only thing that actually appears to be doing something useful is `syz_open_dev`. It's copying a path to `/dev/vbi#` and then calling `syz_open_dev` to open `/dev/vbi3` with `O_RDWR` which is `flags = 2`. The important bit is that this call is occurring and returning a file descriptor. What I don't see is the reproducer *using* the returned file descriptor. It's ignoring it.
My first thought is that the file descriptor might be leaked, but since the process is exiting, that's not really the issue. The kernel closes the file descriptors on process exit. However, this seems to point me to the actual memory leak, I see the bug report about the memory leak and the important line is: `alloc_empty_file+0x57/0x180 fs/file_table.c:262`. `alloc_empty_file` allocates a `struct file`. The `kmemleak` is reporting size 176 bytes for a memory leak object.
Now, this is where it gets interesting, because 176 bytes is too small for a typical `struct file`. `struct file` is much bigger. This means it's not a direct `struct file` that's leaking, it's something associated with it. I need to investigate the size of the `struct file` and the memory allocation around it to see what's actually being leaked. The report says, this is an "unreferenced object" which would be associated with a file, likely a file that was allocated. The leak is clearly related to this file, it's an unreferenced file object. I must verify the `struct file` size to determine the issue, and then determine how it could be unreferenced in this scenario.
|
| 136/2 |
2026/06/12 22:37 |
tool |
codesearch-struct-layout |
0m
Args:
Results: map[Fields:[map[Name:f_lock OffsetBits:0 SizeBits:32] map[Name:f_mode OffsetBits:32 SizeBits:32] map[Name:f_op OffsetBits:64 SizeBits:64] map[Name:f_mapping OffsetBits:128 SizeBits:64] map[Name:private_data OffsetBits:192 SizeBits:64] map[Name:f_inode OffsetBits:256 SizeBits:64] map[Name:f_flags OffsetBits:320 SizeBits:32] map[Name:f_iocb_flags OffsetBits:352 SizeBits:32] map[Name:f_cred OffsetBits:384 SizeBits:64] map[Name:f_owner OffsetBits:448 SizeBits:64] map[Name: OffsetBits:512 SizeBits:128] map[Name: OffsetBits:640 SizeBits:192] map[Name:f_pos OffsetBits:832 SizeBits:64] map[Name:f_security OffsetBits:896 SizeBits:64] map[Name:f_wb_err OffsetBits:960 SizeBits:32] map[Name:f_sb_err OffsetBits:992 SizeBits:32] map[Name:f_ep OffsetBits:1024 SizeBits:64] map[Name: OffsetBits:1088 SizeBits:256] map[Name:f_ref OffsetBits:1344 SizeBits:64]]]
|
| 137/2 |
2026/06/12 22:37 |
llm |
expert |
0m
Model:
Tokens:
input: 82980
output: 49
thoughts: 420
Thoughts: **Analyzing the Leaked `struct file`**
Okay, so I've pinpointed that `f_ref` within the leaked object is located at an offset of 168 bytes. This means the total size of the object is 176 bytes – confirming it's a `struct file`. The fact that this `struct file` is leaking is the core of the problem.
My mind immediately jumps to how file descriptors and reference counts work. When a process exits, the file descriptor table gets cleaned up, triggering `fput` on each file. `fput` should decrement the refcount, and if it hits zero, the file should be freed. So, the leak indicates either an increment without a corresponding decrement, or a scenario where the file was removed from the file descriptor table but `fput` wasn't called.
I need to quickly eliminate other possibilities. Let me look at the system calls in the reproducer:
```c
syscall(__NR_socket, /*domain=*/0x10ul, /*type=*/3ul, /*proto=*/0x10);
syscall(__NR_socket, /*domain=AF_INET*/2ul, /*type=SOCK_RAW*/3ul, /*proto=*/0x67);
```
These just involve socket creation, and it's unlikely that those are the root cause. I have to consider other scenarios that may be a factor, such as the `sendmsg` syscall with an invalid file descriptor. However, since the file descriptor `fd=-1` is immediately failing, it can't be the root cause.
The next possibility is the `io_uring_setup` call. The setup routine does call `io_uring_get_file(ctx)` and it allocates an anonymous file.
Hold on a second, the backtrace says `path_openat`. So, it's NOT the anonymous file allocated by `io_uring`, it is `/dev/vbi3`.
That means the vulnerability must reside in the `open` path of `/dev/vbi3`. I'll need to dive into `v4l2_open`.
|
| 138/2 |
2026/06/12 22:37 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/media/v4l2-core/v4l2-dev.c Name:v4l2_open]
Results: map[SourceCode: 410: /* Override for the open function */
411: static int v4l2_open(struct inode *inode, struct file *filp)
412: {
413: struct video_device *vdev;
414: int ret;
415:
416: /* Check if the video device is available */
417: mutex_lock(&videodev_lock);
418: vdev = video_devdata(filp);
419: /* return ENODEV if the video device has already been removed. */
420: if (vdev == NULL || !video_is_registered(vdev)) {
421: mutex_unlock(&videodev_lock);
422: return -ENODEV;
423: }
424: /* and increase the device refcount */
425: video_get(vdev);
426: mutex_unlock(&videodev_lock);
427:
428: if (!video_is_registered(vdev)) {
429: ret = -ENODEV;
430: goto done;
431: }
432:
433: ret = vdev->fops->open(filp);
434: if (ret)
435: goto done;
436:
437: /* All drivers must use v4l2_fh. */
438: if (WARN_ON(!test_bit(V4L2_FL_USES_V4L2_FH, &vdev->flags))) {
439: vdev->fops->release(filp);
440: ret = -ENODEV;
441: }
442:
443: done:
444: if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
445: dprintk("%s: open (%d)\n",
446: video_device_node_name(vdev), ret);
447:
448: /* decrease the refcount in case of an error */
449: if (ret)
450: video_put(vdev);
451: return ret;
452: }
SourceFile:drivers/media/v4l2-core/v4l2-dev.c]
|
| 139/2 |
2026/06/12 22:37 |
llm |
expert |
0m
Model:
Tokens:
input: 84575
output: 48
thoughts: 141
Thoughts: **Analyzing Potential File Descriptor Leaks in Video4Linux2 Device Opening**
Okay, so I'm tracing the `v4l2_open` function call here, and it looks like it delegates the actual device open to `vdev->fops->open(filp)`. My first thought is: what happens if *that* `open` function returns an error? Does the control just jump back up to the `done` label, and the error gets returned? If so, does this potentially lead to a file descriptor leak? I mean, could the underlying `open` function have already done some work that wasn't properly cleaned up?
No, hold on. The VFS, the Virtual File System, handles the error return from `v4l2_open`. The VFS will call `fput` on the file structure if the open fails. So the file descriptor *should* be cleaned up properly.
But wait, what if `vdev->fops->open` itself increments the file's reference count? That could be a problem, right? Let's quickly check how `vivid_fop_open` handles this. I think it is important to know this detail.
|
| 140/2 |
2026/06/12 22:37 |
tool |
codesearch-definition-source |
0m
Error: requested entity does not exist
Args: map[ContextFile:drivers/media/test-drivers/vivid/vivid-core.c Name:vivid_fop_open]
Results: map[SourceCode: SourceFile:]
|
| 141/2 |
2026/06/12 22:37 |
llm |
expert |
0m
Model:
Tokens:
input: 85039
output: 25
thoughts: 12
Thoughts: Okay, here's my attempt at summarizing that thought process, tailored for an expert audience:
**Finding the `open` Function in Vivid**
Alright, let's get down to it. I need to get my hands on the `open` function within the vivid codebase. I know it's there; the question is, how do I quickly locate its definition? I'm assuming that it is a wrapper for a Pythonic `open` call, and that it provides some additional functionality which would be specific to vivid. I'm thinking I'll start with a few educated guesses. Is it a module-level function, perhaps directly accessible from the main vivid namespace? Or is it nested within a specific class or object, maybe one related to file handling, data loading, or resource management within the framework?
I could run a quick `grep` or `ag` search, but for a smaller codebase, or if I have a general idea, I may be faster off searching through documentation or looking at the package's folder structure. In fact, if the documentation is well structured, and I can quickly search for `file` and `io`, I may find the information faster.
I'll be looking for clues about the function's purpose, how it handles different file formats, and any specific error handling or pre/post-processing it might perform. I'm also interested in its expected input arguments and what it returns. If it's a wrapper, what additional functionality does it provide beyond the standard Python `open` call?
|
| 142/2 |
2026/06/12 22:37 |
tool |
grepper |
0m
Error:
Args: map[Expression:\.open\s*=\s*vivid_]
Results:
|
| 143/2 |
2026/06/12 22:37 |
llm |
expert |
0m
Model:
Tokens:
input: 85410
output: 27
thoughts: 17
Thoughts: Here's a summary of my thought process, as requested:
**Diving into `v4l2_file_operations` in Vivid**
Alright, let's get down to it. My initial focus needs to be on the `v4l2_file_operations` within the Vivid context. I'm immediately thinking about how the Video4Linux2 framework is implemented in this specific driver. What are the key function pointers defined here? Are there any obvious deviations from the standard V4L2 approach that might be relevant to my area of expertise? I'm anticipating interactions between this structure and the hardware abstraction layer, naturally. What's the control flow? What's the context switching paradigm? Are there any potential bottlenecks I should be aware of, especially regarding concurrency and resource contention? I'll be looking closely for the file operation implementations, `open`, `release`, `read`, `write`, `poll`, `ioctl`, etc. - all the usual suspects. I'll need to see how these functions interact with the underlying hardware, how they handle buffer management and error conditions, and how they expose the V4L2 interface to userspace. I'm expecting this is where the driver interacts directly with the V4L2 core. I hope it is well-designed; I need to know how the driver handles initialization, shutdown, and resource management. And of course, I am expecting there to be a considerable amount of work around synchronization and locking to protect the device's state. I'll also be trying to mentally map these operations to the device's capabilities and its register-level interactions. Let's see what's in there...
|
| 144/2 |
2026/06/12 22:38 |
tool |
grepper |
0m
Args: map[Expression:struct v4l2_file_operations vivid_fops]
Results: map[Output:drivers/media/test-drivers/vivid/vivid-core.c=640=static int vivid_fop_release(struct file *file)
--
drivers/media/test-drivers/vivid/vivid-core.c-670-
drivers/media/test-drivers/vivid/vivid-core.c:671:static const struct v4l2_file_operations vivid_fops = {
drivers/media/test-drivers/vivid/vivid-core.c-672- .owner = THIS_MODULE,
]
|
| 145/2 |
2026/06/12 22:38 |
llm |
expert |
0m
Model:
Tokens:
input: 85947
output: 45
thoughts: 11
Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person:
**Analyzing the Call for `vivid_fops`**
Right, let's dive into this. "Let's read `vivid_fops`." It's a direct, almost instinctual reaction, isn't it? As an expert, I'm immediately drawn to the operational significance here. The very suggestion to "read" suggests an understanding is needed, a process of careful consideration. The name itself, `vivid_fops`, is intriguing. The inclusion of "vivid" suggests the data is rich, maybe complex. "Fops", well, that's almost certainly pointing to a specific internal model, or, at least a set of functions and associated data, and, depending on the context, probably a specific and highly-used set of functions. I immediately start mentally parsing the name, anticipating the type of functionality or data structure this relates to, the possible implications for whatever project or problem I'm currently focused on. Is this a core routine, a visualization tool, or something else entirely? The name itself gives us an indication, and this indicates where I should now be focusing. I need to be ready to get into it.
|
| 146/2 |
2026/06/12 22:38 |
tool |
read-file |
0m
Args: map[File:drivers/media/test-drivers/vivid/vivid-core.c FirstLine:671 LineCount:20]
Results: map[Contents: 671: static const struct v4l2_file_operations vivid_fops = {
672: .owner = THIS_MODULE,
673: .open = v4l2_fh_open,
674: .release = vivid_fop_release,
675: .read = vb2_fop_read,
676: .write = vb2_fop_write,
677: .poll = vb2_fop_poll,
678: .unlocked_ioctl = video_ioctl2,
679: .mmap = vb2_fop_mmap,
680: };
681:
682: static const struct v4l2_file_operations vivid_radio_fops = {
683: .owner = THIS_MODULE,
684: .open = v4l2_fh_open,
685: .release = vivid_fop_release,
686: .read = vivid_radio_read,
687: .write = vivid_radio_write,
688: .poll = vivid_radio_poll,
689: .unlocked_ioctl = video_ioctl2,
690: };
]
|
| 147/2 |
2026/06/12 22:38 |
llm |
expert |
0m
Model:
Tokens:
input: 86629
output: 51
thoughts: 26
Thoughts: Here's a summary of my thought process:
**Diving into the Code: Understanding `v4l2_fh_open`**
Okay, so the code's utilizing `v4l2_fh_open`. My first instinct is to zero in on that function. To really understand what's happening, I need to know the implications of `v4l2_fh_open`. I'll dig into the details and documentation related to `v4l2_fh_open` to see how this function is utilized to provide the behavior I need. Let's see what's going on in that part of the code.
|
| 148/2 |
2026/06/12 22:38 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/media/v4l2-core/v4l2-fh.c Name:v4l2_fh_open]
Results: map[SourceCode: 57: int v4l2_fh_open(struct file *filp)
58: {
59: struct video_device *vdev = video_devdata(filp);
60: struct v4l2_fh *fh = kzalloc_obj(*fh);
61:
62: if (fh == NULL)
63: return -ENOMEM;
64: v4l2_fh_init(fh, vdev);
65: v4l2_fh_add(fh, filp);
66: return 0;
67: }
SourceFile:drivers/media/v4l2-core/v4l2-fh.c]
|
| 149/2 |
2026/06/12 22:38 |
llm |
expert |
0m
Model:
Tokens:
input: 87046
output: 51
thoughts: 35
Thoughts: Okay, here's my interpretation of that thought process, from an expert's perspective:
**Diving Deep into v4l2_fh_add and File Handle Management**
Right, so I'm focusing on `v4l2_fh_add`. The core function. My immediate question is always about the fundamentals. I understand that this function is meant to link the `fh` (file handle) structure to the `filp` (file pointer). That's the primary purpose, no doubt. But that connection immediately triggers a critical question in my mind: *does this association involve incrementing the reference count of the `filp`?* It's essential. I need to know precisely how the kernel maintains this relationship, especially when dealing with concurrent access. If it *doesn't* increment the `filp`'s refcount, then I've got a potential race condition or reference counting bug that I need to address. Ignoring this can lead to subtle memory issues or premature resource release, causing significant instability and, of course, kernel panics that are not to be taken lightly.
|
| 150/2 |
2026/06/12 22:38 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/media/v4l2-core/v4l2-fh.c Name:v4l2_fh_add]
Results: map[SourceCode: 44: void v4l2_fh_add(struct v4l2_fh *fh, struct file *filp)
45: {
46: unsigned long flags;
47:
48: filp->private_data = fh;
49:
50: v4l2_prio_open(fh->vdev->prio, &fh->prio);
51: spin_lock_irqsave(&fh->vdev->fh_lock, flags);
52: list_add(&fh->list, &fh->vdev->fh_list);
53: spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
54: }
SourceFile:drivers/media/v4l2-core/v4l2-fh.c]
|
| 151/2 |
2026/06/12 22:38 |
llm |
expert |
0m
Model:
Tokens:
input: 87593
output: 36
thoughts: 1855
Thoughts: **Analyzing a Potential File Descriptor Leak**
Okay, so I'm looking at this reproducer and trying to figure out if it's leaking a file descriptor, specifically related to `/dev/vbi3`. My first thought was, does `v4l2_fh_open` somehow increment the refcount and cause a leak, but it doesn't. So I started checking the calls.
Now, I was initially concerned about how the file descriptor might be passed to `io_uring` through `io_uring_setup`, thinking that might be the source of the leak. But I'm reminded that `io_uring_setup` is actually called with `IORING_SETUP_REGISTERED_FD_ONLY`, so the setup registers the ring fd itself. If it succeeds, it registers the ring file descriptor into the task's `tctx->registered_rings` array.
Looking at the reproducer, it does call `io_uring_setup`, storing the returned ring fd index in `r[0]`. The next call opens `/dev/vbi3` using `syz_open_dev`, which gets the file descriptor.
But then, `io_uring_enter` is called with `fd = r[0]`. This is where it gets interesting. `io_uring_enter` can use its first argument, `fd`, as an index into `tctx->registered_rings` if `IORING_ENTER_REGISTERED_RING` is set, and that's the case here. So it's operating on the *ring* file descriptor, not the `/dev/vbi3` fd.
The critical thing is, `syz_open_dev`'s return value (the `/dev/vbi3` fd) is *ignored*! The reproducer's code doesn't save it. So `io_uring_enter` *doesn't* actually know about or use the `/dev/vbi3` file descriptor.
Could `syz_open_dev` return `0` and thus "leak" it via that value? No, because `io_uring_enter` still uses `r[0]` as the *ring's* index. The return value from the open is irrelevant to it. `io_uring_enter` gets the ring from `tctx->registered_rings[0]`, not the file descriptor table. This is important to note.
Then there is the issue of the `sendmsg` calls which take `fd = -1`, and fail immediately with `-EBADF`. The `sendmsg` call is irrelevant here as it fails immediately.
Okay, so looking through the syscall sequence, the only place where the `/dev/vbi3` fd is *directly* interacted with is the call to `syz_open_dev` itself, which calls `open("/dev/vbi3", O_RDWR)`. That's where it happens.
So the question is, could `open("/dev/vbi3", O_RDWR)` itself, under these specific circumstances, somehow leak the file descriptor? When an `open` is successful, it adds the file descriptor to the task's file descriptor table. On exit, `do_exit` calls `exit_files`, which calls `put_files_struct`, then `close_files`, which iterates through the open fds and calls `filp_close` -> `fput`. The leak would only happen if `fput` is not called, or if the reference count is incremented and not decremented, so something is messed up.
I need to look into `do_sys_openat2` to be sure there's not a logic issue there.
|
| 152/2 |
2026/06/12 22:38 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/open.c Name:do_sys_openat2]
Results: map[SourceCode:1355: static int do_sys_openat2(int dfd, const char __user *filename,
1356: struct open_how *how)
1357: {
1358: struct open_flags op;
1359: int err = build_open_flags(how, &op);
1360: if (unlikely(err))
1361: return err;
1362:
1363: CLASS(filename, name)(filename);
1364: return FD_ADD(how->flags, do_file_open(dfd, name, &op));
1365: }
SourceFile:fs/open.c]
|
| 153/2 |
2026/06/12 22:38 |
llm |
expert |
0m
Model:
Tokens:
input: 90477
output: 32
thoughts: 15
Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience and written in the first person:
**Investigating the `FD_ADD` Macro**
Okay, hold on a second. I see this `FD_ADD` macro popping up. Right away, my brain's going into "definition dive" mode. I need to refresh my understanding of how this particular macro is implemented. What precisely is it doing? How does it interact with the underlying file descriptor set structures? Is it a simple bitwise operation, or does it involve any more complex memory management? I’m thinking there's a reason this particular method was used - are there any performance concerns with just using `|=`? Are there other side effects that I'm forgetting? Let's check the header and make sure there is nothing sneaky that I'm missing.
|
| 154/2 |
2026/06/12 22:38 |
tool |
codesearch-definition-source |
0m
Error: requested entity does not exist
Args: map[ContextFile:fs/open.c Name:FD_ADD]
Results: map[SourceCode: SourceFile:]
|
| 155/2 |
2026/06/12 22:38 |
llm |
expert |
0m
Model:
Tokens:
input: 90723
output: 19
thoughts: 10
Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience:
**Grasping for Context: The `FD_ADD` Hunt**
Alright, the mental gears are starting to turn. My immediate instinct is to reach for a `grep` (or equivalent, depending on the environment - `ag` might be more efficient for this project). That single term, `FD_ADD`, screams "file descriptor management" and "event handling" to me. I'm assuming we're dealing with something low-level, likely networking, asynchronous I/O, or possibly even kernel-level code. There's a high probability this code is C or C++, but I'm prepared to adapt based on what `grep` uncovers. My first pass will be broad – covering the whole codebase, including any included libraries, to get a lay of the land. I need the full picture of where this `FD_ADD` is used, to infer its precise role within the system. Is it part of a bespoke event loop, a standard library wrapper (e.g., something POSIX-related), or a third-party library? The immediate goal is to establish the scope of its usage. From there, I'll be able to better understand the design decisions surrounding it, and what's next. Let's start digging.
|
| 156/2 |
2026/06/12 22:38 |
tool |
grepper |
0m
Args: map[Expression:#define FD_ADD]
Results: map[Output:include/linux/file.h=171=static inline int class_fd_prepare_lock_err(const struct fd_prepare *fdf)
--
include/linux/file.h-251- */
include/linux/file.h:252:#define FD_ADD(_fd_flags, _file_owned) \
include/linux/file.h-253- __FD_ADD(__UNIQUE_ID(fd_prepare), _fd_flags, _file_owned)
]
|
| 157/2 |
2026/06/12 22:38 |
llm |
expert |
0m
Model:
Tokens:
input: 91161
output: 20
thoughts: 10
Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person:
**Analyzing the Call to `__FD_ADD`**
Right, let's dive in. The instruction is to read the definition of `__FD_ADD`. That's a low-level macro, almost certainly dealing with file descriptor manipulation, likely within the context of a `fd_set`. Given the naming convention, I'm expecting this to be a core operation, probably implemented as a bitwise manipulation. It's almost guaranteed to be part of a larger set of macros like `FD_CLR`, `FD_ISSET`, and `FD_ZERO`. My initial assumptions are that it will take two arguments at a minimum: the file descriptor (`fd`) and the `fd_set` (`fds`). I'm anticipating a straightforward bitwise OR operation to set the corresponding bit within the `fd_set` to represent the addition of the file descriptor. The potential is that the macro incorporates bounds checking to prevent overflows within the `fd_set`, as this is critical to avoid data corruption and undefined behavior. I'm also anticipating some level of compiler optimization will be applied, which could result in specific hardware instructions being leveraged depending on the target architecture. The `__` prefix strongly suggests this is a private or internal function within the system's libraries. I'm interested in looking out for any platform-specific implementations that might be present, as well as considering any edge cases relating to the maximum number of file descriptors that the implementation supports.
|
| 158/2 |
2026/06/12 22:38 |
tool |
grepper |
0m
Args: map[Expression:#define __FD_ADD]
Results: map[Output:include/linux/file.h=171=static inline int class_fd_prepare_lock_err(const struct fd_prepare *fdf)
--
include/linux/file.h-235-/* Do not use directly. */
include/linux/file.h:236:#define __FD_ADD(_fdf, _fd_flags, _file_owned) \
include/linux/file.h-237- ({ \
]
|
| 159/2 |
2026/06/12 22:38 |
llm |
expert |
0m
Model:
Tokens:
input: 91638
output: 35
thoughts: 12
Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience, and delivered as a first-person summary:
**Diving into the `__FD_ADD` Macro**
Right, let's get down to brass tacks. I'm going to start by pulling up the definition of `__FD_ADD`. No need to beat around the bush; I'm assuming, given the context, we're dealing with file descriptor manipulation – likely related to some sort of `fd_set` implementation, probably within a POSIX-compliant system. I'm immediately thinking about how it might be interacting with bitwise operations, likely shifting and ORing, to add a file descriptor to a set. I’m curious to see if it's optimized for different architectures and how it handles potential edge cases like exceeding the maximum number of file descriptors that the system supports. The goal, ultimately, is to understand its exact behavior and how it impacts performance within the broader system design. This is where the devil's in the details. I want to see precisely how this macro is constructed, so I can think about its possible implications.
|
| 160/2 |
2026/06/12 22:38 |
tool |
read-file |
0m
Args: map[File:include/linux/file.h FirstLine:236 LineCount:20]
Results: map[Contents: 236: #define __FD_ADD(_fdf, _fd_flags, _file_owned) \
237: ({ \
238: FD_PREPARE(_fdf, _fd_flags, _file_owned); \
239: s32 ret = _fdf.err; \
240: if (likely(!ret)) \
241: ret = fd_publish(_fdf); \
242: ret; \
243: })
244:
245: /*
246: * FD_ADD - Allocate and install an fd and file in one step.
247: * @_fd_flags: flags for get_unused_fd_flags()
248: * @_file_owned: struct file to take ownership of
249: *
250: * Returns the allocated fd number, or negative error code on failure.
251: */
252: #define FD_ADD(_fd_flags, _file_owned) \
253: __FD_ADD(__UNIQUE_ID(fd_prepare), _fd_flags, _file_owned)
254:
255: #endif /* __LINUX_FILE_H */
]
|
| 161/2 |
2026/06/12 22:38 |
llm |
expert |
0m
Model:
Tokens:
input: 92271
output: 21
thoughts: 50
Thoughts: **Analyzing File Descriptor Allocation**
Okay, hold on a second. I need to think this through. So, `FD_PREPARE` is the function responsible for allocating the file descriptor. Right, and if there's a problem, it should return an error indication. That's the expected behavior.
But, wait a minute, I have to consider a corner case here. What if the `_file_owned` variable is itself an error pointer? That could throw a wrench in the whole process. I should double-check that this isn't masking a real error.
Alright, time to go back and carefully examine the `FD_PREPARE` function's implementation. I need to make sure I understand its error handling and how it interacts with `_file_owned` thoroughly. This level of detail is critical to avoid subtle bugs in file descriptor management.
|
| 162/2 |
2026/06/12 22:38 |
tool |
grepper |
0m
Args: map[Expression:#define FD_PREPARE]
Results: map[Output:include/linux/file.h=171=static inline int class_fd_prepare_lock_err(const struct fd_prepare *fdf)
--
include/linux/file.h-216- */
include/linux/file.h:217:#define FD_PREPARE(_fdf, _fd_flags, _file_owned) \
include/linux/file.h-218- CLASS_INIT(fd_prepare, _fdf, __FD_PREPARE_INIT(_fd_flags, _file_owned))
]
|
| 163/2 |
2026/06/12 22:38 |
llm |
expert |
0m
Model:
Tokens:
input: 92666
output: 24
thoughts: 14
Thoughts: Here's a summary of my thought process, assuming I'm an expert:
**Investigating `__FD_PREPARE_INIT`**
Okay, let's dive into this `__FD_PREPARE_INIT` macro. My first thought is to understand its context. I need to figure out what library or module it belongs to immediately. Is this a glibc thing? Perhaps a specific system call wrapper? I'm going to quickly reference the relevant headers to get a bearing. I'm looking for the defining macro and its arguments, or the structures it interacts with. What's the intended purpose of this thing? Is this related to file descriptor management? Initialization of some internal data structure? Handling of file descriptors prior to I/O operations? My instinct is it has something to do with initializing or pre-configuring a file descriptor, especially given the `FD` prefix. I need to ascertain where this macro is called, to understand the surrounding logic. What are the dependencies? I'll probably start with a `grep` or code navigation to pinpoint its usages, particularly within the potentially relevant libraries. Once I know that, I should be able to deduce its function and any potential implications from its usage. I'm hoping I'm not dealing with something obscure and undocumented, but even if it is, tracing back from the usages should give me enough context.
|
| 164/2 |
2026/06/12 22:39 |
tool |
grepper |
0m
Args: map[Expression:#define __FD_PREPARE_INIT]
Results: map[Output:include/linux/file.h=171=static inline int class_fd_prepare_lock_err(const struct fd_prepare *fdf)
--
include/linux/file.h-194- */
include/linux/file.h:195:#define __FD_PREPARE_INIT(_fd_flags, _file_owned) \
include/linux/file.h-196- ({ \
]
|
| 165/2 |
2026/06/12 22:39 |
llm |
expert |
0m
Model:
Tokens:
input: 93105
output: 35
thoughts: 14
Thoughts: Okay, here's my interpretation of that thought process, assuming I'm an expert in this field and approaching this with a high level of technical understanding:
**Diving into the Initialization Process**
Alright, my internal gears are already turning. The thought "Let's read `__FD_PREPARE_INIT`" immediately focuses my attention. This suggests we're about to delve into the initialization phase of *something* that involves file descriptors. The underscores and capitalization strongly imply this is a macro or a well-defined constant, likely related to setting up file descriptors in a system, probably at the kernel level or within a low-level library. I'm mentally parsing this as a signal to:
* **Understand the Context:** I need to quickly recall where this macro fits into the larger picture. What system or library are we working with? What is the function this initialization relates to?
* **Anticipate the Contents:** Given the naming convention, I'm expecting this will define constants, structures, or function calls associated with the initial setup or pre-processing of file descriptors. It may be about allocating structures, setting default flags, or handling the initial states of file descriptors.
* **Consider the Implications:** I'll be thinking about the implications of this initialization. What are the performance considerations? Are there any potential security vulnerabilities related to the setup? Are there any platform-specific differences I need to keep in mind?
So, my immediate thought is, "Okay, let's get into the nitty-gritty of how this system prepares file descriptors at the outset." Let's see what gems are contained within.
|
| 166/2 |
2026/06/12 22:39 |
tool |
read-file |
0m
Args: map[File:include/linux/file.h FirstLine:195 LineCount:20]
Results: map[Contents: 195: #define __FD_PREPARE_INIT(_fd_flags, _file_owned) \
196: ({ \
197: struct fd_prepare fdf = { \
198: .__fd = get_unused_fd_flags((_fd_flags)), \
199: }; \
200: if (likely(fdf.__fd >= 0)) \
201: fdf.__file = (_file_owned); \
202: fdf.err = ACQUIRE_ERR(fd_prepare, &fdf); \
203: fdf; \
204: })
205:
206: /*
207: * FD_PREPARE - Macro to declare and initialize an fd_prepare variable.
208: *
209: * Declares and initializes an fd_prepare variable with automatic
210: * cleanup. No separate scope required - cleanup happens when variable
211: * goes out of scope.
212: *
213: * @_fdf: name of struct fd_prepare variable to define
214: * @_fd_flags: flags for get_unused_fd_flags()
]
|
| 167/2 |
2026/06/12 22:39 |
llm |
expert |
0m
Model:
Tokens:
input: 93843
output: 21
thoughts: 104
Thoughts: **Decoding This Potential File Descriptor Issue**
Okay, hold on a second... `ACQUIRE_ERR`? That immediately flags something as potentially wrong. My initial thought process is this: If `_file_owned` is returning an error pointer, that `ACQUIRE_ERR` macro is *specifically* designed to set `fdf.err` appropriately. That makes sense, in isolation.
But then, the next question hits me: What if the file descriptor `fdf.__fd` is already non-negative (meaning it seems valid) *and* `_file_owned` returns an error pointer? Does the system correctly handle that scenario? Does it close the fd if we are in an error case? I need to know how the cleanup is managed.
Ah, right, `CLASS_INIT`. That's the key. That tells me the destructor for `fd_prepare` is going to be invoked when it goes out of scope. That’s probably the safety net here. It should, at the very least, handle the fd correctly, regardless of `_file_owned`'s state.
But I still need to know *what* that destructor actually *does* for `fd_prepare`. The specifics of the cleanup are key. That's the next thing I need to investigate.
|
| 168/2 |
2026/06/12 22:39 |
tool |
grepper |
0m
Error:
Args: map[Expression:DEFINE_CLASS\(fd_prepare]
Results:
|
| 169/2 |
2026/06/12 22:39 |
llm |
expert |
0m
Model:
Tokens:
input: 94257
output: 18
thoughts: 10
Thoughts: Here's a summary of my thought process, as if I were the one thinking it:
**Digging into `fd_prepare`**
Okay, time to get my hands dirty. I'm going to start by grepping for `fd_prepare`. That seems like the logical first step, right? It's a pretty specific function name, so that should give me a good starting point and quickly illuminate the areas of the code base that are interacting with this function. Hopefully, this will lead me to the relevant modules or subsystems that use `fd_prepare`, and that will give me context to work with. I'm expecting to see calls, definitions, and maybe even some documentation comments if I'm lucky. From there, I can start to understand its purpose and how it fits into the larger architecture. I'll pay close attention to the arguments it takes and how it's used within those calls. That should give me the hints needed to dig deeper.
|
| 170/2 |
2026/06/12 22:39 |
tool |
grepper |
0m
Args: map[Expression:struct fd_prepare]
Results: map[Output:include/linux/file.h=128=extern unsigned int sysctl_nr_open_min, sysctl_nr_open_max;
--
include/linux/file.h-141- */
include/linux/file.h:142:struct fd_prepare {
include/linux/file.h-143- s32 err;
--
include/linux/file.h-148-/* Typedef for fd_prepare cleanup guards. */
include/linux/file.h:149:typedef struct fd_prepare class_fd_prepare_t;
include/linux/file.h-150-
--
include/linux/file.h-155-#define fd_prepare_fd(_fdf) \
include/linux/file.h:156: (_Generic((_fdf), struct fd_prepare: (_fdf).__fd))
include/linux/file.h-157-
include/linux/file.h-158-#define fd_prepare_file(_fdf) \
include/linux/file.h:159: (_Generic((_fdf), struct fd_prepare: (_fdf).__file))
include/linux/file.h-160-
include/linux/file.h-161-/* Do not use directly. */
include/linux/file.h:162:static inline void class_fd_prepare_destructor(const struct fd_prepare *fdf)
include/linux/file.h-163-{
--
include/linux/file.h-170-/* Do not use directly. */
include/linux/file.h:171:static inline int class_fd_prepare_lock_err(const struct fd_prepare *fdf)
include/linux/file.h-172-{
--
include/linux/file.h-188- *
include/linux/file.h:189: * Returns a struct fd_prepare with fd, file, and err set.
include/linux/file.h-190- * If fd allocation fails, fd will be negative and err will be set. If
--
include/linux/file.h-196- ({ \
include/linux/file.h:197: struct fd_prepare fdf = { \
include/linux/file.h-198- .__fd = get_unused_fd_flags((_fd_flags)), \
--
include/linux/file.h-212- *
include/linux/file.h:213: * @_fdf: name of struct fd_prepare variable to define
include/linux/file.h-214- * @_fd_flags: flags for get_unused_fd_flags()
--
include/linux/file.h-221- * fd_publish - Publish prepared fd and file to the fd table.
include/linux/file.h:222: * @_fdf: struct fd_prepare variable
include/linux/file.h-223- */
--
include/linux/file.h-225- ({ \
include/linux/file.h:226: struct fd_prepare *fdp = &(_fdf); \
include/linux/file.h-227- VFS_WARN_ON_ONCE(fdp->err); \
]
|
| 171/2 |
2026/06/12 22:39 |
llm |
expert |
0m
Model:
Tokens:
input: 95297
output: 35
thoughts: 14
Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience:
**Analyzing `class_fd_prepare_destructor`**
Alright, let's dive into `class_fd_prepare_destructor`. My initial thought is to mentally parse the context of this function – I'm immediately interested in the class structure it's associated with and the overall object lifecycle it fits into. What's the fundamental role of this destructor preparation? Is it related to resource management (file descriptors, sockets, etc.), or some higher-level bookkeeping prior to an object's destruction?
I'm mentally running through potential scenarios: Is this handling closing file descriptors, releasing locks, signaling some kind of finalization to the operating system, or something else entirely? I anticipate there might be complexities involving RAII principles, exception handling, and potentially memory management if this destructor interacts with dynamically allocated resources. I'll need to pay close attention to any double-free vulnerabilities or resource leaks this code might introduce or prevent. Understanding thread safety implications is also crucial; are there any race conditions possible during destruction if this object is used in a multithreaded environment?
I'm prepared to critically assess any assumptions within the code. I'll mentally evaluate the control flow to ensure proper error handling and resource cleanup across all potential paths. I expect the code to be well-documented. Otherwise, I will have to start reasoning about the intended behavior and implications with what's available. Finally, I'm ready to consider any performance implications. I am trying to determine if it is optimized to avoid performance bottlenecks in critical sections, or if there is the potential to improve efficiency with minimal changes.
|
| 172/2 |
2026/06/12 22:39 |
tool |
read-file |
0m
Args: map[File:include/linux/file.h FirstLine:162 LineCount:20]
Results: map[Contents: 162: static inline void class_fd_prepare_destructor(const struct fd_prepare *fdf)
163: {
164: if (unlikely(fdf->__fd >= 0))
165: put_unused_fd(fdf->__fd);
166: if (unlikely(!IS_ERR_OR_NULL(fdf->__file)))
167: fput(fdf->__file);
168: }
169:
170: /* Do not use directly. */
171: static inline int class_fd_prepare_lock_err(const struct fd_prepare *fdf)
172: {
173: if (unlikely(fdf->err))
174: return fdf->err;
175: if (unlikely(fdf->__fd < 0))
176: return fdf->__fd;
177: if (unlikely(IS_ERR(fdf->__file)))
178: return PTR_ERR(fdf->__file);
179: if (unlikely(!fdf->__file))
180: return -ENOMEM;
181: return 0;
]
|
| 173/2 |
2026/06/12 22:39 |
llm |
expert |
0m
Model:
Tokens:
input: 96030
output: 35
thoughts: 73
Thoughts: **Analyzing the File Descriptor Lifecycle**
Okay, so I'm digging into this file descriptor management, specifically the cleanup process. The key here is that `class_fd_prepare_destructor` calls `put_unused_fd` and then `fput(fdf->__file)`. My initial thought is, how do these function calls interact. I need to understand what happens to the underlying file.
Then, the critical point is that `fd_publish` sets `fdf->__fd = -1` and `fdf->__file = NULL`. Hmm, if that's happening *before* the destructor is called, then `fput` in the destructor does *nothing* on a published descriptor. It's effectively a no-op! That seems like an optimization, but I need to be completely sure. I should check `fd_publish` and see exactly what's going on.
|
| 174/2 |
2026/06/12 22:39 |
tool |
read-file |
0m
Args: map[File:include/linux/file.h FirstLine:221 LineCount:20]
Results: map[Contents: 221: * fd_publish - Publish prepared fd and file to the fd table.
222: * @_fdf: struct fd_prepare variable
223: */
224: #define fd_publish(_fdf) \
225: ({ \
226: struct fd_prepare *fdp = &(_fdf); \
227: VFS_WARN_ON_ONCE(fdp->err); \
228: VFS_WARN_ON_ONCE(fdp->__fd < 0); \
229: VFS_WARN_ON_ONCE(IS_ERR_OR_NULL(fdp->__file)); \
230: fd_install(fdp->__fd, fdp->__file); \
231: retain_and_null_ptr(fdp->__file); \
232: take_fd(fdp->__fd); \
233: })
234:
235: /* Do not use directly. */
236: #define __FD_ADD(_fdf, _fd_flags, _file_owned) \
237: ({ \
238: FD_PREPARE(_fdf, _fd_flags, _file_owned); \
239: s32 ret = _fdf.err; \
240: if (likely(!ret)) \
]
|
| 175/2 |
2026/06/12 22:39 |
llm |
expert |
0m
Model:
Tokens:
input: 96715
output: 40
thoughts: 227
Thoughts: **Analyzing File Descriptor Management in System Calls**
Okay, let me break this down. My initial concern was about how file descriptors are managed during the process of opening files, specifically looking at `do_sys_openat2` and its interaction with `FD_ADD`. The general flow is: `FD_ADD` handles the creation and publication of the file descriptor. If that's successful, all good.
The key thing I'm focused on is error handling. If `do_file_open` hits a snag and returns an error, `FD_ADD` will propagate that, and the file destructor should call `fput` if the file structure it got was valid. Originally, I thought, because `do_file_open` returns an error *pointer*, it seemed like `IS_ERR_OR_NULL` was true and `fput` wouldn't be triggered, potentially leading to a leak. However, that's not right.
But, wait. Now I realize there's another possibility! Say `do_file_open` *succeeds* in returning a valid file structure, but then `get_unused_fd_flags` has an issue. If `get_unused_fd_flags` fails and sets `fdf->__fd < 0`... which means an error, `fdf.err` gets set. Consequently, `fd_publish` isn't called, which means the destructor DOES call `fput(fdf->__file)`. So, that seems correct and is expected behavior. That means I believe that `FD_ADD` properly manages errors in the case of `open` calls. I can see it correctly handles various error conditions.
But, my brain is now buzzing, and I'm not entirely satisfied. My concern now extends beyond file opening. What if the *leak* is somewhere else entirely, like in `io_uring_setup`? I need to go look at `io_uring_get_file` to be sure.
|
| 176/2 |
2026/06/12 22:39 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_uring_get_file]
Results: map[SourceCode:2790: /*
2791: * Allocate an anonymous fd, this is what constitutes the application
2792: * visible backing of an io_uring instance. The application mmaps this
2793: * fd to gain access to the SQ/CQ ring details.
2794: */
2795: static struct file *io_uring_get_file(struct io_ring_ctx *ctx)
2796: {
2797: /* Create a new inode so that the LSM can block the creation. */
2798: return anon_inode_create_getfile("[io_uring]", &io_uring_fops, ctx,
2799: O_RDWR | O_CLOEXEC, NULL);
2800: }
SourceFile:io_uring/io_uring.c]
|
| 177/2 |
2026/06/12 22:39 |
llm |
expert |
0m
Model:
Tokens:
input: 97631
output: 48
thoughts: 211
Thoughts: **Analyzing the File Leak in io_uring**
Okay, so I'm looking at this bug report concerning `io_uring_get_file`. The backtrace is throwing me for a loop, but let's break it down. The report says we're seeing `alloc_empty_file` which is called by `anon_inode_create_getfile`, which makes sense. However, the trace also includes `path_openat`. This is where it gets interesting, because while `anon_inode_create_getfile` *does* call `alloc_empty_file`, it's *not* called from `path_openat`.
That means the leaked file isn't coming from that direct chain! The trace must be showing *another* call to `path_openat`. And, as far as I can see in the reproducer, the *only* place `path_openat` is being used is in the `syz_open_dev` function for the `open` call. So if that's the only one, then we know the leaked file has to be `/dev/vbi3`.
Now, the question is *why* `/dev/vbi3` is being leaked. The most likely culprit would be in `vivid_fop_release`. I'll need to go and check that function now.
|
| 178/2 |
2026/06/12 22:39 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/media/test-drivers/vivid/vivid-core.c Name:vivid_fop_release]
Results: map[SourceCode: 640: static int vivid_fop_release(struct file *file)
641: {
642: struct vivid_dev *dev = video_drvdata(file);
643: struct video_device *vdev = video_devdata(file);
644:
645: mutex_lock(&dev->mutex);
646: if (!no_error_inj && v4l2_fh_is_singular_file(file) &&
647: dev->disconnect_error && !video_is_registered(vdev) &&
648: vivid_is_last_user(dev)) {
649: /*
650: * I am the last user of this driver, and a disconnect
651: * was forced (since this video_device is unregistered),
652: * so re-register all video_device's again.
653: */
654: v4l2_info(&dev->v4l2_dev, "reconnect\n");
655: vivid_reconnect(dev);
656: }
657: if (file_to_v4l2_fh(file) == dev->radio_rx_rds_owner) {
658: dev->radio_rx_rds_last_block = 0;
659: dev->radio_rx_rds_owner = NULL;
660: }
661: if (file_to_v4l2_fh(file) == dev->radio_tx_rds_owner) {
662: dev->radio_tx_rds_last_block = 0;
663: dev->radio_tx_rds_owner = NULL;
664: }
665: mutex_unlock(&dev->mutex);
666: if (vdev->queue)
667: return vb2_fop_release(file);
668: return v4l2_fh_release(file);
669: }
SourceFile:drivers/media/test-drivers/vivid/vivid-core.c]
|
| 179/2 |
2026/06/12 22:39 |
llm |
expert |
0m
Model:
Tokens:
input: 98756
output: 38
thoughts: 1426
Thoughts: **Analyzing Potential File Descriptor Leaks**
Okay, so `vivid_fop_release` isn't called, meaning the file descriptor is leaked. That immediately tells me the reference count isn't reaching zero. I need to figure out where the refcount is getting incremented. Let's see... possibilities include: `dup`, `dup2`, `dup3`, `fcntl(F_DUPFD)`; `sendmsg` with `SCM_RIGHTS`; `io_uring` FD registration; BPF maps... and, hang on, what about `mmap`? No, `mmap` *increments* the file's refcount, but the file descriptor will eventually be freed via `munmap` or process exit.
Ah, but does the reproducer actually `mmap` anything? Let's check...
```c
syscall(__NR_mmap, /*addr=*/0x1ffffffff000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
syscall(__NR_mmap, /*addr=*/0x200000000000ul, /*len=*/0x1000000ul, /*prot=PROT_WRITE|PROT_READ|PROT_EXEC*/7ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
syscall(__NR_mmap, /*addr=*/0x200001000000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
```
No, all the `mmap` calls are anonymous (`fd = -1`). That's a dead end.
Wait, what about `io_uring_setup`? That returns a file descriptor! And then `io_uring_enter` is called. Could it be related to `io_uring_setup`? Does it pass a file descriptor via `sendmsg` with `SCM_RIGHTS`?
Let's dissect the `sendmsg` calls. The first one is `sendmsg$NFT_BATCH`.
```c
*(uint64_t*)0x200000000080 = 0;
*(uint32_t*)0x200000000088 = 0;
*(uint64_t*)0x200000000090 = 0;
*(uint64_t*)0x200000000098 = 1;
*(uint64_t*)0x2000000000a0 = 0;
*(uint64_t*)0x2000000000a8 = 0;
*(uint32_t*)0x2000000000b0 = 0;
```
This is a `msghdr`. `msg_name`, `msg_namelen`, `msg_iov`, `msg_iovlen`, `msg_control`, `msg_controllen` are zero. `msg_flags` is zero. No `SCM_RIGHTS` there.
The second `sendmsg` is `sendmsg$nl_route_sched`.
```c
*(uint64_t*)0x200000006040 = 0;
*(uint32_t*)0x200000006048 = 0;
*(uint64_t*)0x200000006050 = 0x200000000140; // msg_iov
*(uint64_t*)0x200000000140 = 0x200000006080; // iov_base
*(uint64_t*)0x200000000148 = 0x1230; // iov_len
*(uint64_t*)0x2
|
| 180/2 |
2026/06/12 22:39 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_uring_create]
Results: map[SourceCode:2978: static __cold int io_uring_create(struct io_ctx_config *config)
2979: {
2980: struct io_uring_params *p = &config->p;
2981: struct io_ring_ctx *ctx;
2982: struct io_uring_task *tctx;
2983: struct file *file;
2984: int ret;
2985:
2986: ret = io_prepare_config(config);
2987: if (ret)
2988: return ret;
2989:
2990: ctx = io_ring_ctx_alloc(p);
2991: if (!ctx)
2992: return -ENOMEM;
2993:
2994: ctx->clockid = CLOCK_MONOTONIC;
2995: ctx->clock_offset = 0;
2996:
2997: if (!(ctx->flags & IORING_SETUP_NO_SQARRAY))
2998: static_branch_deferred_inc(&io_key_has_sqarray);
2999:
3000: if ((ctx->flags & IORING_SETUP_DEFER_TASKRUN) &&
3001: !(ctx->flags & IORING_SETUP_IOPOLL))
3002: ctx->int_flags |= IO_RING_F_TASK_COMPLETE;
3003:
3004: if ((ctx->int_flags & IO_RING_F_TASK_COMPLETE) ||
3005: (ctx->flags & IORING_SETUP_IOPOLL))
3006: ctx->int_flags |= IO_RING_F_LOCKLESS_CQ;
3007:
3008: /*
3009: * lazy poll_wq activation relies on ->task_complete for synchronisation
3010: * purposes, see io_activate_pollwq()
3011: */
3012: if (!(ctx->int_flags & IO_RING_F_TASK_COMPLETE))
3013: ctx->int_flags |= IO_RING_F_POLL_ACTIVATED;
3014:
3015: /*
3016: * When SETUP_IOPOLL and SETUP_SQPOLL are both enabled, user
3017: * space applications don't need to do io completion events
3018: * polling again, they can rely on io_sq_thread to do polling
3019: * work, which can reduce cpu usage and uring_lock contention.
3020: */
3021: if (ctx->flags & IORING_SETUP_IOPOLL &&
3022: !(ctx->flags & IORING_SETUP_SQPOLL))
3023: ctx->int_flags |= IO_RING_F_SYSCALL_IOPOLL;
3024:
3025: if (in_compat_syscall())
3026: ctx->int_flags |= IO_RING_F_COMPAT;
3027: if (!ns_capable_noaudit(&init_user_ns, CAP_IPC_LOCK))
3028: ctx->user = get_uid(current_user());
3029:
3030: /*
3031: * For SQPOLL, we just need a wakeup, always. For !SQPOLL, if
3032: * COOP_TASKRUN is set, then IPIs are never needed by the app.
3033: */
3034: if (ctx->flags & (IORING_SETUP_SQPOLL|IORING_SETUP_COOP_TASKRUN))
3035: ctx->notify_method = TWA_SIGNAL_NO_IPI;
3036: else
3037: ctx->notify_method = TWA_SIGNAL;
3038:
3039: /*
3040: * If the current task has restrictions enabled, then copy them to
3041: * our newly created ring and mark it as registered.
3042: */
3043: if (current->io_uring_restrict)
3044: io_ctx_restriction_clone(ctx, current->io_uring_restrict);
3045:
3046: /*
3047: * This is just grabbed for accounting purposes. When a process exits,
3048: * the mm is exited and dropped before the files, hence we need to hang
3049: * on to this mm purely for the purposes of being able to unaccount
3050: * memory (locked/pinned vm). It's not used for anything else.
3051: */
3052: mmgrab(current->mm);
3053: ctx->mm_account = current->mm;
3054:
3055: ret = io_allocate_scq_urings(ctx, config);
3056: if (ret)
3057: goto err;
3058:
3059: ret = io_sq_offload_create(ctx, p);
3060: if (ret)
3061: goto err;
3062:
3063: p->features = IORING_FEAT_FLAGS;
3064:
3065: if (copy_to_user(config->uptr, p, sizeof(*p))) {
3066: ret = -EFAULT;
3067: goto err;
3068: }
3069:
3070: if (ctx->flags & IORING_SETUP_SINGLE_ISSUER
3071: && !(ctx->flags & IORING_SETUP_R_DISABLED))
3072: ctx->submitter_task = get_task_struct(current);
3073:
3074: file = io_uring_get_file(ctx);
3075: if (IS_ERR(file)) {
3076: ret = PTR_ERR(file);
3077: goto err;
3078: }
3079:
3080: ret = __io_uring_add_tctx_node(ctx);
3081: if (ret)
3082: goto err_fput;
3083: tctx = current->io_uring;
3084:
3085: /*
3086: * Install ring fd as the very last thing, so we don't risk someone
3087: * having closed it before we finish setup
3088: */
3089: if (p->flags & IORING_SETUP_REGISTERED_FD_ONLY)
3090: ret = io_ring_add_registered_file(tctx, file, 0, IO_RINGFD_REG_MAX);
3091: else
3092: ret = io_uring_install_fd(file);
3093: if (ret < 0)
3094: goto err_fput;
3095:
3096: trace_io_uring_create(ret, ctx, p->sq_entries, p->cq_entries, p->flags);
3097: return ret;
3098: err:
3099: io_ring_ctx_wait_and_kill(ctx);
3100: return ret;
3101: err_fput:
3102: fput(file);
3103: return ret;
3104: }
SourceFile:io_uring/io_uring.c]
|
| 181/2 |
2026/06/12 22:39 |
llm |
expert |
0m
Model:
Tokens:
input: 103261
output: 49
thoughts: 601
Thoughts: **Analyzing a Potential File Descriptor Leak**
Okay, let's break this down. My initial thought was that `io_ring_add_registered_file` registers the file descriptor with `tctx->registered_rings`. Then, the ring file is in `tctx->registered_rings[0]` if `io_uring_setup` succeeds. When a task exits, we know that `io_uring_task_cancel` or `io_uring_unreg_ringfd` calls `fput` on those registered ring files. So far, so good.
But, the leaked file wasn't the ring file; it was `/dev/vbi3`. That threw me. Could `io_uring_setup` somehow be leaking `/dev/vbi3`?
No, wait. The code snippet shows `io_uring_setup` being called *before* `syz_open_dev`. The relevant calls are:
```c
res = syscall(__NR_io_uring_setup, /*entries=*/0x523, /*params=*/0x200000000040ul);
if (res != -1)
r[0] = res;
syz_open_dev(/*dev=*/0x200000000000, /*id=*/3, /*flags=*/2);
```
So when `io_uring_setup` runs, `/dev/vbi3` isn't even open yet! Therefore, `io_uring_setup` *cannot* leak that file.
Then, `syz_open_dev` opens `/dev/vbi3`, and *then* the `sendmsg` call is made with `fd=-1`. Following that, `io_uring_enter` is called with `fd=r[0]`.
Hmm, `io_uring_enter` *could* process SQEs. But the reproducer didn't write any SQEs! That's a key detail. Aha, I see! `IORING_SETUP_NO_MMAP` means the SQEs would be at `user_addr`. And the reproducer uses a `user_addr` of 0. That's it! `io_uring_setup` probably failed with `-EFAULT`!
If `io_uring_setup` failed, then `r[0]` would be `-1`. Then, `io_uring_enter` is called with `fd=-1`, and that call fails with `-EBADF`. Thus, `io_uring_enter` actually does nothing.
Wait a second, if `io_uring_setup` fails, and `io_uring_enter` fails, and `sendmsg` fails, then *the only operation that *could* succeed* is `syz_open_dev`!
Could `syz_open_dev` itself fail? I should investigate that, if it fails then it returns an error. The question is, if it fails, *does it leak the file descriptor*? Let me go back and re-examine the `v4l2_open` code... that's where the answer lies.
|
| 182/2 |
2026/06/12 22:40 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/media/v4l2-core/v4l2-dev.c Name:v4l2_open]
Results: map[SourceCode: 410: /* Override for the open function */
411: static int v4l2_open(struct inode *inode, struct file *filp)
412: {
413: struct video_device *vdev;
414: int ret;
415:
416: /* Check if the video device is available */
417: mutex_lock(&videodev_lock);
418: vdev = video_devdata(filp);
419: /* return ENODEV if the video device has already been removed. */
420: if (vdev == NULL || !video_is_registered(vdev)) {
421: mutex_unlock(&videodev_lock);
422: return -ENODEV;
423: }
424: /* and increase the device refcount */
425: video_get(vdev);
426: mutex_unlock(&videodev_lock);
427:
428: if (!video_is_registered(vdev)) {
429: ret = -ENODEV;
430: goto done;
431: }
432:
433: ret = vdev->fops->open(filp);
434: if (ret)
435: goto done;
436:
437: /* All drivers must use v4l2_fh. */
438: if (WARN_ON(!test_bit(V4L2_FL_USES_V4L2_FH, &vdev->flags))) {
439: vdev->fops->release(filp);
440: ret = -ENODEV;
441: }
442:
443: done:
444: if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
445: dprintk("%s: open (%d)\n",
446: video_device_node_name(vdev), ret);
447:
448: /* decrease the refcount in case of an error */
449: if (ret)
450: video_put(vdev);
451: return ret;
452: }
SourceFile:drivers/media/v4l2-core/v4l2-dev.c]
|
| 183/2 |
2026/06/12 22:40 |
llm |
expert |
0m
Model:
Tokens:
input: 105270
output: 51
thoughts: 84
Thoughts: **Analyzing Potential Resource Leakage in V4L2 Driver Initialization**
Okay, so I'm thinking about the standard `v4l2_open` function and how it handles errors. The `ret` value is the key here. If `v4l2_open` encounters a problem and returns an error code, the virtual filesystem (VFS) *should* take care of releasing the file pointer using `fput`. But, and this is the critical point... what if the *internal* `vdev->fops->open(filp)` function call *within* `v4l2_open` returns an error, but *also* has a subtle bug and leaks a reference to `filp`? I need to consider that scenario, because a simple error return from `v4l2_open` isn't necessarily a guarantee of complete resource cleanup in more complex drivers. That could mean a file descriptor is left in an unclosed state. I suspect that if it leaks a reference to filp, it will be the driver's responsibility to free the reference. It would be a subtle but nasty bug. Time to look into `v4l2_fh_open` and how it interacts with all of this; I need to understand the complete reference counting story in the V4L2 framework. I suspect there may be a resource leak in some error conditions, and `v4l2_fh_open` is the next place to look for that.
|
| 184/2 |
2026/06/12 22:40 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/media/v4l2-core/v4l2-fh.c Name:v4l2_fh_open]
Results: map[SourceCode: 57: int v4l2_fh_open(struct file *filp)
58: {
59: struct video_device *vdev = video_devdata(filp);
60: struct v4l2_fh *fh = kzalloc_obj(*fh);
61:
62: if (fh == NULL)
63: return -ENOMEM;
64: v4l2_fh_init(fh, vdev);
65: v4l2_fh_add(fh, filp);
66: return 0;
67: }
SourceFile:drivers/media/v4l2-core/v4l2-fh.c]
|
| 185/2 |
2026/06/12 22:40 |
llm |
expert |
0m
Model:
Tokens:
input: 105919
output: 48
thoughts: 115
Thoughts: **My Analysis of the V4L2 File Handle Opening Process**
Okay, so I'm looking at how `v4l2_fh_open` works, and from what I can see, it's pretty straightforward in terms of error handling. The only error it seems to throw is `-ENOMEM`. If it fails due to memory issues and returns that error code, it's designed to be clean; nothing is leaked. Simple and efficient.
That then means a return of 0 from `v4l2_fh_open` indicates success. In this case `v4l2_open` returns 0. I take it this signals to the VFS that all is well. Once the VFS gets that green light, it goes ahead and places the newly created file descriptor into the process's file descriptor table. Makes sense. Standard VFS behavior.
And finally, when the process gracefully exits, the VFS takes care of cleanup by calling `fput` on the file. That call then leads to the `fops->release` function, which in this particular scenario is resolved as `vivid_fop_release`. So the VFS is going to handle the cleanup automatically.
|
| 186/2 |
2026/06/12 22:40 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/media/test-drivers/vivid/vivid-core.c Name:vivid_fop_release]
Results: map[SourceCode: 640: static int vivid_fop_release(struct file *file)
641: {
642: struct vivid_dev *dev = video_drvdata(file);
643: struct video_device *vdev = video_devdata(file);
644:
645: mutex_lock(&dev->mutex);
646: if (!no_error_inj && v4l2_fh_is_singular_file(file) &&
647: dev->disconnect_error && !video_is_registered(vdev) &&
648: vivid_is_last_user(dev)) {
649: /*
650: * I am the last user of this driver, and a disconnect
651: * was forced (since this video_device is unregistered),
652: * so re-register all video_device's again.
653: */
654: v4l2_info(&dev->v4l2_dev, "reconnect\n");
655: vivid_reconnect(dev);
656: }
657: if (file_to_v4l2_fh(file) == dev->radio_rx_rds_owner) {
658: dev->radio_rx_rds_last_block = 0;
659: dev->radio_rx_rds_owner = NULL;
660: }
661: if (file_to_v4l2_fh(file) == dev->radio_tx_rds_owner) {
662: dev->radio_tx_rds_last_block = 0;
663: dev->radio_tx_rds_owner = NULL;
664: }
665: mutex_unlock(&dev->mutex);
666: if (vdev->queue)
667: return vb2_fop_release(file);
668: return v4l2_fh_release(file);
669: }
SourceFile:drivers/media/test-drivers/vivid/vivid-core.c]
|
| 187/2 |
2026/06/12 22:40 |
llm |
expert |
0m
Model:
Tokens:
input: 106914
output: 37
thoughts: 165
Thoughts: **Analyzing Potential File Leaks and io_uring Issues**
Okay, let's break this down. First, I need to make sure I'm following the file lifecycle correctly. `vivid_fop_release` calls either `vb2_fop_release(file)` or `v4l2_fh_release(file)`. The crucial question is, does this lead to a leak? No, because it's `fput` that ultimately handles freeing the file, isn't it? The `fops->release` function is simply a callback. So, if `fput` is invoked, the file is definitely freed. If a leak *does* occur, it has to mean that `fput` *wasn't* called, or somehow the reference count got messed up and incremented.
Now, let's shift gears. Can `io_uring_setup` somehow manage to *succeed* under unexpected conditions? A successful io_uring setup is what I'm interested in! I should check the case where I use `IORING_SETUP_NO_MMAP`. What if `user_addr` is zero when I call `io_create_region`? Does it fail then? I should investigate that scenario thoroughly.
|
| 188/2 |
2026/06/12 22:40 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/memmap.c Name:io_create_region]
Results: map[SourceCode: 184: int io_create_region(struct io_ring_ctx *ctx, struct io_mapped_region *mr,
185: struct io_uring_region_desc *reg,
186: unsigned long mmap_offset)
187: {
188: int nr_pages, ret;
189: u64 end;
190:
191: if (WARN_ON_ONCE(mr->pages || mr->ptr || mr->nr_pages))
192: return -EFAULT;
193: if (memchr_inv(®->__resv, 0, sizeof(reg->__resv)))
194: return -EINVAL;
195: if (reg->flags & ~IORING_MEM_REGION_TYPE_USER)
196: return -EINVAL;
197: /* user_addr should be set IFF it's a user memory backed region */
198: if ((reg->flags & IORING_MEM_REGION_TYPE_USER) != !!reg->user_addr)
199: return -EFAULT;
200: if (!reg->size || reg->mmap_offset || reg->id)
201: return -EINVAL;
202: if ((reg->size >> PAGE_SHIFT) > INT_MAX)
203: return -E2BIG;
204: if ((reg->user_addr | reg->size) & ~PAGE_MASK)
205: return -EINVAL;
206: if (check_add_overflow(reg->user_addr, reg->size, &end))
207: return -EOVERFLOW;
208:
209: nr_pages = reg->size >> PAGE_SHIFT;
210: if (ctx->user) {
211: ret = __io_account_mem(ctx->user, nr_pages);
212: if (ret)
213: return ret;
214: }
215: mr->nr_pages = nr_pages;
216:
217: if (reg->flags & IORING_MEM_REGION_TYPE_USER)
218: ret = io_region_pin_pages(mr, reg);
219: else
220: ret = io_region_allocate_pages(mr, reg, mmap_offset);
221: if (ret)
222: goto out_free;
223:
224: ret = io_region_init_ptr(mr);
225: if (ret)
226: goto out_free;
227: return 0;
228: out_free:
229: io_free_region(ctx->user, mr);
230: return ret;
231: }
SourceFile:io_uring/memmap.c]
|
| 189/2 |
2026/06/12 22:40 |
llm |
expert |
0m
Model:
Tokens:
input: 108189
output: 37
thoughts: 597
Thoughts: **Debugging a Persistent Kernel Issue**
Okay, let's break this down. First, that `-EFAULT` return from `io_create_region` in the `io_uring_setup` code is a major red flag. I see it stems from an inconsistency: the code is setting `IORING_MEM_REGION_TYPE_USER` in `reg->flags` but, because `p->cq_off.user_addr` is zero, `!!reg->user_addr` evaluates to zero. This discrepancy between the flag and the address being set *guarantees* that `io_uring_setup` will fail. So `io_uring` is a dead end for this particular issue.
Now, I'm pivoting to consider `sendmsg`. The `syscall` trace shows `sendmsg` being called with `fd = -1`. Of course it's failing with `-EBADF`. That's expected, and it doesn't give me any useful information.
Alright, the only *successful* syscall is `syz_open_dev`. I need to think about file descriptor leaks. Could `/dev/vbi3` be being opened, and somehow its file descriptor is being leaked?
If the process exits, I expect `do_exit` to handle the file descriptors with `exit_files`. I know `exit_files` calls `put_files_struct`, which then calls `close_files`, which iterates through open file descriptors and calls `filp_close`. `filp_close` calls `fput`. The key is whether `fput` *doesn't* get called, or whether the file refcount is incremented somehow.
Could the driver itself (`vivid`, in this case) be doing something to bump the file refcount on the file? I'm going to scan the `vivid` driver code again, looking for any instance of `get_file` or `fget` that might be called. I'm going to use grep. It's time to dig into the driver implementation and see what's going on.
|
| 190/2 |
2026/06/12 22:40 |
tool |
grepper |
0m
Error:
Args: map[Expression:get_file|fget PathPrefix:drivers/media/test-drivers/vivid/]
Results:
|
| 191/2 |
2026/06/12 22:40 |
llm |
expert |
0m
Model:
Tokens:
input: 109286
output: 37
thoughts: 13
Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience:
**Considering `v4l2-core` in the Context of... (assumed further context, not in the prompt)**
Okay, hold on a second. We're discussing [assumed context, needs to be inferred by the user - e.g., camera driver architecture, multimedia pipeline design, hardware abstraction layers, etc.] and I've been focused on [specific area/aspect]. But a critical piece I almost overlooked is `v4l2-core`. It’s the kernel's Video4Linux2 core, and I need to zoom in and consider how intimately our current approach interacts with it. Ignoring `v4l2-core` would be a significant oversight. The interactions, potential conflicts, and extension possibilities, all hinge on this foundational abstraction layer. I need to re-evaluate [a specific area] with `v4l2-core`'s role at the forefront of the analysis. Let's see how our approach fits and whether our proposed solution leverages or conflicts with it. I should have considered that from the start.
|
| 192/2 |
2026/06/12 22:40 |
tool |
grepper |
0m
Error:
Args: map[Expression:get_file|fget PathPrefix:drivers/media/v4l2-core/]
Results:
|
| 193/2 |
2026/06/12 22:40 |
llm |
expert |
0m
Model:
Tokens:
input: 109588
output: 35
thoughts: 46
Thoughts: Okay, let's see...
**Investigating File Handling in `v4l2-core`**
Hmm, so I was looking at the `v4l2-core` code, and I don't seem to be finding any calls to `fget` or `get_file` within this module directly. That's a bit odd, usually something like that would pop up pretty quickly if they were directly managing file descriptors. Perhaps they're using a different method, or maybe the file handling is abstracted away in a lower layer. Regardless, it's worth digging a bit deeper. I should check how `v4l2-core` handles file refcounts. If it's not using those functions, it must be doing something else to manage those pointers. Let me go through the module and see if I can find other refcount operations and understand how it's interacting with the underlying file structures.
|
| 194/2 |
2026/06/12 22:40 |
tool |
grepper |
0m
Error:
Args: map[Expression:->f_ref PathPrefix:drivers/media/v4l2-core/]
Results:
|
| 195/2 |
2026/06/12 22:40 |
llm |
expert |
0m
Model:
Tokens:
input: 109876
output: 37
thoughts: 257
Thoughts: **Investigating the File Descriptor Leak**
Okay, hold on a second. I need to rethink this. My initial assumption was that the leak was in `vivid` or `v4l2-core`, but what if I'm barking up the wrong tree entirely? What if the issue lies within `alloc_empty_file` itself? But no, that can't be it. `alloc_empty_file` is used everywhere; if it was leaking, the system would be imploding instantly.
Hmm... could there be something about the `sendmsg` call with `fd=-1`? Perhaps that’s related to the issue? No, wait a minute, `sockfd_lookup_light` immediately returns `-EBADF` if the file descriptor is negative. That's a dead end.
Right. I'm going to back up, and consider an alternative. What if the problem *isn't* the `syz_open_dev` function, as I initially thought? What if I'm missing something, and it's actually `prctl(PR_SET_MM_MAP)` that's leaking a file descriptor? I see in the code:
```c
*(uint32_t*)0x2000000000e4 = -1; // exe_fd
syscall(__NR_prctl, /*option=*/0x23ul, /*opt=*/0xeul, /*arg=*/0x200000000080ul, /*len=*/0x68ul, 0);
```
I need to look into `prctl_set_mm_map` more closely. That's where I should focus my attention now.
|
| 196/2 |
2026/06/12 22:40 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:kernel/sys.c Name:prctl_set_mm_map]
Results: map[SourceCode:2060: static int prctl_set_mm_map(int opt, const void __user *addr, unsigned long data_size)
2061: {
2062: struct prctl_mm_map prctl_map = { .exe_fd = (u32)-1, };
2063: unsigned long user_auxv[AT_VECTOR_SIZE];
2064: struct mm_struct *mm = current->mm;
2065: int error;
2066:
2067: BUILD_BUG_ON(sizeof(user_auxv) != sizeof(mm->saved_auxv));
2068: BUILD_BUG_ON(sizeof(struct prctl_mm_map) > 256);
2069:
2070: if (opt == PR_SET_MM_MAP_SIZE)
2071: return put_user((unsigned int)sizeof(prctl_map),
2072: (unsigned int __user *)addr);
2073:
2074: if (data_size != sizeof(prctl_map))
2075: return -EINVAL;
2076:
2077: if (copy_from_user(&prctl_map, addr, sizeof(prctl_map)))
2078: return -EFAULT;
2079:
2080: error = validate_prctl_map_addr(&prctl_map);
2081: if (error)
2082: return error;
2083:
2084: if (prctl_map.auxv_size) {
2085: /*
2086: * Someone is trying to cheat the auxv vector.
2087: */
2088: if (!prctl_map.auxv ||
2089: prctl_map.auxv_size > sizeof(mm->saved_auxv))
2090: return -EINVAL;
2091:
2092: memset(user_auxv, 0, sizeof(user_auxv));
2093: if (copy_from_user(user_auxv,
2094: (const void __user *)prctl_map.auxv,
2095: prctl_map.auxv_size))
2096: return -EFAULT;
2097:
2098: /* Last entry must be AT_NULL as specification requires */
2099: user_auxv[AT_VECTOR_SIZE - 2] = AT_NULL;
2100: user_auxv[AT_VECTOR_SIZE - 1] = AT_NULL;
2101: }
2102:
2103: if (prctl_map.exe_fd != (u32)-1) {
2104: /*
2105: * Check if the current user is checkpoint/restore capable.
2106: * At the time of this writing, it checks for CAP_SYS_ADMIN
2107: * or CAP_CHECKPOINT_RESTORE.
2108: * Note that a user with access to ptrace can masquerade an
2109: * arbitrary program as any executable, even setuid ones.
2110: * This may have implications in the tomoyo subsystem.
2111: */
2112: if (!checkpoint_restore_ns_capable(current_user_ns()))
2113: return -EPERM;
2114:
2115: error = prctl_set_mm_exe_file(mm, prctl_map.exe_fd);
2116: if (error)
2117: return error;
2118: }
2119:
2120: /*
2121: * arg_lock protects concurrent updates but we still need mmap_lock for
2122: * read to exclude races with sys_brk.
2123: */
2124: mmap_read_lock(mm);
2125:
2126: /*
2127: * We don't validate if these members are pointing to
2128: * real present VMAs because application may have correspond
2129: * VMAs already unmapped and kernel uses these members for statistics
2130: * output in procfs mostly, except
2131: *
2132: * - @start_brk/@brk which are used in do_brk_flags but kernel lookups
2133: * for VMAs when updating these members so anything wrong written
2134: * here cause kernel to swear at userspace program but won't lead
2135: * to any problem in kernel itself
2136: */
2137:
2138: spin_lock(&mm->arg_lock);
2139: mm->start_code = prctl_map.start_code;
2140: mm->end_code = prctl_map.end_code;
2141: mm->start_data = prctl_map.start_data;
2142: mm->end_data = prctl_map.end_data;
2143: mm->start_brk = prctl_map.start_brk;
2144: mm->brk = prctl_map.brk;
2145: mm->start_stack = prctl_map.start_stack;
2146: mm->arg_start = prctl_map.arg_start;
2147: mm->arg_end = prctl_map.arg_end;
2148: mm->env_start = prctl_map.env_start;
2149: mm->env_end = prctl_map.env_end;
2150: spin_unlock(&mm->arg_lock);
2151:
2152: /*
2153: * Note this update of @saved_auxv is lockless thus
2154: * if someone reads this member in procfs while we're
2155: * updating -- it may get partly updated results. It's
2156: * known and acceptable trade off: we leave it as is to
2157: * not introduce additional locks here making the kernel
2158: * more complex.
2159: */
2160: if (prctl_map.auxv_size)
2161: memcpy(mm->saved_auxv, user_auxv, sizeof(user_auxv));
2162:
2163: mmap_read_unlock(mm);
2164: return 0;
2165: }
SourceFile:kernel/sys.c]
|
| 197/2 |
2026/06/12 22:40 |
llm |
expert |
0m
Model:
Tokens:
input: 112326
output: 34
thoughts: 1873
Thoughts: **Analyzing a Potential Kernel Resource Leak**
Okay, let's break this down systematically. The initial hunch focused on a possible leak related to `prctl` and file descriptors, but since `prctl_map.exe_fd` is -1, `prctl_set_mm_exe_file` isn't called, so that's a dead end.
Now, the reproducer points to `/dev/vbi3`, and I'm trying to figure out how it could be leaked. The process flow seems to be `syz_open_dev`, followed by potential failures in `io_uring_setup`, `sendmsg`, and `io_uring_enter` before the process exits. The key question: could `/dev/vbi3` be leaked in this scenario?
I'm revisiting `vivid_fop_release`. There's no way that `vivid_fop_release` *wouldn't* be called, right? `fput` *always* calls `fops->release`. The reported BUG says the leaked object is the `struct file` itself. If `fput` is called, that object is supposed to be freed by `file_free_rcu` -> `kmem_cache_free`. A leak implies either `fput` wasn't called, or a reference count issue.
Could `io_uring_setup` somehow be incrementing the refcount on the `/dev/vbi3` file? Wait, `io_uring_setup` is *called before* `syz_open_dev`. It can't possibly know about the `/dev/vbi3` file at that point.
I'm looking at the reproducer again, specifically the `sendmsg` call. `sendmsg` is using `fd = -1`, so it fails immediately in `sockfd_lookup_light` because the file descriptor is empty. It doesn't even touch the message data. The same applies to `io_uring_enter`; `fd = r[0]`, where `r[0]` is the result of `io_uring_setup`. If `io_uring_setup` fails, `io_uring_enter` is called with `-1`, and it bails out in `fdget`.
Now, the critical question: could `io_uring_setup` succeed, even though it's failing? I'm re-examining the `io_uring_setup` arguments in the reproducer: the `flags` value is `0x1c080`. That means `IORING_SETUP_NO_MMAP` (0x4000), `IORING_SETUP_REGISTERED_FD_ONLY` (0x8000), and `IORING_SETUP_NO_SQARRAY` (0x10000) are all set. `user_addr` is at offset 72, which the reproducer doesn't seem to touch directly. However, the reproducer *does* map memory at `0x200000000000`. This memory is zero-initialized because of the mmap call with `MAP_ANONYMOUS`. So `user_addr` is effectively 0. With `IORING_SETUP_NO_MMAP` set *and* a `user_addr` of 0, `io_create_region` should return `-EFAULT`. So `io_uring_setup` *must* fail. I need to be sure; no kernel version should allow `IORING_SETUP_NO_MMAP` to work without `user_addr`.
Could the leak be something *other* than `/dev/vbi3`? Let me look at the earlier `socket` calls. The backtrace had `alloc_empty_file` from `path_openat`. Sockets are created by `sock_alloc_file`, which in turn calls `alloc_empty_file`. Does `sock_alloc_file` call `path_openat`? No! It calls `alloc_empty_file` directly. Need to look more closely at `sock_alloc_file`.
|
| 198/2 |
2026/06/12 22:41 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:net/socket.c Name:sock_alloc_file]
Results: map[SourceCode: 536: struct file *sock_alloc_file(struct socket *sock, int flags, const char *dname)
537: {
538: struct file *file;
539:
540: if (!dname)
541: dname = sock->sk ? sock->sk->sk_prot_creator->name : "";
542:
543: file = alloc_file_pseudo(SOCK_INODE(sock), sock_mnt, dname,
544: O_RDWR | (flags & O_NONBLOCK),
545: &socket_file_ops);
546: if (IS_ERR(file)) {
547: sock_release(sock);
548: return file;
549: }
550:
551: file->f_mode |= FMODE_NOWAIT;
552: sock->file = file;
553: file->private_data = sock;
554: stream_open(SOCK_INODE(sock), file);
555: /*
556: * Disable permission and pre-content events, but enable legacy
557: * inotify events for legacy users.
558: */
559: file_set_fsnotify_mode(file, FMODE_NONOTIFY_PERM);
560: return file;
561: }
SourceFile:net/socket.c]
|
| 199/2 |
2026/06/12 22:41 |
llm |
expert |
0m
Model:
Tokens:
input: 115545
output: 47
thoughts: 699
Thoughts: **Debugging a Persistent File Leak**
Okay, so I'm looking at this trace, and it's pretty clear: `alloc_empty_file` is definitely being called from `path_openat`. That means it's not a socket, and it's not related to io_uring. This narrows it down significantly – it *has* to be `/dev/vbi3`. But why is `/dev/vbi3` leaking? It shouldn't be.
Let's revisit `syz_open_dev`. I see the `open("/dev/vbi3", 2, 0)` call. This opens the file, gets a file descriptor, and then… the program exits. Standard stuff. At exit, `do_exit` should call `exit_files`, which *should* close all those file descriptors and decrease the refcount. So, if the file is leaking, it implies the refcount is being bumped and never decremented.
Where is this refcount being modified? The VIVID driver is suspect. Let me check the `vivid` driver's `open` function. That's `v4l2_fh_open`, and I've already scrutinized it; it doesn't touch the refcount. Wait, but what about `v4l2_open`? Aha! There's a `video_get(vdev)` call, which increments the refcount. But hang on... it's the `struct video_device`'s refcount, NOT the file struct. That's a red herring.
Okay, let me backtrack. Is there *any* other place where the refcount might be touched? What if there's a kernel thread created by the `vivid` driver that keeps a reference to the file? Let me examine `vivid_create_instance`.
|
| 200/2 |
2026/06/12 22:41 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/media/test-drivers/vivid/vivid-core.c Name:vivid_create_instance]
Results: map[SourceCode:1800: static int vivid_create_instance(struct platform_device *pdev, int inst)
1801: {
1802: static const struct v4l2_dv_timings def_dv_timings =
1803: V4L2_DV_BT_CEA_1280X720P60;
1804: unsigned in_type_counter[4] = { 0, 0, 0, 0 };
1805: unsigned out_type_counter[4] = { 0, 0, 0, 0 };
1806: int ccs_cap = ccs_cap_mode[inst];
1807: int ccs_out = ccs_out_mode[inst];
1808: bool has_tuner;
1809: bool has_modulator;
1810: struct vivid_dev *dev;
1811: unsigned node_type = node_types[inst];
1812: v4l2_std_id tvnorms_cap = 0, tvnorms_out = 0;
1813: int ret;
1814: int i;
1815:
1816: /* allocate main vivid state structure */
1817: dev = kzalloc_obj(*dev);
1818: if (!dev)
1819: return -ENOMEM;
1820:
1821: dev->inst = inst;
1822:
1823: #ifdef CONFIG_MEDIA_CONTROLLER
1824: dev->v4l2_dev.mdev = &dev->mdev;
1825:
1826: /* Initialize media device */
1827: strscpy(dev->mdev.model, VIVID_MODULE_NAME, sizeof(dev->mdev.model));
1828: snprintf(dev->mdev.bus_info, sizeof(dev->mdev.bus_info),
1829: "platform:%s-%03d", VIVID_MODULE_NAME, inst);
1830: dev->mdev.dev = &pdev->dev;
1831: media_device_init(&dev->mdev);
1832: dev->mdev.ops = &vivid_media_ops;
1833: #endif
1834:
1835: /* register v4l2_device */
1836: snprintf(dev->v4l2_dev.name, sizeof(dev->v4l2_dev.name),
1837: "%s-%03d", VIVID_MODULE_NAME, inst);
1838: ret = v4l2_device_register(&pdev->dev, &dev->v4l2_dev);
1839: if (ret) {
1840: kfree(dev);
1841: return ret;
1842: }
1843: dev->v4l2_dev.release = vivid_dev_release;
1844:
1845: ret = vivid_detect_feature_set(dev, inst, node_type,
1846: &has_tuner, &has_modulator,
1847: &ccs_cap, &ccs_out,
1848: in_type_counter, out_type_counter);
1849: if (ret)
1850: goto free_dev;
1851:
1852: vivid_set_capabilities(dev);
1853:
1854: ret = -ENOMEM;
1855: /* initialize the test pattern generator */
1856: tpg_init(&dev->tpg, 640, 360);
1857: if (tpg_alloc(&dev->tpg, array_size(MAX_WIDTH, MAX_ZOOM)))
1858: goto free_dev;
1859: dev->scaled_line = vcalloc(MAX_WIDTH, MAX_ZOOM);
1860: if (!dev->scaled_line)
1861: goto free_dev;
1862: dev->blended_line = vcalloc(MAX_WIDTH, MAX_ZOOM);
1863: if (!dev->blended_line)
1864: goto free_dev;
1865:
1866: /* load the edid */
1867: dev->edid = vmalloc_array(256, 128);
1868: if (!dev->edid)
1869: goto free_dev;
1870:
1871: ret = vivid_init_dv_timings(dev);
1872: if (ret < 0)
1873: goto free_dev;
1874:
1875: vivid_disable_unused_ioctls(dev, has_tuner, has_modulator,
1876: in_type_counter, out_type_counter);
1877:
1878: /* configure internal data */
1879: dev->fmt_cap = &vivid_formats[0];
1880: dev->fmt_out = &vivid_formats[0];
1881: if (!dev->multiplanar)
1882: vivid_formats[0].data_offset[0] = 0;
1883: dev->webcam_size_idx = 1;
1884: dev->webcam_ival_idx = 3;
1885: tpg_s_fourcc(&dev->tpg, dev->fmt_cap->fourcc);
1886: dev->std_out = V4L2_STD_PAL;
1887: if (dev->input_type[0] == TV || dev->input_type[0] == SVID)
1888: tvnorms_cap = V4L2_STD_ALL;
1889: if (dev->output_type[0] == SVID)
1890: tvnorms_out = V4L2_STD_ALL;
1891: for (i = 0; i < MAX_INPUTS; i++) {
1892: dev->dv_timings_cap[i] = def_dv_timings;
1893: dev->std_cap[i] = V4L2_STD_PAL;
1894: }
1895: dev->dv_timings_out = def_dv_timings;
1896: dev->tv_freq = 2804 /* 175.25 * 16 */;
1897: dev->tv_audmode = V4L2_TUNER_MODE_STEREO;
1898: dev->tv_field_cap = V4L2_FIELD_INTERLACED;
1899: dev->tv_field_out = V4L2_FIELD_INTERLACED;
1900: dev->radio_rx_freq = 95000 * 16;
1901: dev->radio_rx_audmode = V4L2_TUNER_MODE_STEREO;
1902: if (dev->has_radio_tx) {
1903: dev->radio_tx_freq = 95500 * 16;
1904: dev->radio_rds_loop = false;
1905: }
1906: dev->radio_tx_subchans = V4L2_TUNER_SUB_STEREO | V4L2_TUNER_SUB_RDS;
1907: dev->sdr_adc_freq = 300000;
1908: dev->sdr_fm_freq = 50000000;
1909: dev->sdr_pixelformat = V4L2_SDR_FMT_CU8;
1910: dev->sdr_buffersize = SDR_CAP_SAMPLES_PER_BUF * 2;
1911:
1912: dev->edid_max_blocks = dev->edid_blocks = 2;
1913: memcpy(dev->edid, vivid_hdmi_edid, sizeof(vivid_hdmi_edid));
1914: dev->radio_rds_init_time = ktime_get();
1915: INIT_WORK(&dev->update_hdmi_ctrl_work, update_hdmi_ctrls_work_handler);
1916: INIT_WORK(&dev->update_svid_ctrl_work, update_svid_ctrls_work_handler);
1917: for (int j = 0, k = 0; j < dev->num_inputs; ++j)
1918: if (dev->input_type[j] == HDMI)
1919: dev->hdmi_index_to_input_index[k++] = j;
1920: for (int j = 0, k = 0; j < dev->num_outputs; ++j)
1921: if (dev->output_type[j] == HDMI) {
1922: dev->output_to_iface_index[j] = k;
1923: dev->hdmi_index_to_output_index[k++] = j;
1924: }
1925: for (int j = 0, k = 0; j < dev->num_inputs; ++j)
1926: if (dev->input_type[j] == SVID)
1927: dev->svid_index_to_input_index[k++] = j;
1928: for (int j = 0, k = 0; j < dev->num_outputs; ++j)
1929: if (dev->output_type[j] == SVID)
1930: dev->output_to_iface_index[j] = k++;
1931:
1932: /* create all controls */
1933: ret = vivid_create_controls(dev, ccs_cap == -1, ccs_out == -1, no_error_inj,
1934: in_type_counter[TV] || in_type_counter[SVID] ||
1935: out_type_counter[SVID],
1936: in_type_counter[HDMI] || out_type_counter[HDMI]);
1937: if (ret)
1938: goto unreg_dev;
1939:
1940: /* enable/disable interface specific controls */
1941: if (dev->num_inputs && dev->input_type[0] != HDMI) {
1942: v4l2_ctrl_activate(dev->ctrl_dv_timings_signal_mode, false);
1943: v4l2_ctrl_activate(dev->ctrl_dv_timings, false);
1944: } else if (dev->num_inputs && dev->input_type[0] == HDMI) {
1945: v4l2_ctrl_activate(dev->ctrl_std_signal_mode, false);
1946: v4l2_ctrl_activate(dev->ctrl_standard, false);
1947: }
1948:
1949: /*
1950: * update the capture and output formats to do a proper initial
1951: * configuration.
1952: */
1953: vivid_update_format_cap(dev, false);
1954: vivid_update_format_out(dev);
1955:
1956: /* update touch configuration */
1957: dev->timeperframe_tch_cap.numerator = 1;
1958: dev->timeperframe_tch_cap.denominator = 10;
1959: vivid_set_touch(dev, 0);
1960:
1961: /* initialize locks */
1962: spin_lock_init(&dev->slock);
1963: mutex_init(&dev->mutex);
1964:
1965: /* init dma queues */
1966: INIT_LIST_HEAD(&dev->vid_cap_active);
1967: INIT_LIST_HEAD(&dev->vid_out_active);
1968: INIT_LIST_HEAD(&dev->vbi_cap_active);
1969: INIT_LIST_HEAD(&dev->vbi_out_active);
1970: INIT_LIST_HEAD(&dev->sdr_cap_active);
1971: INIT_LIST_HEAD(&dev->meta_cap_active);
1972: INIT_LIST_HEAD(&dev->meta_out_active);
1973: INIT_LIST_HEAD(&dev->touch_cap_active);
1974:
1975: spin_lock_init(&dev->cec_xfers_slock);
1976:
1977: if (allocators[inst] == 1)
1978: dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
1979:
1980: ret = vivid_create_queues(dev);
1981: if (ret)
1982: goto unreg_dev;
1983:
1984: #ifdef CONFIG_VIDEO_VIVID_CEC
1985: if (dev->has_vid_cap && in_type_counter[HDMI]) {
1986: struct cec_adapter *adap;
1987:
1988: adap = vivid_cec_alloc_adap(dev, 0, false);
1989: ret = PTR_ERR_OR_ZERO(adap);
1990: if (ret < 0)
1991: goto unreg_dev;
1992: dev->cec_rx_adap = adap;
1993: }
1994:
1995: if (dev->has_vid_out) {
1996: int j;
1997:
1998: for (i = j = 0; i < dev->num_outputs; i++) {
1999: struct cec_adapter *adap;
2000:
2001: if (dev->output_type[i] != HDMI)
2002: continue;
2003:
2004: adap = vivid_cec_alloc_adap(dev, j, true);
2005: ret = PTR_ERR_OR_ZERO(adap);
2006: if (ret < 0) {
2007: while (j--)
2008: cec_delete_adapter(dev->cec_tx_adap[j]);
2009: goto unreg_dev;
2010: }
2011:
2012: dev->cec_tx_adap[j++] = adap;
2013: }
2014: }
2015:
2016: if (dev->cec_rx_adap || dev->num_hdmi_outputs) {
2017: init_waitqueue_head(&dev->kthread_waitq_cec);
2018: dev->kthread_cec = kthread_run(vivid_cec_bus_thread, dev,
2019: "vivid_cec-%s", dev->v4l2_dev.name);
2020: if (IS_ERR(dev->kthread_cec)) {
2021: ret = PTR_ERR(dev->kthread_cec);
2022: dev->kthread_cec = NULL;
2023: v4l2_err(&dev->v4l2_dev, "kernel_thread() failed\n");
2024: goto unreg_dev;
2025: }
2026: }
2027:
2028: #endif
2029:
2030: v4l2_ctrl_handler_setup(&dev->ctrl_hdl_vid_cap);
2031: v4l2_ctrl_handler_setup(&dev->ctrl_hdl_vid_out);
2032: v4l2_ctrl_handler_setup(&dev->ctrl_hdl_vbi_cap);
2033: v4l2_ctrl_handler_setup(&dev->ctrl_hdl_vbi_out);
2034: v4l2_ctrl_handler_setup(&dev->ctrl_hdl_radio_rx);
2035: v4l2_ctrl_handler_setup(&dev->ctrl_hdl_radio_tx);
2036: v4l2_ctrl_handler_setup(&dev->ctrl_hdl_sdr_cap);
2037: v4l2_ctrl_handler_setup(&dev->ctrl_hdl_meta_cap);
2038: v4l2_ctrl_handler_setup(&dev->ctrl_hdl_meta_out);
2039: v4l2_ctrl_handler_setup(&dev->ctrl_hdl_touch_cap);
2040:
2041: /* finally start creating the device nodes */
2042: ret = vivid_create_devnodes(pdev, dev, inst,
2043: tvnorms_cap, tvnorms_out,
2044: in_type_counter, out_type_counter);
2045: if (ret)
2046: goto unreg_dev;
2047:
2048: /* Now that everything is fine, let's add it to device list */
2049: vivid_devs[inst] = dev;
2050:
2051: return 0;
2052:
2053: unreg_dev:
2054: vb2_video_unregister_device(&dev->touch_cap_dev);
2055: vb2_video_unregister_device(&dev->meta_out_dev);
2056: vb2_video_unregister_device(&dev->meta_cap_dev);
2057: video_unregister_device(&dev->radio_tx_dev);
2058: video_unregister_device(&dev->radio_rx_dev);
2059: vb2_video_unregister_device(&dev->sdr_cap_dev);
2060: vb2_video_unregister_device(&dev->vbi_out_dev);
2061: vb2_video_unregister_device(&dev->vbi_cap_dev);
2062: vb2_video_unregister_device(&dev->vid_out_dev);
2063: vb2_video_unregister_device(&dev->vid_cap_dev);
2064: cec_unregister_adapter(dev->cec_rx_adap);
2065: for (i = 0; i < MAX_HDMI_OUTPUTS; i++)
2066: cec_unregister_adapter(dev->cec_tx_adap[i]);
2067: if (dev->kthread_cec)
2068: kthread_stop(dev->kthread_cec);
2069: free_dev:
2070: v4l2_device_put(&dev->v4l2_dev);
2071: return ret;
2072: }
SourceFile:drivers/media/test-drivers/vivid/vivid-core.c]
|
| 201/2 |
2026/06/12 22:41 |
llm |
expert |
0m
Model:
Tokens:
input: 121790
output: 37
thoughts: 2446
Thoughts: **Analyzing a Potential File Leak in the vivid Driver**
Okay, so the initial hypothesis pointed towards a possible leak from the `vivid_cec_bus_thread`, specifically if it somehow retained a reference to the file. But a quick re-examination shows it's a reference to the device, not the file itself, so scratch that.
Now, let's assume the leak isn't `/dev/vbi3`. Could it be the socket? A deep dive into `sock_alloc_file` pointed me down a path that calls `alloc_file_pseudo`, which in turn calls `alloc_empty_file` but crucially *doesn't* call `path_openat`. The bug report's backtrace is pretty clear: it shows a standard `openat` syscall, which maps directly to the reproducer's call to `open("/dev/vbi3", O_RDWR, 0)`. That confirms the leaked file IS `/dev/vbi3`.
The question becomes *why* is `/dev/vbi3` being leaked? Is there a subtle bug in the `vivid` driver? Let's scrutinize `vivid_fop_release`. The function is called on file closure, which means if it's leaked, the release function *won't* get called because the reference count never hits zero. The file is being leaked because its reference count got incremented somewhere and wasn't properly decremented.
Where can a file's reference count be incremented? Let's make a list:
1. `get_file(file)`
2. `fget(fd)`
3. `fdget(fd)` (but `fdput` must be called to decrement it)
4. `io_uring` registering the file descriptor
5. `SCM_RIGHTS` (passing file descriptors through sockets)
6. `bpf` maps (less likely in this context, but worth keeping in mind)
Now, could the `io_uring_setup` have actually succeeded in some way? Let's re-examine that specific call. The reproducer sets flags to `0x1c080` or `IORING_SETUP_NO_SQARRAY | IORING_SETUP_REGISTERED_FD_ONLY | IORING_SETUP_NO_MMAP | IORING_SETUP_SUBMIT_ALL`. When `IORING_SETUP_NO_MMAP` is set, `user_addr` must be valid. The reproducer sets up a mapping at `0x200000000000` with a size of `0x1000000`. `io_uring_params` is at `0x200000000040`. `sq_off.user_addr` resides at `0x200000000088`.
Hold on, the reproducer's code writes *to* `0x200000000088`! It turns out these values are initially written for `prctl` before being overwritten for `sendmsg`. Crucially, right before `io_uring_setup`, the reproducer sets `*(uint32_t*)0x200000000088 = 0;`. This wipes the 8 bytes for `sq_off.user_addr`, setting it to zero! The same happens with `cq_off.user_addr` which is zero as well. Looking at `io_create_region` again, if `user_addr` is zero and `IORING_MEM_REGION_TYPE_USER` is set, it returns `-EFAULT`. So, `io_uring_setup` *must* fail, right? No, let's explore this further.
|
| 202/2 |
2026/06/12 22:41 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/memmap.c Name:io_create_region]
Results: map[SourceCode: 184: int io_create_region(struct io_ring_ctx *ctx, struct io_mapped_region *mr,
185: struct io_uring_region_desc *reg,
186: unsigned long mmap_offset)
187: {
188: int nr_pages, ret;
189: u64 end;
190:
191: if (WARN_ON_ONCE(mr->pages || mr->ptr || mr->nr_pages))
192: return -EFAULT;
193: if (memchr_inv(®->__resv, 0, sizeof(reg->__resv)))
194: return -EINVAL;
195: if (reg->flags & ~IORING_MEM_REGION_TYPE_USER)
196: return -EINVAL;
197: /* user_addr should be set IFF it's a user memory backed region */
198: if ((reg->flags & IORING_MEM_REGION_TYPE_USER) != !!reg->user_addr)
199: return -EFAULT;
200: if (!reg->size || reg->mmap_offset || reg->id)
201: return -EINVAL;
202: if ((reg->size >> PAGE_SHIFT) > INT_MAX)
203: return -E2BIG;
204: if ((reg->user_addr | reg->size) & ~PAGE_MASK)
205: return -EINVAL;
206: if (check_add_overflow(reg->user_addr, reg->size, &end))
207: return -EOVERFLOW;
208:
209: nr_pages = reg->size >> PAGE_SHIFT;
210: if (ctx->user) {
211: ret = __io_account_mem(ctx->user, nr_pages);
212: if (ret)
213: return ret;
214: }
215: mr->nr_pages = nr_pages;
216:
217: if (reg->flags & IORING_MEM_REGION_TYPE_USER)
218: ret = io_region_pin_pages(mr, reg);
219: else
220: ret = io_region_allocate_pages(mr, reg, mmap_offset);
221: if (ret)
222: goto out_free;
223:
224: ret = io_region_init_ptr(mr);
225: if (ret)
226: goto out_free;
227: return 0;
228: out_free:
229: io_free_region(ctx->user, mr);
230: return ret;
231: }
SourceFile:io_uring/memmap.c]
|
| 203/2 |
2026/06/12 22:41 |
llm |
expert |
0m
Model:
Tokens:
input: 125912
output: 35
thoughts: 332
Thoughts: **Analyzing Potential File Descriptor Leaks**
Okay, so I'm diving into this `io_uring_setup` failure. The code clearly states, `if ((reg->flags & IORING_MEM_REGION_TYPE_USER) != !!reg->user_addr) return -EFAULT;`. Right, so if `IORING_MEM_REGION_TYPE_USER` is set in `reg->flags` (which will be 1), and `reg->user_addr` is zero, we get `1 != 0`, which is true. Therefore, `io_uring_setup` fails with an `-EFAULT`. That's locked down.
The only system call that seems to succeed is `syz_open_dev`. But hold on, can *that* fail? If `syz_open_dev` returns `-1`, we have a problem.
Now the million-dollar question: If it fails, does it leak the file descriptor? Let's refresh our memory of the `open` behavior. It returns an error code on failure. We need to go back and check the `do_sys_openat2` logic. Let's look again: `return FD_ADD(how->flags, do_file_open(dfd, name, &op));`. Okay, if `do_file_open` returns an error pointer, `FD_ADD` returns the error, and there's a destructor that *should* call `fput` if the file is valid. But hang on, since the return from `do_file_open` is an error pointer, `IS_ERR_OR_NULL` is true. Therefore, `fput` is *not* called. Which means there might be a leak.
Now I have to think about what `do_file_open` does. If `do_file_open` returns an error pointer, that means the file wasn't allocated, or it got freed already! That's the key. I need to examine the `do_file_open` function closely to see how it handles errors and potential resource leaks.
|
| 204/2 |
2026/06/12 22:41 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/namei.c Name:do_file_open]
Results: map[SourceCode:4877: struct file *do_file_open(int dfd, struct filename *pathname,
4878: const struct open_flags *op)
4879: {
4880: struct nameidata nd;
4881: int flags = op->lookup_flags;
4882: struct file *filp;
4883:
4884: if (IS_ERR(pathname))
4885: return ERR_CAST(pathname);
4886: set_nameidata(&nd, dfd, pathname, NULL);
4887: filp = path_openat(&nd, op, flags | LOOKUP_RCU);
4888: if (unlikely(filp == ERR_PTR(-ECHILD)))
4889: filp = path_openat(&nd, op, flags);
4890: if (unlikely(filp == ERR_PTR(-ESTALE)))
4891: filp = path_openat(&nd, op, flags | LOOKUP_REVAL);
4892: restore_nameidata();
4893: return filp;
4894: }
SourceFile:fs/namei.c]
|
| 205/2 |
2026/06/12 22:41 |
llm |
expert |
0m
Model:
Tokens:
input: 127055
output: 34
thoughts: 10
Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and presented as if it were my own internal monologue:
**File Allocation within `path_openat`**
Right, so we're talking about `path_openat`. My initial thought, of course, is the resource allocation that happens when this function is called. The core is the file itself. Specifically, the line that states `path_openat` allocates the file. It's a fundamental part of the operation, the allocation of the file structure itself is a critical step in the process. It's not just a pointer or descriptor, but the foundational data structure representing the open file, the one that holds the various metadata, state, and other vital information required for I/O operations. It's the point where we begin to interact with the kernel’s internal file representation. Before allocation, there's nothing, now we have the kernel representation of the file. And that's what `path_openat` does at its core, from a resource management perspective. It's the critical first step.
|
| 206/2 |
2026/06/12 22:41 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/namei.c Name:path_openat]
Results: map[SourceCode:4838: static struct file *path_openat(struct nameidata *nd,
4839: const struct open_flags *op, unsigned flags)
4840: {
4841: struct file *file;
4842: int error;
4843:
4844: file = alloc_empty_file(op->open_flag, current_cred());
4845: if (IS_ERR(file))
4846: return file;
4847:
4848: if (unlikely(file->f_flags & __O_TMPFILE)) {
4849: error = do_tmpfile(nd, flags, op, file);
4850: } else if (unlikely(file->f_flags & O_PATH)) {
4851: error = do_o_path(nd, flags, file);
4852: } else {
4853: const char *s = path_init(nd, flags);
4854: while (!(error = link_path_walk(s, nd)) &&
4855: (s = open_last_lookups(nd, file, op)) != NULL)
4856: ;
4857: if (!error)
4858: error = do_open(nd, file, op);
4859: terminate_walk(nd);
4860: }
4861: if (likely(!error)) {
4862: if (likely(file->f_mode & FMODE_OPENED))
4863: return file;
4864: WARN_ON(1);
4865: error = -EINVAL;
4866: }
4867: fput_close(file);
4868: if (error == -EOPENSTALE) {
4869: if (flags & LOOKUP_RCU)
4870: error = -ECHILD;
4871: else
4872: error = -ESTALE;
4873: }
4874: return ERR_PTR(error);
4875: }
SourceFile:fs/namei.c]
|
| 207/2 |
2026/06/12 22:41 |
llm |
expert |
0m
Model:
Tokens:
input: 127919
output: 35
thoughts: 57
Thoughts: Okay, let me break this down.
**Diving into the File Handling Logic**
Right, so I'm tracing through this code, and it looks like `path_openat` is calling `alloc_empty_file`. Got it. Then, I see a conditional: if `error` isn't zero, it immediately jumps to `fput_close(file)`. That's a familiar pattern – cleanup on error. But hold on a second... `fput_close`? I need to refresh my memory on the exact functionality of `fput_close`. Let me just quickly check that definition...
|
| 208/2 |
2026/06/12 22:41 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/file_table.c Name:fput_close]
Results: map[SourceCode: 618: /*
619: * Equivalent to fput(), but optimized for being called with the last
620: * reference.
621: *
622: * See file_ref_put_close() for details.
623: */
624: void fput_close(struct file *file)
625: {
626: if (file_ref_put_close(&file->f_ref))
627: __fput_deferred(file);
628: }
SourceFile:fs/file_table.c]
|
| 209/2 |
2026/06/12 22:41 |
llm |
expert |
0m
Model:
Tokens:
input: 128319
output: 33
thoughts: 60
Thoughts: **Refcount Confusion**
Okay, hold on a second. I'm following the logic through `file_ref_put_close`, and it's definitely decrementing the reference count. If that count hits zero, it triggers `__fput_deferred`. The problem is, I need to know how the reference count is being modified upstream, because if `do_open` is incrementing the refcount, then I have to worry about a potential race condition. Let me quickly jump into `do_open` and make sure my understanding of its refcount interaction is correct. Gotta be absolutely certain about this.
|
| 210/2 |
2026/06/12 22:41 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/namei.c Name:do_open]
Results: map[SourceCode:4652: /*
4653: * Handle the last step of open()
4654: */
4655: static int do_open(struct nameidata *nd,
4656: struct file *file, const struct open_flags *op)
4657: {
4658: struct mnt_idmap *idmap;
4659: int open_flag = op->open_flag;
4660: bool do_truncate;
4661: int acc_mode;
4662: int error;
4663:
4664: if (!(file->f_mode & (FMODE_OPENED | FMODE_CREATED))) {
4665: error = complete_walk(nd);
4666: if (error)
4667: return error;
4668: }
4669: if (!(file->f_mode & FMODE_CREATED))
4670: audit_inode(nd->name, nd->path.dentry, 0);
4671: idmap = mnt_idmap(nd->path.mnt);
4672: if (open_flag & O_CREAT) {
4673: if ((open_flag & O_EXCL) && !(file->f_mode & FMODE_CREATED))
4674: return -EEXIST;
4675: if (d_is_dir(nd->path.dentry))
4676: return -EISDIR;
4677: error = may_create_in_sticky(idmap, nd,
4678: d_backing_inode(nd->path.dentry));
4679: if (unlikely(error))
4680: return error;
4681: }
4682: if ((nd->flags & LOOKUP_DIRECTORY) && !d_can_lookup(nd->path.dentry))
4683: return -ENOTDIR;
4684:
4685: do_truncate = false;
4686: acc_mode = op->acc_mode;
4687: if (file->f_mode & FMODE_CREATED) {
4688: /* Don't check for write permission, don't truncate */
4689: open_flag &= ~O_TRUNC;
4690: acc_mode = 0;
4691: } else if (d_is_reg(nd->path.dentry) && open_flag & O_TRUNC) {
4692: error = mnt_want_write(nd->path.mnt);
4693: if (error)
4694: return error;
4695: do_truncate = true;
4696: }
4697: error = may_open(idmap, &nd->path, acc_mode, open_flag);
4698: if (!error && !(file->f_mode & FMODE_OPENED))
4699: error = vfs_open(&nd->path, file);
4700: if (!error)
4701: error = security_file_post_open(file, op->acc_mode);
4702: if (!error && do_truncate)
4703: error = handle_truncate(idmap, file);
4704: if (unlikely(error > 0)) {
4705: WARN_ON(1);
4706: error = -EINVAL;
4707: }
4708: if (do_truncate)
4709: mnt_drop_write(nd->path.mnt);
4710: return error;
4711: }
SourceFile:fs/namei.c]
|
| 211/2 |
2026/06/12 22:41 |
llm |
expert |
0m
Model:
Tokens:
input: 129533
output: 33
thoughts: 12
Thoughts: Here's my understanding of the situation, given my expertise:
**My Perspective on the `do_open` and `vfs_open` Relationship**
Okay, so I'm looking at this `do_open` function call. My gut reaction is to instantly think about how this plays into the overall file system architecture. And right away, my expertise tells me that `do_open` *is* calling `vfs_open`. That's not surprising at all. In fact, it's what I'd expect. `vfs_open` is the Virtual File System (VFS) layer's entry point for opening files. It acts as the key abstraction, shielding the user-level system calls like `open()` from the specifics of different underlying file systems (ext4, XFS, etc.). `do_open` is, in all likelihood, the kernel's implementation of the `open()` system call, so it makes perfect sense that it would then hand off the hard work of file system lookups, permission checks, and inode/dentry handling to the VFS through `vfs_open`. It is the crucial translation layer for that.
|
| 212/2 |
2026/06/12 22:41 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/open.c Name:vfs_open]
Results: map[SourceCode:1069: /**
1070: * vfs_open - open the file at the given path
1071: * @path: path to open
1072: * @file: newly allocated file with f_flag initialized
1073: */
1074: int vfs_open(const struct path *path, struct file *file)
1075: {
1076: int ret;
1077:
1078: file->__f_path = *path;
1079: ret = do_dentry_open(file, NULL);
1080: if (!ret) {
1081: /*
1082: * Once we return a file with FMODE_OPENED, __fput() will call
1083: * fsnotify_close(), so we need fsnotify_open() here for
1084: * symmetry.
1085: */
1086: fsnotify_open(file);
1087: }
1088: return ret;
1089: }
SourceFile:fs/open.c]
|
| 213/2 |
2026/06/12 22:41 |
llm |
expert |
0m
Model:
Tokens:
input: 130133
output: 35
thoughts: 15
Thoughts: Okay, here's my interpretation of that thought process, from an expert's perspective:
**Diving into the Filesystem: A Quick Run-Down of `vfs_open` and `do_dentry_open`**
Right, so, `vfs_open`. That's where it all starts, isn't it? When a process calls `open()`, the Virtual File System (VFS) layer intercepts the call. My mental map immediately jumps to the standard VFS entry point. It's the gatekeeper, the intermediary. It's the function that handles the high-level request, parses the path, and figures out which filesystem driver needs to be involved. I know it handles things like permission checks, translating flags, and all that initial setup. I think of it as the initial call in the "open" process.
And then, boom, within that, the key is the subsequent call to `do_dentry_open`. That's the real meat of the matter. `do_dentry_open` is the workhorse of the VFS, that's where the heavy lifting occurs and the low-level work is being done. It's where the dentry gets involved, where the filesystem actually gets accessed through its own methods.
This makes total sense. `vfs_open` is the "I've got a request," and `do_dentry_open` is the "okay, let's actually *do* this" part.
|
| 214/2 |
2026/06/12 22:42 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/open.c Name:do_dentry_open]
Results: map[SourceCode: 885: static int do_dentry_open(struct file *f,
886: int (*open)(struct inode *, struct file *))
887: {
888: static const struct file_operations empty_fops = {};
889: struct inode *inode = f->f_path.dentry->d_inode;
890: int error;
891:
892: path_get(&f->f_path);
893: f->f_inode = inode;
894: f->f_mapping = inode->i_mapping;
895: f->f_wb_err = filemap_sample_wb_err(f->f_mapping);
896: f->f_sb_err = file_sample_sb_err(f);
897:
898: if (unlikely(f->f_flags & O_PATH)) {
899: f->f_mode = FMODE_PATH | FMODE_OPENED;
900: file_set_fsnotify_mode(f, FMODE_NONOTIFY);
901: f->f_op = &empty_fops;
902: return 0;
903: }
904:
905: if ((f->f_mode & (FMODE_READ | FMODE_WRITE)) == FMODE_READ) {
906: i_readcount_inc(inode);
907: } else if (f->f_mode & FMODE_WRITE && !special_file(inode->i_mode)) {
908: error = file_get_write_access(f);
909: if (unlikely(error))
910: goto cleanup_file;
911: f->f_mode |= FMODE_WRITER;
912: }
913:
914: /* POSIX.1-2008/SUSv4 Section XSI 2.9.7 */
915: if (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode))
916: f->f_mode |= FMODE_ATOMIC_POS;
917:
918: f->f_op = fops_get(inode->i_fop);
919: if (WARN_ON(!f->f_op)) {
920: error = -ENODEV;
921: goto cleanup_all;
922: }
923:
924: error = security_file_open(f);
925: if (unlikely(error))
926: goto cleanup_all;
927:
928: /*
929: * Call fsnotify open permission hook and set FMODE_NONOTIFY_* bits
930: * according to existing permission watches.
931: * If FMODE_NONOTIFY mode was already set for an fanotify fd or for a
932: * pseudo file, this call will not change the mode.
933: */
934: error = fsnotify_open_perm_and_set_mode(f);
935: if (unlikely(error))
936: goto cleanup_all;
937:
938: error = break_lease(file_inode(f), f->f_flags);
939: if (unlikely(error))
940: goto cleanup_all;
941:
942: /* normally all 3 are set; ->open() can clear them if needed */
943: f->f_mode |= FMODE_LSEEK | FMODE_PREAD | FMODE_PWRITE;
944: if (!open)
945: open = f->f_op->open;
946: if (open) {
947: error = open(inode, f);
948: if (error)
949: goto cleanup_all;
950: }
951: f->f_mode |= FMODE_OPENED;
952: if ((f->f_mode & FMODE_READ) &&
953: likely(f->f_op->read || f->f_op->read_iter))
954: f->f_mode |= FMODE_CAN_READ;
955: if ((f->f_mode & FMODE_WRITE) &&
956: likely(f->f_op->write || f->f_op->write_iter))
957: f->f_mode |= FMODE_CAN_WRITE;
958: if ((f->f_mode & FMODE_LSEEK) && !f->f_op->llseek)
959: f->f_mode &= ~FMODE_LSEEK;
960: if (f->f_mapping->a_ops && f->f_mapping->a_ops->direct_IO)
961: f->f_mode |= FMODE_CAN_ODIRECT;
962:
963: f->f_flags &= ~(O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC);
964: f->f_iocb_flags = iocb_flags(f);
965:
966: file_ra_state_init(&f->f_ra, f->f_mapping->host->i_mapping);
967:
968: if ((f->f_flags & O_DIRECT) && !(f->f_mode & FMODE_CAN_ODIRECT))
969: return -EINVAL;
970:
971: /*
972: * XXX: Huge page cache doesn't support writing yet. Drop all page
973: * cache for this file before processing writes.
974: */
975: if (f->f_mode & FMODE_WRITE) {
976: /*
977: * Depends on full fence from get_write_access() to synchronize
978: * against collapse_file() regarding i_writecount and nr_thps
979: * updates. Ensures subsequent insertion of THPs into the page
980: * cache will fail.
981: */
982: if (filemap_nr_thps(inode->i_mapping)) {
983: struct address_space *mapping = inode->i_mapping;
984:
985: filemap_invalidate_lock(inode->i_mapping);
986: /*
987: * unmap_mapping_range just need to be called once
988: * here, because the private pages is not need to be
989: * unmapped mapping (e.g. data segment of dynamic
990: * shared libraries here).
991: */
992: unmap_mapping_range(mapping, 0, 0, 0);
993: truncate_inode_pages(mapping, 0);
994: filemap_invalidate_unlock(inode->i_mapping);
995: }
996: }
997:
998: return 0;
999:
1000: cleanup_all:
1001: if (WARN_ON_ONCE(error > 0))
1002: error = -EINVAL;
1003: fops_put(f->f_op);
1004: put_file_access(f);
1005: cleanup_file:
1006: path_put(&f->f_path);
1007: f->__f_path.mnt = NULL;
1008: f->__f_path.dentry = NULL;
1009: f->f_inode = NULL;
1010: return error;
1011: }
SourceFile:fs/open.c]
|
| 215/2 |
2026/06/12 22:42 |
llm |
expert |
0m
Model:
Tokens:
input: 132649
output: 24
thoughts: 3142
Thoughts: **Analyzing the Reproducer for a Potential Kernel Leak**
Okay, so I'm trying to figure out if there's a file descriptor leak in this `io_uring` reproducer. The initial thought was a potential leak in `do_dentry_open`, but that seems unlikely because even if the `open` call fails, the `__fput` function still correctly frees the file, and that makes sense, as the `release` function is only called if `FMODE_OPENED` is set, and that only happens if the `open` succeeds. The code takes that into account.
Then, there was concern that a fail in `security_file_post_open` could lead to a leak but the same logic applies, `__fput` handles the cleanup if `FMODE_OPENED` is set. So far, so good.
Now, the focus shifts to `io_uring_setup`. Previously, I thought a NULL `user_addr` caused a `-EFAULT`, but this reproducer *does* provide valid addresses. It seems to map memory at `0x200000000000` and writes values which, when overwritten, lead to *both* `sq_off.user_addr` and `cq_off.user_addr` pointing to this mapped address. That `io_uring_setup` call is succeeding because of this mapped region!
Now, the interesting bit: I understand that `io_uring_enter` uses the registered ring fd (0 in this case) if `IORING_ENTER_REGISTERED_RING` is set. Then, the reproducer ignores `/dev/vbi3`, opening the device and discarding the return value, so it sits in fd 3.
But where does the interaction happen between the open file and the ring? The SQEs live in the user provided memory, at the `sq_off.user_addr`. Now, looking at the code, it seems the `sq_off.user_addr` refers to the SQEs, not the ring itself.
And here’s where things get interesting. The reproducer sets `IORING_SETUP_NO_MMAP`. This means that *I* provide the memory for the SQ/CQ rings. I see the memory is being handled by `io_allocate_scq_urings`, which is passed `p->cq_off.user_addr` as the address of the CQ ring, and `p->sq_off.user_addr` as the address of the SQEs!
The reproducer wrote `/dev/vbi#\0` to `0x200000000000`. So it's overwriting the SQE ring with the device name! What will happen when `io_uring_enter` tries to interpret this as a SQE?
Is this the memory corruption that is the cause of the leak? And are those values being used to overwrite the file struct? I believe that's the next avenue.
|
| 216/2 |
2026/06/12 22:42 |
tool |
codesearch-struct-layout |
0m
Args:
Results: map[Fields:[map[Name:opcode OffsetBits:0 SizeBits:8] map[Name:flags OffsetBits:8 SizeBits:8] map[Name:ioprio OffsetBits:16 SizeBits:16] map[Name:fd OffsetBits:32 SizeBits:32] map[Name: OffsetBits:64 SizeBits:64] map[Name: OffsetBits:128 SizeBits:64] map[Name:len OffsetBits:192 SizeBits:32] map[Name: OffsetBits:224 SizeBits:32] map[Name:user_data OffsetBits:256 SizeBits:64] map[Name: OffsetBits:320 SizeBits:16] map[Name:personality OffsetBits:336 SizeBits:16] map[Name: OffsetBits:352 SizeBits:32] map[Name: OffsetBits:384 SizeBits:128]]]
|
| 217/2 |
2026/06/12 22:42 |
llm |
expert |
0m
Model:
Tokens:
input: 136708
output: 19
thoughts: 233
Thoughts: **Decoding the Device Identifier**
Okay, let's break this down. That string, "/dev/vbi#\0", looks like it's representing some sort of device identifier or handle. My initial thought is to look at each character and convert it to its hexadecimal representation.
* `'/'` is 0x2f, so that's a good start.
* Then we have `'d'` which is 0x64.
* Following that is `'e'` which translates to 0x65.
* The next character, `'v'` is 0x76.
* Another slash, `/`, which is again 0x2f.
* The following character, `'v'`, is 0x76.
* Then `'b'` which translates to 0x62.
* And `'i'` which is 0x69.
* A hash symbol, `'#'`, corresponding to 0x23.
* Finally, the null terminator, `\0`, which is 0x00.
Now, what does this tell me? Let's interpret this as structured data, or at least break it down into likely fields.
My initial interpretation is:
* `opcode` = 0x2f (47 in decimal)
* `flags` = 0x64 (100)
* `ioprio` = 0x7665 (which is 30309).
* `fd` = 0x6962762f (which is 1768040000).
Hang on a minute...Opcode 47 is IORING\_OP\_TEE! This seems like a valid structure. Given that I have an io\_uring context, this structure seems like a valid way of passing the opcode and the other parameters to the `io_uring_enter` syscall.
Therefore, let's verify that assumption and check `io_uring_opcodes` to confirm that 47 is indeed the opcode for `IORING_OP_TEE`. That will solidify my assumption.
|
| 218/2 |
2026/06/12 22:42 |
tool |
grepper |
0m
Args: map[Expression:IORING_OP_]
Results: map[Output:
Full output is too long, showing 500 out of 1080 lines.
Use more precise expression if possible.
Documentation/filesystems/fuse/fuse-io-uring.rst=27=In order to set up fuse-over-io-uring fuse-server (user-space)
Documentation/filesystems/fuse/fuse-io-uring.rst:28:needs to submit SQEs (opcode = IORING_OP_URING_CMD) to the /dev/fuse
Documentation/filesystems/fuse/fuse-io-uring.rst-29-connection file descriptor. Initial submit is with the sub command
--
Documentation/filesystems/fuse/fuse-io-uring.rst=42=Initial SQE
--
Documentation/filesystems/fuse/fuse-io-uring.rst-47- | | >io_uring_submit()
Documentation/filesystems/fuse/fuse-io-uring.rst:48: | | IORING_OP_URING_CMD /
Documentation/filesystems/fuse/fuse-io-uring.rst-49- | | FUSE_URING_CMD_REGISTER
--
Documentation/filesystems/fuse/fuse-io-uring.rst=58=Sending requests with CQEs
--
Documentation/filesystems/fuse/fuse-io-uring.rst-80- | | >io_uring_submit()
Documentation/filesystems/fuse/fuse-io-uring.rst:81: | | IORING_OP_URING_CMD/
Documentation/filesystems/fuse/fuse-io-uring.rst-82- | | FUSE_URING_CMD_COMMIT_AND_FETCH
--
Documentation/networking/iou-zcrx.rst=156=Prepare a zero copy recv request::
--
Documentation/networking/iou-zcrx.rst-160- sqe = io_uring_get_sqe(ring);
Documentation/networking/iou-zcrx.rst:161: io_uring_prep_rw(IORING_OP_RECV_ZC, sqe, fd, NULL, 0, 0);
Documentation/networking/iou-zcrx.rst-162- sqe->ioprio |= IORING_RECV_MULTISHOT;
--
fs/fuse/dev_uring.c=1080=static int fuse_uring_register(struct io_uring_cmd *cmd,
--
fs/fuse/dev_uring.c-1125- * Entry function from io_uring to handle the given passthrough command
fs/fuse/dev_uring.c:1126: * (op code IORING_OP_URING_CMD)
fs/fuse/dev_uring.c-1127- */
--
fs/fuse/inode.c=1514=static struct fuse_init_args *fuse_new_init(struct fuse_mount *fm)
--
fs/fuse/inode.c-1551- * This is just an information flag for fuse server. No need to check
fs/fuse/inode.c:1552: * the reply - server is either sending IORING_OP_URING_CMD or not.
fs/fuse/inode.c-1553- */
--
include/linux/io_uring_types.h=235=struct io_restriction {
include/linux/io_uring_types.h-236- DECLARE_BITMAP(register_op, IORING_REGISTER_LAST);
include/linux/io_uring_types.h:237: DECLARE_BITMAP(sqe_op, IORING_OP_LAST);
include/linux/io_uring_types.h-238- struct io_bpf_filters *bpf_filters;
--
include/linux/io_uring_types.h-242- u8 sqe_flags_required;
include/linux/io_uring_types.h:243: /* IORING_OP_* restrictions exist */
include/linux/io_uring_types.h-244- bool op_registered;
--
include/linux/io_uring_types.h=707=struct io_kiocb {
--
include/linux/io_uring_types.h-764- /*
include/linux/io_uring_types.h:765: * for polled requests, i.e. IORING_OP_POLL_ADD and async armed
include/linux/io_uring_types.h-766- * poll
--
include/uapi/linux/blkdev.h-8-/*
include/uapi/linux/blkdev.h:9: * io_uring block file commands, see IORING_OP_URING_CMD.
include/uapi/linux/blkdev.h-10- * It's a different number space from ioctl(), reuse the block's code 0x12.
--
include/uapi/linux/bsg.h=69=struct bsg_uring_cmd {
--
include/uapi/linux/bsg.h-90-#ifdef __KERNEL__
include/uapi/linux/bsg.h:91:/* Must match IORING_OP_URING_CMD payload size (e.g. SQE128). */
include/uapi/linux/bsg.h-92-static_assert(sizeof(struct bsg_uring_cmd) == 80);
--
include/uapi/linux/bsg.h-99- * When using BSG_PROTOCOL_SCSI + BSG_SUB_PROTOCOL_SCSI_CMD with
include/uapi/linux/bsg.h:100: * IORING_OP_URING_CMD, the completion queue entry (CQE) contains:
include/uapi/linux/bsg.h-101- * - result: errno (0 on success)
--
include/uapi/linux/io_uring.h=255=enum io_uring_op {
include/uapi/linux/io_uring.h:256: IORING_OP_NOP,
include/uapi/linux/io_uring.h:257: IORING_OP_READV,
include/uapi/linux/io_uring.h:258: IORING_OP_WRITEV,
include/uapi/linux/io_uring.h:259: IORING_OP_FSYNC,
include/uapi/linux/io_uring.h:260: IORING_OP_READ_FIXED,
include/uapi/linux/io_uring.h:261: IORING_OP_WRITE_FIXED,
include/uapi/linux/io_uring.h:262: IORING_OP_POLL_ADD,
include/uapi/linux/io_uring.h:263: IORING_OP_POLL_REMOVE,
include/uapi/linux/io_uring.h:264: IORING_OP_SYNC_FILE_RANGE,
include/uapi/linux/io_uring.h:265: IORING_OP_SENDMSG,
include/uapi/linux/io_uring.h:266: IORING_OP_RECVMSG,
include/uapi/linux/io_uring.h:267: IORING_OP_TIMEOUT,
include/uapi/linux/io_uring.h:268: IORING_OP_TIMEOUT_REMOVE,
include/uapi/linux/io_uring.h:269: IORING_OP_ACCEPT,
include/uapi/linux/io_uring.h:270: IORING_OP_ASYNC_CANCEL,
include/uapi/linux/io_uring.h:271: IORING_OP_LINK_TIMEOUT,
include/uapi/linux/io_uring.h:272: IORING_OP_CONNECT,
include/uapi/linux/io_uring.h:273: IORING_OP_FALLOCATE,
include/uapi/linux/io_uring.h:274: IORING_OP_OPENAT,
include/uapi/linux/io_uring.h:275: IORING_OP_CLOSE,
include/uapi/linux/io_uring.h:276: IORING_OP_FILES_UPDATE,
include/uapi/linux/io_uring.h:277: IORING_OP_STATX,
include/uapi/linux/io_uring.h:278: IORING_OP_READ,
include/uapi/linux/io_uring.h:279: IORING_OP_WRITE,
include/uapi/linux/io_uring.h:280: IORING_OP_FADVISE,
include/uapi/linux/io_uring.h:281: IORING_OP_MADVISE,
include/uapi/linux/io_uring.h:282: IORING_OP_SEND,
include/uapi/linux/io_uring.h:283: IORING_OP_RECV,
include/uapi/linux/io_uring.h:284: IORING_OP_OPENAT2,
include/uapi/linux/io_uring.h:285: IORING_OP_EPOLL_CTL,
include/uapi/linux/io_uring.h:286: IORING_OP_SPLICE,
include/uapi/linux/io_uring.h:287: IORING_OP_PROVIDE_BUFFERS,
include/uapi/linux/io_uring.h:288: IORING_OP_REMOVE_BUFFERS,
include/uapi/linux/io_uring.h:289: IORING_OP_TEE,
include/uapi/linux/io_uring.h:290: IORING_OP_SHUTDOWN,
include/uapi/linux/io_uring.h:291: IORING_OP_RENAMEAT,
include/uapi/linux/io_uring.h:292: IORING_OP_UNLINKAT,
include/uapi/linux/io_uring.h:293: IORING_OP_MKDIRAT,
include/uapi/linux/io_uring.h:294: IORING_OP_SYMLINKAT,
include/uapi/linux/io_uring.h:295: IORING_OP_LINKAT,
include/uapi/linux/io_uring.h:296: IORING_OP_MSG_RING,
include/uapi/linux/io_uring.h:297: IORING_OP_FSETXATTR,
include/uapi/linux/io_uring.h:298: IORING_OP_SETXATTR,
include/uapi/linux/io_uring.h:299: IORING_OP_FGETXATTR,
include/uapi/linux/io_uring.h:300: IORING_OP_GETXATTR,
include/uapi/linux/io_uring.h:301: IORING_OP_SOCKET,
include/uapi/linux/io_uring.h:302: IORING_OP_URING_CMD,
include/uapi/linux/io_uring.h:303: IORING_OP_SEND_ZC,
include/uapi/linux/io_uring.h:304: IORING_OP_SENDMSG_ZC,
include/uapi/linux/io_uring.h:305: IORING_OP_READ_MULTISHOT,
include/uapi/linux/io_uring.h:306: IORING_OP_WAITID,
include/uapi/linux/io_uring.h:307: IORING_OP_FUTEX_WAIT,
include/uapi/linux/io_uring.h:308: IORING_OP_FUTEX_WAKE,
include/uapi/linux/io_uring.h:309: IORING_OP_FUTEX_WAITV,
include/uapi/linux/io_uring.h:310: IORING_OP_FIXED_FD_INSTALL,
include/uapi/linux/io_uring.h:311: IORING_OP_FTRUNCATE,
include/uapi/linux/io_uring.h:312: IORING_OP_BIND,
include/uapi/linux/io_uring.h:313: IORING_OP_LISTEN,
include/uapi/linux/io_uring.h:314: IORING_OP_RECV_ZC,
include/uapi/linux/io_uring.h:315: IORING_OP_EPOLL_WAIT,
include/uapi/linux/io_uring.h:316: IORING_OP_READV_FIXED,
include/uapi/linux/io_uring.h:317: IORING_OP_WRITEV_FIXED,
include/uapi/linux/io_uring.h:318: IORING_OP_PIPE,
include/uapi/linux/io_uring.h:319: IORING_OP_NOP128,
include/uapi/linux/io_uring.h:320: IORING_OP_URING_CMD128,
include/uapi/linux/io_uring.h-321-
include/uapi/linux/io_uring.h-322- /* this goes last, obviously */
include/uapi/linux/io_uring.h:323: IORING_OP_LAST,
include/uapi/linux/io_uring.h-324-};
--
include/uapi/linux/io_uring.h-460-/*
include/uapi/linux/io_uring.h:461: * IORING_OP_MSG_RING command types, stored in sqe->addr
include/uapi/linux/io_uring.h-462- */
include/uapi/linux/io_uring.h=463=enum io_uring_msg_ring_flags {
--
include/uapi/linux/io_uring.h-468-/*
include/uapi/linux/io_uring.h:469: * IORING_OP_MSG_RING flags (sqe->msg_ring_flags)
include/uapi/linux/io_uring.h-470- *
--
include/uapi/linux/io_uring.h-478-/*
include/uapi/linux/io_uring.h:479: * IORING_OP_FIXED_FD_INSTALL flags (sqe->install_fd_flags)
include/uapi/linux/io_uring.h-480- *
--
include/uapi/linux/io_uring.h-485-/*
include/uapi/linux/io_uring.h:486: * IORING_OP_NOP flags (sqe->nop_flags)
include/uapi/linux/io_uring.h-487- *
--
include/uapi/linux/io_uring.h=1027=struct io_uring_recvmsg_out {
--
include/uapi/linux/io_uring.h-1034-/*
include/uapi/linux/io_uring.h:1035: * Argument for IORING_OP_URING_CMD when file is a socket
include/uapi/linux/io_uring.h-1036- */
--
include/uapi/linux/io_uring/query.h=31=struct io_uring_query_opcode {
include/uapi/linux/io_uring/query.h:32: /* The number of supported IORING_OP_* opcodes */
include/uapi/linux/io_uring/query.h-33- __u32 nr_request_opcodes;
--
include/uapi/linux/ublk_cmd.h=90=struct ublk_shmem_buf_reg {
--
include/uapi/linux/ublk_cmd.h-217- * SQEs can now be submitted to the io_uring to read/write the request's buffer
include/uapi/linux/ublk_cmd.h:218: * by enabling fixed buffers (e.g. using IORING_OP_{READ,WRITE}_FIXED or
include/uapi/linux/ublk_cmd.h-219- * IORING_URING_CMD_FIXED) and passing the registered buffer index in buf_index.
--
io_uring/bpf_filter.c=97=static void io_free_bpf_filters(struct rcu_head *head)
--
io_uring/bpf_filter.c-109-
io_uring/bpf_filter.c:110: for (i = 0; i < IORING_OP_LAST; i++) {
io_uring/bpf_filter.c-111- struct io_bpf_filter *f;
--
io_uring/bpf_filter.c=151=static struct io_bpf_filters *io_new_bpf_filters(void)
--
io_uring/bpf_filter.c-158-
io_uring/bpf_filter.c:159: filters->filters = kzalloc_objs(struct io_bpf_filter *, IORING_OP_LAST,
io_uring/bpf_filter.c-160- GFP_KERNEL_ACCOUNT);
--
io_uring/bpf_filter.c=266=static struct io_bpf_filters *io_bpf_filter_cow(struct io_restriction *src)
--
io_uring/bpf_filter.c-283- rcu_read_lock();
io_uring/bpf_filter.c:284: for (i = 0; i < IORING_OP_LAST; i++) {
io_uring/bpf_filter.c-285- srcf = rcu_dereference(src->bpf_filters->filters[i]);
--
io_uring/bpf_filter.c=313=static int io_bpf_filter_import(struct io_uring_bpf *reg,
--
io_uring/bpf_filter.c-325-
io_uring/bpf_filter.c:326: if (reg->filter.opcode >= IORING_OP_LAST)
io_uring/bpf_filter.c-327- return -EINVAL;
--
io_uring/bpf_filter.c-337- /* Verify filter size */
io_uring/bpf_filter.c:338: def = &io_issue_defs[array_index_nospec(reg->filter.opcode, IORING_OP_LAST)];
io_uring/bpf_filter.c-339-
--
io_uring/bpf_filter.c=359=int io_register_bpf_filter(struct io_restriction *res,
--
io_uring/bpf_filter.c-437- if (reg.filter.flags & IO_URING_BPF_FILTER_DENY_REST) {
io_uring/bpf_filter.c:438: for (int i = 0; i < IORING_OP_LAST; i++) {
io_uring/bpf_filter.c-439- if (i == reg.filter.opcode)
--
io_uring/cancel.c=140=int io_async_cancel_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
--
io_uring/cancel.c-164- op = READ_ONCE(sqe->len);
io_uring/cancel.c:165: if (op >= IORING_OP_LAST)
io_uring/cancel.c-166- return -EINVAL;
--
io_uring/fdinfo.c=60=static void __io_uring_show_fdinfo(struct io_ring_ctx *ctx, struct seq_file *m)
--
io_uring/fdinfo.c-109- opcode = READ_ONCE(sqe->opcode);
io_uring/fdinfo.c:110: if (opcode >= IORING_OP_LAST)
io_uring/fdinfo.c-111- continue;
io_uring/fdinfo.c:112: opcode = array_index_nospec(opcode, IORING_OP_LAST);
io_uring/fdinfo.c-113- if (sq_shift) {
--
io_uring/futex.c=92=static bool __io_futex_cancel(struct io_kiocb *req)
--
io_uring/futex.c-94- /* futex wake already done or in progress */
io_uring/futex.c:95: if (req->opcode == IORING_OP_FUTEX_WAIT) {
io_uring/futex.c-96- struct io_futex_data *ifd = req->async_data;
--
io_uring/io_uring.c=1734=static int io_init_req(struct io_ring_ctx *ctx, struct io_kiocb *req,
--
io_uring/io_uring.c-1752-
io_uring/io_uring.c:1753: if (unlikely(req->opcode >= IORING_OP_LAST)) {
io_uring/io_uring.c-1754- req->opcode = 0;
--
io_uring/io_uring.c-1756- }
io_uring/io_uring.c:1757: req->opcode = array_index_nospec(req->opcode, IORING_OP_LAST);
io_uring/io_uring.c-1758-
--
io_uring/io_uring.h=560=static inline bool io_is_uring_cmd(const struct io_kiocb *req)
io_uring/io_uring.h-561-{
io_uring/io_uring.h:562: return req->opcode == IORING_OP_URING_CMD ||
io_uring/io_uring.h:563: req->opcode == IORING_OP_URING_CMD128;
io_uring/io_uring.h-564-}
--
io_uring/kbuf.c=570=static int __io_manage_buffers_legacy(struct io_kiocb *req,
--
io_uring/kbuf.c-576- if (!bl) {
io_uring/kbuf.c:577: if (req->opcode != IORING_OP_PROVIDE_BUFFERS)
io_uring/kbuf.c-578- return -ENOENT;
--
io_uring/kbuf.c-592- return -EINVAL;
io_uring/kbuf.c:593: if (req->opcode == IORING_OP_PROVIDE_BUFFERS)
io_uring/kbuf.c-594- return io_add_buffers(req->ctx, p, bl);
--
io_uring/msg_ring.c=83=static void io_msg_remote_post(struct io_ring_ctx *ctx, struct io_kiocb *req,
--
io_uring/msg_ring.c-85-{
io_uring/msg_ring.c:86: req->opcode = IORING_OP_NOP;
io_uring/msg_ring.c-87- req->cqe.user_data = user_data;
--
io_uring/msg_ring.c=176=static int io_msg_install_complete(struct io_kiocb *req, unsigned int issue_flags)
--
io_uring/msg_ring.c-198- * completes with -EOVERFLOW, then the sender must ensure that a
io_uring/msg_ring.c:199: * later IORING_OP_MSG_RING delivers the message.
io_uring/msg_ring.c-200- */
--
io_uring/net.c=423=int io_sendmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
--
io_uring/net.c-439- if (sr->flags & IORING_RECVSEND_BUNDLE) {
io_uring/net.c:440: if (req->opcode == IORING_OP_SENDMSG)
io_uring/net.c-441- return -EINVAL;
--
io_uring/net.c-450- return -ENOMEM;
io_uring/net.c:451: if (req->opcode != IORING_OP_SENDMSG)
io_uring/net.c-452- return io_send_setup(req, sqe);
--
io_uring/net.c=759=static int io_recvmsg_prep_setup(struct io_kiocb *req)
--
io_uring/net.c-767-
io_uring/net.c:768: if (req->opcode == IORING_OP_RECV) {
io_uring/net.c-769- kmsg->msg.msg_name = NULL;
--
io_uring/net.c=790=int io_recvmsg_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
--
io_uring/net.c-818- return -EINVAL;
io_uring/net.c:819: if (req->opcode == IORING_OP_RECV) {
io_uring/net.c-820- sr->mshot_len = sr->len;
--
io_uring/net.c-832- if (sr->flags & IORING_RECVSEND_BUNDLE) {
io_uring/net.c:833: if (req->opcode == IORING_OP_RECVMSG)
io_uring/net.c-834- return -EINVAL;
--
io_uring/net.c=1336=int io_send_zc_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
--
io_uring/net.c-1390-
io_uring/net.c:1391: if (req->opcode == IORING_OP_SEND_ZC) {
io_uring/net.c-1392- ret = io_send_setup(req, sqe);
--
io_uring/net.c=1489=int io_sendmsg_zc(struct io_kiocb *req, unsigned int issue_flags)
--
io_uring/net.c-1519-
io_uring/net.c:1520: if (req->opcode == IORING_OP_SEND_ZC) {
io_uring/net.c-1521- msg_flags &= ~MSG_INTERNAL_SENDMSG_FLAGS;
--
io_uring/net.c=1560=void io_sendrecv_fail(struct io_kiocb *req)
--
io_uring/net.c-1567- if ((req->flags & REQ_F_NEED_CLEANUP) &&
io_uring/net.c:1568: (req->opcode == IORING_OP_SEND_ZC || req->opcode == IORING_OP_SENDMSG_ZC))
io_uring/net.c-1569- req->cqe.flags |= IORING_CQE_F_MORE;
--
io_uring/notif.c=114=struct io_kiocb *io_alloc_notif(struct io_ring_ctx *ctx)
--
io_uring/notif.c-122- notif->ctx = ctx;
io_uring/notif.c:123: notif->opcode = IORING_OP_NOP;
io_uring/notif.c-124- notif->flags = 0;
--
io_uring/opdef.c=54=const struct io_issue_def io_issue_defs[] = {
io_uring/opdef.c:55: [IORING_OP_NOP] = {
io_uring/opdef.c-56- .audit_skip = 1,
--
io_uring/opdef.c-60- },
io_uring/opdef.c:61: [IORING_OP_READV] = {
io_uring/opdef.c-62- .needs_file = 1,
--
io_uring/opdef.c-74- },
io_uring/opdef.c:75: [IORING_OP_WRITEV] = {
io_uring/opdef.c-76- .needs_file = 1,
--
io_uring/opdef.c-88- },
io_uring/opdef.c:89: [IORING_OP_FSYNC] = {
io_uring/opdef.c-90- .needs_file = 1,
--
io_uring/opdef.c-94- },
io_uring/opdef.c:95: [IORING_OP_READ_FIXED] = {
io_uring/opdef.c-96- .needs_file = 1,
--
io_uring/opdef.c-106- },
io_uring/opdef.c:107: [IORING_OP_WRITE_FIXED] = {
io_uring/opdef.c-108- .needs_file = 1,
--
io_uring/opdef.c-119- },
io_uring/opdef.c:120: [IORING_OP_POLL_ADD] = {
io_uring/opdef.c-121- .needs_file = 1,
--
io_uring/opdef.c-126- },
io_uring/opdef.c:127: [IORING_OP_POLL_REMOVE] = {
io_uring/opdef.c-128- .audit_skip = 1,
--
io_uring/opdef.c-131- },
io_uring/opdef.c:132: [IORING_OP_SYNC_FILE_RANGE] = {
io_uring/opdef.c-133- .needs_file = 1,
--
io_uring/opdef.c-137- },
io_uring/opdef.c:138: [IORING_OP_SENDMSG] = {
io_uring/opdef.c-139- .needs_file = 1,
--
io_uring/opdef.c-150- },
io_uring/opdef.c:151: [IORING_OP_RECVMSG] = {
io_uring/opdef.c-152- .needs_file = 1,
--
io_uring/opdef.c-164- },
io_uring/opdef.c:165: [IORING_OP_TIMEOUT] = {
io_uring/opdef.c-166- .audit_skip = 1,
--
io_uring/opdef.c-170- },
io_uring/opdef.c:171: [IORING_OP_TIMEOUT_REMOVE] = {
io_uring/opdef.c-172- /* used by timeout updates' prep() */
--
io_uring/opdef.c-176- },
io_uring/opdef.c:177: [IORING_OP_ACCEPT] = {
io_uring/opdef.c-178- .needs_file = 1,
--
io_uring/opdef.c-189- },
io_uring/opdef.c:190: [IORING_OP_ASYNC_CANCEL] = {
io_uring/opdef.c-191- .audit_skip = 1,
--
io_uring/opdef.c-194- },
io_uring/opdef.c:195: [IORING_OP_LINK_TIMEOUT] = {
io_uring/opdef.c-196- .audit_skip = 1,
--
io_uring/opdef.c-200- },
io_uring/opdef.c:201: [IORING_OP_CONNECT] = {
io_uring/opdef.c-202- .needs_file = 1,
--
io_uring/opdef.c-212- },
io_uring/opdef.c:213: [IORING_OP_FALLOCATE] = {
io_uring/opdef.c-214- .needs_file = 1,
--
io_uring/opdef.c-218- },
io_uring/opdef.c:219: [IORING_OP_OPENAT] = {
io_uring/opdef.c-220- .filter_pdu_size = sizeof_field(struct io_uring_bpf_ctx, open),
--
io_uring/opdef.c-224- },
io_uring/opdef.c:225: [IORING_OP_CLOSE] = {
io_uring/opdef.c-226- .prep = io_close_prep,
--
io_uring/opdef.c-228- },
io_uring/opdef.c:229: [IORING_OP_FILES_UPDATE] = {
io_uring/opdef.c-230- .audit_skip = 1,
--
io_uring/opdef.c-234- },
io_uring/opdef.c:235: [IORING_OP_STATX] = {
io_uring/opdef.c-236- .audit_skip = 1,
--
io_uring/opdef.c-239- },
io_uring/opdef.c:240: [IORING_OP_READ] = {
io_uring/opdef.c-241- .needs_file = 1,
--
io_uring/opdef.c-252- },
io_uring/opdef.c:253: [IORING_OP_WRITE] = {
io_uring/opdef.c-254- .needs_file = 1,
--
io_uring/opdef.c-265- },
io_uring/opdef.c:266: [IORING_OP_FADVISE] = {
io_uring/opdef.c-267- .needs_file = 1,
--
io_uring/opdef.c-271- },
io_uring/opdef.c:272: [IORING_OP_MADVISE] = {
io_uring/opdef.c-273- .audit_skip = 1,
--
io_uring/opdef.c-276- },
io_uring/opdef.c:277: [IORING_OP_SEND] = {
io_uring/opdef.c-278- .needs_file = 1,
--
io_uring/opdef.c-291- },
io_uring/opdef.c:292: [IORING_OP_RECV] = {
io_uring/opdef.c-293- .needs_file = 1,
--
io_uring/opdef.c-306- },
io_uring/opdef.c:307: [IORING_OP_OPENAT2] = {
io_uring/opdef.c-308- .filter_pdu_size = sizeof_field(struct io_uring_bpf_ctx, open),
--
io_uring/opdef.c-312- },
io_uring/opdef.c:313: [IORING_OP_EPOLL_CTL] = {
io_uring/opdef.c-314- .unbound_nonreg_file = 1,
--
io_uring/opdef.c-322- },
io_uring/opdef.c:323: [IORING_OP_SPLICE] = {
io_uring/opdef.c-324- .needs_file = 1,
--
io_uring/opdef.c-330- },
io_uring/opdef.c:331: [IORING_OP_PROVIDE_BUFFERS] = {
io_uring/opdef.c-332- .audit_skip = 1,
--
io_uring/opdef.c-336- },
io_uring/opdef.c:337: [IORING_OP_REMOVE_BUFFERS] = {
io_uring/opdef.c-338- .audit_skip = 1,
--
io_uring/opdef.c-342- },
io_uring/opdef.c:343: [IORING_OP_TEE] = {
io_uring/opdef.c-344- .needs_file = 1,
--
io_uring/opdef.c-350- },
io_uring/opdef.c:351: [IORING_OP_SHUTDOWN] = {
io_uring/opdef.c-352- .needs_file = 1,
--
io_uring/opdef.c-359- },
io_uring/opdef.c:360: [IORING_OP_RENAMEAT] = {
io_uring/opdef.c-361- .prep = io_renameat_prep,
--
io_uring/opdef.c-363- },
io_uring/opdef.c:364: [IORING_OP_UNLINKAT] = {
io_uring/opdef.c-365- .prep = io_unlinkat_prep,
--
io_uring/opdef.c-367- },
io_uring/opdef.c:368: [IORING_OP_MKDIRAT] = {
io_uring/opdef.c-369- .prep = io_mkdirat_prep,
--
io_uring/opdef.c-371- },
io_uring/opdef.c:372: [IORING_OP_SYMLINKAT] = {
io_uring/opdef.c-373- .prep = io_symlinkat_prep,
--
io_uring/opdef.c-375- },
io_uring/opdef.c:376: [IORING_OP_LINKAT] = {
io_uring/opdef.c-377- .prep = io_linkat_prep,
--
io_uring/opdef.c-379- },
io_uring/opdef.c:380: [IORING_OP_MSG_RING] = {
io_uring/opdef.c-381- .needs_file = 1,
--
io_uring/opdef.c-385- },
io_uring/opdef.c:386: [IORING_OP_FSETXATTR] = {
io_uring/opdef.c-387- .needs_file = 1,
--
io_uring/opdef.c-390- },
io_uring/opdef.c:391: [IORING_OP_SETXATTR] = {
io_uring/opdef.c-392- .prep = io_setxattr_prep,
--
io_uring/opdef.c-394- },
io_uring/opdef.c:395: [IORING_OP_FGETXATTR] = {
io_uring/opdef.c-396- .needs_file = 1,
--
io_uring/opdef.c-399- },
io_uring/opdef.c:400: [IORING_OP_GETXATTR] = {
io_uring/opdef.c-401- .prep = io_getxattr_prep,
--
io_uring/opdef.c-403- },
io_uring/opdef.c:404: [IORING_OP_SOCKET] = {
io_uring/opdef.c-405- .audit_skip = 1,
--
io_uring/opdef.c-414- },
io_uring/opdef.c:415: [IORING_OP_URING_CMD] = {
io_uring/opdef.c-416- .buffer_select = 1,
--
io_uring/opdef.c-423- },
io_uring/opdef.c:424: [IORING_OP_SEND_ZC] = {
io_uring/opdef.c-425- .needs_file = 1,
]
|
| 219/2 |
2026/06/12 22:42 |
llm |
expert |
0m
Model:
Tokens:
input: 147753
output: 36
thoughts: 806
Thoughts: **Analyzing Potential Vulnerabilities in `io_uring` and VFS**
Okay, let's break this down. First, I'm confirming that `IORING_OP_TEE` is indeed operation code 47. Then, I'm quickly getting up to speed, and making sure I understand the arguments that IORING_OP_TEE expects.
Now, I'm going through the reproducer, and trying to understand why it isn't working as I expect. The value `0x6962762f` is coming up in `fd`, and I realize that the reproducer *doesn't* actually have a file descriptor with that value. Bingo! So, `io_uring_enter` will try to use that invalid `fd` and fail with `-EBADF`. The `SQE` will just be rejected, and nothing will happen. That's not the leak I'm looking for.
I'm starting to think more broadly now, what if `io_uring_setup` itself fails? Ah, if that happens, `r[0]` will be `-1`. Then, `io_uring_enter` is called with that `-1` `fd`. It will fail immediately. This confirms that `io_uring` is a dead end.
I need to expand my search. What if the leak isn't related to `/dev/vbi3`? What if it's related to the `socket`? No, I already checked `sock_alloc_file`, and it doesn't call `path_openat`. Okay, what about a file opened by `prctl`? Nope, `prctl` doesn't open files. `sendmsg`? Also, no.
Wait... could `syz_open_dev` be opening `/dev/vbi3`, and is the leak is in the VFS layer? It's the most likely path. Let's check `alloc_empty_file`!
```c
struct file *alloc_empty_file(int flags, const struct cred *cred)
{
static const struct file_operations empty_fops = {};
struct file *f;
f = alloc_file(&empty_fops, flags, cred);
if (!IS_ERR(f))
f->f_mode |= FMODE_OPENED;
return f;
}
```
Wait! It sets `FMODE_OPENED`! That's interesting. I remember this. Now, let's double check `path_openat` and see what it is doing with this flag!
```c
file = alloc_empty_file(op->open_flag, current_cred());
if (IS_ERR(file))
return file;
if (unlikely(file->f_flags & __O_TMPFILE)) {
error = do_tmpfile(nd, flags, op, file);
} else if (unlikely(file->f_flags & O_PATH)) {
error = do_o_path(nd, flags, file);
} else {
const char *s = path_init(nd, flags);
while (!(error = link_path_walk(s, nd)) &&
(s = open_last_lookups(nd, file, op)) != NULL)
;
if (!error)
error = do_open(nd, file, op);
terminate_walk(nd);
}
if (likely(!error)) {
if (likely(file->f_mode & FMODE_OPENED))
return file;
WARN_ON(1);
error = -EINVAL;
}
fput_close(file);
```
Wait, `alloc_empty_file` sets `FMODE_OPENED`?! Let's check that function in `fs/file_table.c`.
|
| 220/2 |
2026/06/12 22:42 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/file_table.c Name:alloc_empty_file]
Results: map[SourceCode: 233: /* Find an unused file structure and return a pointer to it.
234: * Returns an error pointer if some error happend e.g. we over file
235: * structures limit, run out of memory or operation is not permitted.
236: *
237: * Be very careful using this. You are responsible for
238: * getting write access to any mount that you might assign
239: * to this filp, if it is opened for write. If this is not
240: * done, you will imbalance int the mount's writer count
241: * and a warning at __fput() time.
242: */
243: struct file *alloc_empty_file(int flags, const struct cred *cred)
244: {
245: static long old_max;
246: struct file *f;
247: int error;
248:
249: /*
250: * Privileged users can go above max_files
251: */
252: if (unlikely(get_nr_files() >= files_stat.max_files) &&
253: !capable(CAP_SYS_ADMIN)) {
254: /*
255: * percpu_counters are inaccurate. Do an expensive check before
256: * we go and fail.
257: */
258: if (percpu_counter_sum_positive(&nr_files) >= files_stat.max_files)
259: goto over;
260: }
261:
262: f = kmem_cache_alloc(filp_cache, GFP_KERNEL);
263: if (unlikely(!f))
264: return ERR_PTR(-ENOMEM);
265:
266: error = init_file(f, flags, cred);
267: if (unlikely(error)) {
268: kmem_cache_free(filp_cache, f);
269: return ERR_PTR(error);
270: }
271:
272: percpu_counter_inc(&nr_files);
273:
274: return f;
275:
276: over:
277: /* Ran out of filps - report that */
278: if (get_nr_files() > old_max) {
279: pr_info("VFS: file-max limit %lu reached\n", get_max_files());
280: old_max = get_nr_files();
281: }
282: return ERR_PTR(-ENFILE);
283: }
SourceFile:fs/file_table.c]
|
| 221/2 |
2026/06/12 22:42 |
llm |
expert |
0m
Model:
Tokens:
input: 150243
output: 49
thoughts: 211
Thoughts: **File Descriptor Lifecycle: A Curious Case**
Okay, so I'm digging into this file descriptor lifecycle, and something's bugging me. It seems `alloc_empty_file` *intentionally* doesn't set the `FMODE_OPENED` flag. Interesting, I wouldn't have thought that. This flag, it turns out, is the responsibility of `do_dentry_open` – it's set *after* a successful `open` call. Now, if `do_open` bails out with an error, `FMODE_OPENED` never gets flipped.
That's when things get even more interesting. `path_openat` then invokes `fput_close(file)`. `fput_close` is pretty standard, it decrements the reference count and calls `__fput_deferred`. Now `__fput` checks the `FMODE_OPENED` flag. Since we know that flag *wasn't* set, `__fput` skips calling `fops->release`. But, and here's the kicker, it *still* calls `file_free(file)`. So the file gets freed regardless.
Wait a second...I'm thinking about `vivid_fop_open` (which, as I recall, is a wrapper around `v4l2_fh_open`) here. What happens if the `v4l2_fh_open` part *succeeds*, but then `v4l2_open` returns an error? We need to go back and check the exact behavior of `v4l2_open`...
|
| 222/2 |
2026/06/12 22:42 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/media/v4l2-core/v4l2-dev.c Name:v4l2_open]
Results: map[SourceCode: 410: /* Override for the open function */
411: static int v4l2_open(struct inode *inode, struct file *filp)
412: {
413: struct video_device *vdev;
414: int ret;
415:
416: /* Check if the video device is available */
417: mutex_lock(&videodev_lock);
418: vdev = video_devdata(filp);
419: /* return ENODEV if the video device has already been removed. */
420: if (vdev == NULL || !video_is_registered(vdev)) {
421: mutex_unlock(&videodev_lock);
422: return -ENODEV;
423: }
424: /* and increase the device refcount */
425: video_get(vdev);
426: mutex_unlock(&videodev_lock);
427:
428: if (!video_is_registered(vdev)) {
429: ret = -ENODEV;
430: goto done;
431: }
432:
433: ret = vdev->fops->open(filp);
434: if (ret)
435: goto done;
436:
437: /* All drivers must use v4l2_fh. */
438: if (WARN_ON(!test_bit(V4L2_FL_USES_V4L2_FH, &vdev->flags))) {
439: vdev->fops->release(filp);
440: ret = -ENODEV;
441: }
442:
443: done:
444: if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
445: dprintk("%s: open (%d)\n",
446: video_device_node_name(vdev), ret);
447:
448: /* decrease the refcount in case of an error */
449: if (ret)
450: video_put(vdev);
451: return ret;
452: }
SourceFile:drivers/media/v4l2-core/v4l2-dev.c]
|
| 223/2 |
2026/06/12 22:42 |
llm |
expert |
0m
Model:
Tokens:
input: 151521
output: 49
thoughts: 169
Thoughts: **Analyzing the Video4Linux2 Open and Release Sequence**
Okay, let's break this down step-by-step. I'm looking at how a Video4Linux2 device is opened and subsequently released, focusing on the potential error paths. If `vdev->fops->open(filp)` succeeds, `ret` becomes 0, and that means `v4l2_open` returns 0. So, we've successfully opened the V4L2 device kernel-side at this point.
Now, `do_dentry_open` comes into play and sets the `FMODE_OPENED` flag on the file structure. After that `do_open` is called which, importantly, calls `security_file_post_open`. This is a crucial security check. If `security_file_post_open` *fails*, then `do_open` returns an error. This is important to understand.
If an error *does* occur after `FMODE_OPENED` is set, `path_openat` will call `fput_close(file)`. Because `FMODE_OPENED` is set, `__fput` will call the `fops->release` function, which in the V4L2 context is `v4l2_release`. This is the cleanup function. So, the kernel will attempt to release the device if there's an error after the open.
My next step is to examine precisely what `v4l2_release` does. I need to understand its role in handling errors during this critical open sequence. I'll need to know whether any cleanup happens there, specifically.
|
| 224/2 |
2026/06/12 22:42 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/media/v4l2-core/v4l2-dev.c Name:v4l2_release]
Results: map[SourceCode: 454: /* Override for the release function */
455: static int v4l2_release(struct inode *inode, struct file *filp)
456: {
457: struct video_device *vdev = video_devdata(filp);
458: int ret;
459:
460: /*
461: * We need to serialize the release() with queueing new requests.
462: * The release() may trigger the cancellation of a streaming
463: * operation, and that should not be mixed with queueing a new
464: * request at the same time.
465: */
466: if (v4l2_device_supports_requests(vdev->v4l2_dev)) {
467: mutex_lock(&vdev->v4l2_dev->mdev->req_queue_mutex);
468: ret = vdev->fops->release(filp);
469: mutex_unlock(&vdev->v4l2_dev->mdev->req_queue_mutex);
470: } else {
471: ret = vdev->fops->release(filp);
472: }
473:
474: if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
475: dprintk("%s: release\n",
476: video_device_node_name(vdev));
477:
478: /* decrease the refcount unconditionally since the release()
479: return value is ignored. */
480: video_put(vdev);
481: return ret;
482: }
SourceFile:drivers/media/v4l2-core/v4l2-dev.c]
|
| 225/2 |
2026/06/12 22:42 |
llm |
expert |
0m
Model:
Tokens:
input: 152601
output: 38
thoughts: 2106
Thoughts: **Analyzing a Potential io_uring and v4l2 Vulnerability**
Okay, let's break this down. First, `v4l2_release` should clean up everything, calling `vivid_fop_release` and then `video_put(vdev)`. So far, so good.
But, if `io_uring_setup` succeeds, what happens? I'm thinking about that `-EFAULT` return from `io_create_region` if `user_addr` is zero. But no, `user_addr` is `0x200000000000`, a mapped address. So, `io_create_region` should successfully pin the pages there. Therefore, `io_uring_setup` should succeed too, returning a registered fd index of `0`.
Then, we have `syz_open_dev` opening `/dev/vbi3`, followed by a `sendmsg` failure. Then `io_uring_enter` is called, and this is where it gets interesting because `fd` is `0`, which is the registered ring fd. The interesting thing is that if `IORING_ENTER_REGISTERED_RING` is set, `fd` is used as an index into the `registered_rings` array. So, the `io_uring_enter` will use the ring file itself. Does this interact with `/dev/vbi3`? No, since the `/dev/vbi3` fd is 3 and `io_uring_enter` uses fd 0.
`io_uring_enter` then processes SQEs. Where are they located? They are located at `sq_off.user_addr` which is `0x200000000000`. And what is written there? The reproducer writes to it a `/dev/vbi#\0` string.
Wait a minute, is `0x200000000000` the address of the SQ ring *itself* or the SQEs? Okay, with `IORING_SETUP_NO_MMAP` set, the user provides the memory. Let's look at `io_allocate_scq_urings`:
`p->cq_off.user_addr` is used for the completion queue *and* submission queue *rings*. But, crucially, `p->sq_off.user_addr` is for the *submission queue entries* themselves!
Okay, so `0x200000000000` is the SQEs. And that's where the reproducer writes `/dev/vbi#\0`. That's ten bytes that are going to get interpreted as an `io_uring_sqe`!
Let's decode those ten bytes:
- `opcode` is `0x2f` (47) which is `IORING_OP_TEE`.
- `flags` is `0x64` = `IOSQE_CQE_SKIP_SUCCESS | IOSQE_BUFFER_SELECT | IOSQE_IO_LINK`.
- `ioprio` is `0x7665`.
- `fd` is `0x6962762f`.
Wait, `IORING_OP_TEE` takes a *file descriptor* in `fd` and a *destination address* in `sqe->addr`? So, if we look at `fd` which is `0x6962762f`, is it a valid file descriptor? No! Then `io_uring_enter` will fail with `-EBADF` because it cannot find the file and will just do nothing.
What if `fd` *was* a valid number? `0x6962762f` does not correspond to a valid fd. Even if `flags` had `IOSQE_FIXED_FILE`, it would *still* fail because there is no matching fd.
But, does the leak involve the ring file itself? Remember `io_uring_setup` with `IORING_SETUP_REGISTERED_FD_ONLY` returns an *index*, not a normal file descriptor! But it allocates a file struct. Does this result in a leak?
Let's check `io_uring_create`.
|
| 226/2 |
2026/06/12 22:43 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_uring_create]
Results: map[SourceCode:2978: static __cold int io_uring_create(struct io_ctx_config *config)
2979: {
2980: struct io_uring_params *p = &config->p;
2981: struct io_ring_ctx *ctx;
2982: struct io_uring_task *tctx;
2983: struct file *file;
2984: int ret;
2985:
2986: ret = io_prepare_config(config);
2987: if (ret)
2988: return ret;
2989:
2990: ctx = io_ring_ctx_alloc(p);
2991: if (!ctx)
2992: return -ENOMEM;
2993:
2994: ctx->clockid = CLOCK_MONOTONIC;
2995: ctx->clock_offset = 0;
2996:
2997: if (!(ctx->flags & IORING_SETUP_NO_SQARRAY))
2998: static_branch_deferred_inc(&io_key_has_sqarray);
2999:
3000: if ((ctx->flags & IORING_SETUP_DEFER_TASKRUN) &&
3001: !(ctx->flags & IORING_SETUP_IOPOLL))
3002: ctx->int_flags |= IO_RING_F_TASK_COMPLETE;
3003:
3004: if ((ctx->int_flags & IO_RING_F_TASK_COMPLETE) ||
3005: (ctx->flags & IORING_SETUP_IOPOLL))
3006: ctx->int_flags |= IO_RING_F_LOCKLESS_CQ;
3007:
3008: /*
3009: * lazy poll_wq activation relies on ->task_complete for synchronisation
3010: * purposes, see io_activate_pollwq()
3011: */
3012: if (!(ctx->int_flags & IO_RING_F_TASK_COMPLETE))
3013: ctx->int_flags |= IO_RING_F_POLL_ACTIVATED;
3014:
3015: /*
3016: * When SETUP_IOPOLL and SETUP_SQPOLL are both enabled, user
3017: * space applications don't need to do io completion events
3018: * polling again, they can rely on io_sq_thread to do polling
3019: * work, which can reduce cpu usage and uring_lock contention.
3020: */
3021: if (ctx->flags & IORING_SETUP_IOPOLL &&
3022: !(ctx->flags & IORING_SETUP_SQPOLL))
3023: ctx->int_flags |= IO_RING_F_SYSCALL_IOPOLL;
3024:
3025: if (in_compat_syscall())
3026: ctx->int_flags |= IO_RING_F_COMPAT;
3027: if (!ns_capable_noaudit(&init_user_ns, CAP_IPC_LOCK))
3028: ctx->user = get_uid(current_user());
3029:
3030: /*
3031: * For SQPOLL, we just need a wakeup, always. For !SQPOLL, if
3032: * COOP_TASKRUN is set, then IPIs are never needed by the app.
3033: */
3034: if (ctx->flags & (IORING_SETUP_SQPOLL|IORING_SETUP_COOP_TASKRUN))
3035: ctx->notify_method = TWA_SIGNAL_NO_IPI;
3036: else
3037: ctx->notify_method = TWA_SIGNAL;
3038:
3039: /*
3040: * If the current task has restrictions enabled, then copy them to
3041: * our newly created ring and mark it as registered.
3042: */
3043: if (current->io_uring_restrict)
3044: io_ctx_restriction_clone(ctx, current->io_uring_restrict);
3045:
3046: /*
3047: * This is just grabbed for accounting purposes. When a process exits,
3048: * the mm is exited and dropped before the files, hence we need to hang
3049: * on to this mm purely for the purposes of being able to unaccount
3050: * memory (locked/pinned vm). It's not used for anything else.
3051: */
3052: mmgrab(current->mm);
3053: ctx->mm_account = current->mm;
3054:
3055: ret = io_allocate_scq_urings(ctx, config);
3056: if (ret)
3057: goto err;
3058:
3059: ret = io_sq_offload_create(ctx, p);
3060: if (ret)
3061: goto err;
3062:
3063: p->features = IORING_FEAT_FLAGS;
3064:
3065: if (copy_to_user(config->uptr, p, sizeof(*p))) {
3066: ret = -EFAULT;
3067: goto err;
3068: }
3069:
3070: if (ctx->flags & IORING_SETUP_SINGLE_ISSUER
3071: && !(ctx->flags & IORING_SETUP_R_DISABLED))
3072: ctx->submitter_task = get_task_struct(current);
3073:
3074: file = io_uring_get_file(ctx);
3075: if (IS_ERR(file)) {
3076: ret = PTR_ERR(file);
3077: goto err;
3078: }
3079:
3080: ret = __io_uring_add_tctx_node(ctx);
3081: if (ret)
3082: goto err_fput;
3083: tctx = current->io_uring;
3084:
3085: /*
3086: * Install ring fd as the very last thing, so we don't risk someone
3087: * having closed it before we finish setup
3088: */
3089: if (p->flags & IORING_SETUP_REGISTERED_FD_ONLY)
3090: ret = io_ring_add_registered_file(tctx, file, 0, IO_RINGFD_REG_MAX);
3091: else
3092: ret = io_uring_install_fd(file);
3093: if (ret < 0)
3094: goto err_fput;
3095:
3096: trace_io_uring_create(ret, ctx, p->sq_entries, p->cq_entries, p->flags);
3097: return ret;
3098: err:
3099: io_ring_ctx_wait_and_kill(ctx);
3100: return ret;
3101: err_fput:
3102: fput(file);
3103: return ret;
3104: }
SourceFile:io_uring/io_uring.c]
|
| 227/2 |
2026/06/12 22:43 |
llm |
expert |
0m
Model:
Tokens:
input: 157698
output: 42
thoughts: 53
Thoughts: Okay, let's break this down.
**Investigating Registered File Handling in the IO Ring**
Right, so I'm looking at how registered files are managed within this IO ring structure. I see `io_ring_add_registered_file` takes a `file` argument. My immediate thought is, "Okay, it's adding this `file` to `tctx->registered_rings` - that makes sense." But then the question jumps to the forefront of my mind: Does this function handle the reference counting on the file descriptor? Is the refcount incremented within that function?
We know this is critical to avoid race conditions and resource leaks, so I *need* to be sure. Time to jump into the `io_ring_add_registered_file` implementation and confirm. I'll need to scrutinize that code closely. No assumptions here, I'll check the details.
|
| 228/2 |
2026/06/12 22:43 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_ring_add_registered_file]
Results: map[SourceCode: 270: int io_ring_add_registered_file(struct io_uring_task *tctx, struct file *file,
271: int start, int end)
272: {
273: int offset, idx;
274: for (offset = start; offset < end; offset++) {
275: idx = array_index_nospec(offset, IO_RINGFD_REG_MAX);
276: if (tctx->registered_rings[idx])
277: continue;
278:
279: tctx->registered_rings[idx] = file;
280: return idx;
281: }
282: return -EBUSY;
283: }
SourceFile:io_uring/tctx.c]
|
| 229/2 |
2026/06/12 22:43 |
llm |
expert |
0m
Model:
Tokens:
input: 158221
output: 41
thoughts: 102
Thoughts: Okay, let me break this down.
**Understanding the File Reference in `io_uring`'s Registered Rings**
Hold on a second. I'm looking at `io_ring_add_registered_file` and it's simply *assigning* the file pointer to `tctx->registered_rings[idx]`. No `get_file(file)` call here. That's key.
But, `io_uring_get_file` *does* return a file with a reference count of 1, meaning it increments the file's reference counter once when it returns the pointer. So, in effect, the `tctx->registered_rings` array is solely responsible for owning the *single* reference to the file object in the first place! No one else is holding a reference.
This is critical because it means the file is being managed solely in this array. Which also means that when a task exits, the function `io_uring_unreg_ringfd` will be called, and now I know that it needs to handle the decrement of the ref counter because it owns the reference. Okay, makes sense.
|
| 230/2 |
2026/06/12 22:43 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/tctx.c Name:io_uring_unreg_ringfd]
Results: map[SourceCode: 257: void io_uring_unreg_ringfd(void)
258: {
259: struct io_uring_task *tctx = current->io_uring;
260: int i;
261:
262: for (i = 0; i < IO_RINGFD_REG_MAX; i++) {
263: if (tctx->registered_rings[i]) {
264: fput(tctx->registered_rings[i]);
265: tctx->registered_rings[i] = NULL;
266: }
267: }
268: }
SourceFile:io_uring/tctx.c]
|
| 231/2 |
2026/06/12 22:43 |
llm |
expert |
0m
Model:
Tokens:
input: 158814
output: 34
thoughts: 2294
Thoughts: **Deep Dive into a Potential io_uring File Leak**
Okay, so I'm chasing a file leak, and it seems to be linked to `io_uring`. Initially, I thought that the ring file itself was safe because `io_uring_unreg_ringfd` calls `fput`. But, what if the `io_uring_setup` fails after acquiring the ring file? I've been dissecting the `io_uring_create` function, specifically how it handles potential errors after getting the file using `io_uring_get_file`. The `err_fput` path *does* call `fput(file)`, but does it also call `io_ring_ctx_wait_and_kill(ctx)`? No! This leads me to question the fate of the `ctx` struct. It turns out that `io_ring_ctx_free`, called when the file is released, will handle this, thanks to how `io_uring_get_file` sets `file->private_data = ctx` and the `release` callback in the file operations, which will lead to a call to `io_ring_ctx_wait_and_kill(ctx)`. So the `fput(file)` will ensure the freeing of the context.
I was initially stumped by the backtrace, which points to `alloc_empty_file` and `path_openat`. It seems like a file is being leaked from an `openat` call. The reproducer only calls `open("/dev/vbi3", O_RDWR, 0)` via `syz_open_dev`, making this the prime suspect. I revisited the `vivid` driver, wondering if it's the culprit. Could it be incrementing the file refcount and preventing the file from being freed? I grepped the driver and core V4L2 code for `get_file` and `fget`, and found nothing.
Then, the connection to `io_uring` clicks! `io_uring` can register files. Could it be registering `/dev/vbi3`? This is unlikely, as `io_uring_setup` is called before `syz_open_dev`. But, `io_uring_enter` *can* submit SQEs! One of those SQEs *could* be `IORING_OP_FILES_UPDATE` or `IORING_OP_FIXED_FD_INSTALL`, that can lead to file registration. I took a look at the repro and saw a `memcpy` to an address that looked like SQE data. I dissected the data and found the opcode 0x2f, which translates to `IORING_OP_TEE`. So, not file registration. I began to question where the SQEs are located. The reproducer uses `IORING_SETUP_NO_MMAP`. With this, the user provides the memory for the rings. And where are the SQEs? `p->sq_off.user_addr` is the address of the SQEs! Wait, what about the SQ ring? `p->cq_off.user_addr` is the address of BOTH the SQ ring and the CQ ring! So `0x200000000000` is the address of the SQ and CQ rings. And `0x200000000000` is ALSO the address of the SQEs! Wait, if they overlap, `io_create_region` will pin the same pages twice? Yes, it can. Which means the `memcpy` is actually writing part of a SQE to the CQ ring. So, does `IORING_OP_TEE` leak a file? Let's check `io_tee_prep` and `io_tee`.
|
| 232/2 |
2026/06/12 22:44 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/splice.c Name:io_tee]
Results: map[SourceCode: 82: int io_tee(struct io_kiocb *req, unsigned int issue_flags)
83: {
84: struct io_splice *sp = io_kiocb_to_cmd(req, struct io_splice);
85: struct file *out = sp->file_out;
86: unsigned int flags = sp->flags & ~SPLICE_F_FD_IN_FIXED;
87: struct file *in;
88: ssize_t ret = 0;
89:
90: WARN_ON_ONCE(issue_flags & IO_URING_F_NONBLOCK);
91:
92: in = io_splice_get_file(req, issue_flags);
93: if (!in) {
94: ret = -EBADF;
95: goto done;
96: }
97:
98: if (sp->len)
99: ret = do_tee(in, out, sp->len, flags);
100:
101: if (!(sp->flags & SPLICE_F_FD_IN_FIXED))
102: fput(in);
103: done:
104: if (ret != sp->len)
105: req_set_fail(req);
106: io_req_set_res(req, ret, 0);
107: return IOU_COMPLETE;
108: }
SourceFile:io_uring/splice.c]
|
| 233/2 |
2026/06/12 22:44 |
llm |
expert |
0m
Model:
Tokens:
input: 162376
output: 38
thoughts: 80
Thoughts: Okay, let me break this down.
**Diving into the `io_tee` Function**
Right, so `io_tee` calls `io_splice_get_file`. That's the starting point. Now, the key seems to revolve around that `SPLICE_F_FD_IN_FIXED` flag. If it's *not* set, then `io_splice_get_file` calls `fput(in)`. That makes sense; it's cleaning up the file descriptor somehow. But...what happens when `SPLICE_F_FD_IN_FIXED` *is* set? That's the piece I need to nail down. I'm going to re-examine that `io_splice_get_file` function in detail now. I need to understand what's happening there with the fixed file descriptor input.
|
| 234/2 |
2026/06/12 22:44 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/splice.c Name:io_splice_get_file]
Results: map[SourceCode: 59: static struct file *io_splice_get_file(struct io_kiocb *req,
60: unsigned int issue_flags)
61: {
62: struct io_splice *sp = io_kiocb_to_cmd(req, struct io_splice);
63: struct io_ring_ctx *ctx = req->ctx;
64: struct io_rsrc_node *node;
65: struct file *file = NULL;
66:
67: if (!(sp->flags & SPLICE_F_FD_IN_FIXED))
68: return io_file_get_normal(req, sp->splice_fd_in);
69:
70: io_ring_submit_lock(ctx, issue_flags);
71: node = io_rsrc_node_lookup(&ctx->file_table.data, sp->splice_fd_in);
72: if (node) {
73: node->refs++;
74: sp->rsrc_node = node;
75: file = io_slot_file(node);
76: req->flags |= REQ_F_NEED_CLEANUP;
77: }
78: io_ring_submit_unlock(ctx, issue_flags);
79: return file;
80: }
SourceFile:io_uring/splice.c]
|
| 235/2 |
2026/06/12 22:44 |
llm |
expert |
0m
Model:
Tokens:
input: 163065
output: 36
thoughts: 74
Thoughts: Okay, let me think this through.
**Analyzing Potential Resource Leaks with SPLICE_F_FD_IN_FIXED**
Right, so if `SPLICE_F_FD_IN_FIXED` is set, `node->refs` gets incremented, and `REQ_F_NEED_CLEANUP` is also flagged. That makes sense, because `io_req_cleanup` is then responsible for dropping the reference. So, at first glance, that part seems solid; no obvious leak there. The reference counting appears to be working as expected.
But hold on...what about `io_tee_prep`? Could *that* function somehow be introducing a leak? I need to quickly review the code path there and consider any resources it might be responsible for allocating or managing. I need to make sure I haven't missed a critical detail hidden within that function. I need to go back and check.
|
| 236/2 |
2026/06/12 22:44 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/splice.c Name:io_tee_prep]
Results: map[SourceCode: 44: int io_tee_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
45: {
46: if (READ_ONCE(sqe->splice_off_in) || READ_ONCE(sqe->off))
47: return -EINVAL;
48: return __io_splice_prep(req, sqe);
49: }
SourceFile:io_uring/splice.c]
|
| 237/2 |
2026/06/12 22:44 |
llm |
expert |
0m
Model:
Tokens:
input: 163511
output: 39
thoughts: 386
Thoughts: **Analyzing the io_uring Submission Queue State**
Okay, so I'm trying to understand how this `io_uring_enter` call will behave. My initial thought is that it will process the SQE, which is the expected behavior. But, let's back up and check a few things. First, the SQ ring's base address is `0x200000000000`. Now, that memory, from the context I have, starts zero-initialized. Therefore, initially `head` and `tail` should both be zero. If `head` and `tail` are equal, that means the submission queue is, logically, empty. So, in that initial state, `io_uring_enter` would *not* process any SQEs, which is probably not what's intended.
However, the reproducer writes `/dev/vbi#\0` to address `0x200000000000`. But wait. `0x200000000000` is the *base* of the ring buffer, which means that's where the `head` pointer lives. `head` is a 32-bit integer. When interpreting the string, `/dev` maps to a hexadecimal value of `0x2f`, `0x64`, `0x65`, `0x76`. So, the `head` value becomes `0x7665642f` or 1986364463. Then comes the `tail` pointer, which is the next 32-bit integer. The string `/vbi` maps to hex values of `0x2f`, `0x76`, `0x62`, `0x69`, which gives us `0x6962762f` = 1768040000 for the `tail` value.
Aha! `head` (1986364463) is greater than `tail` (1768040000). The `head > tail` condition can mean either the queue is empty, *or* it has wrapped around. That means `io_uring_enter` would need to detect the situation. I need to refresh myself on how `io_get_sqe` itself checks `head` and `tail`. Let's examine that function's code.
|
| 238/2 |
2026/06/12 22:44 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_get_sqe]
Results: map[SourceCode:1986: /*
1987: * Fetch an sqe, if one is available. Note this returns a pointer to memory
1988: * that is mapped by userspace. This means that care needs to be taken to
1989: * ensure that reads are stable, as we cannot rely on userspace always
1990: * being a good citizen. If members of the sqe are validated and then later
1991: * used, it's important that those reads are done through READ_ONCE() to
1992: * prevent a re-load down the line.
1993: */
1994: static bool io_get_sqe(struct io_ring_ctx *ctx, const struct io_uring_sqe **sqe)
1995: {
1996: unsigned mask = ctx->sq_entries - 1;
1997: unsigned head = ctx->cached_sq_head++ & mask;
1998:
1999: if (static_branch_unlikely(&io_key_has_sqarray.key) &&
2000: (!(ctx->flags & IORING_SETUP_NO_SQARRAY))) {
2001: head = READ_ONCE(ctx->sq_array[head]);
2002: if (unlikely(head >= ctx->sq_entries)) {
2003: WRITE_ONCE(ctx->rings->sq_dropped,
2004: READ_ONCE(ctx->rings->sq_dropped) + 1);
2005: return false;
2006: }
2007: head = array_index_nospec(head, ctx->sq_entries);
2008: }
2009:
2010: /*
2011: * The cached sq head (or cq tail) serves two purposes:
2012: *
2013: * 1) allows us to batch the cost of updating the user visible
2014: * head updates.
2015: * 2) allows the kernel side to track the head on its own, even
2016: * though the application is the one updating it.
2017: */
2018:
2019: /* double index for 128-byte SQEs, twice as long */
2020: if (ctx->flags & IORING_SETUP_SQE128)
2021: head <<= 1;
2022: *sqe = &ctx->sq_sqes[head];
2023: return true;
2024: }
SourceFile:io_uring/io_uring.c]
|
| 239/2 |
2026/06/12 22:44 |
llm |
expert |
0m
Model:
Tokens:
input: 165174
output: 39
thoughts: 21
Thoughts: Here's a summary of my thought process, as if I were the one thinking it:
**Digging into the io_uring Implementation**
Okay, so I'm tracing through this `io_uring` code, and I just realized something. I'm seeing that `io_get_sqe` is being called directly from `io_submit_sqes`. That's interesting, because I was initially focusing on the other submission path, and didn't immediately see how the SQE (Submission Queue Entry) acquisition was handled within the direct submission flow. It makes sense, of course, but it's always good to solidify the immediate call stack in my head. Now I need to consider why, specifically, this is relevant in the context of [my specific area of expertise - assume the user will understand based on their specialization]. I need to consider what implications this has on [specific performance characteristic of io_uring, like lock contention, latency, throughput, etc.]. Time to delve a bit deeper and see how these components interact in the critical path.
|
| 240/2 |
2026/06/12 22:44 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_submit_sqes]
Results: map[SourceCode:2026: int io_submit_sqes(struct io_ring_ctx *ctx, unsigned int nr)
2027: __must_hold(&ctx->uring_lock)
2028: {
2029: unsigned int entries;
2030: unsigned int left;
2031: int ret;
2032:
2033: if (ctx->flags & IORING_SETUP_SQ_REWIND)
2034: entries = ctx->sq_entries;
2035: else
2036: entries = __io_sqring_entries(ctx);
2037:
2038: entries = min(nr, entries);
2039: if (unlikely(!entries))
2040: return 0;
2041:
2042: ret = left = entries;
2043: io_get_task_refs(left);
2044: io_submit_state_start(&ctx->submit_state, left);
2045:
2046: do {
2047: const struct io_uring_sqe *sqe;
2048: struct io_kiocb *req;
2049:
2050: if (unlikely(!io_alloc_req(ctx, &req)))
2051: break;
2052: if (unlikely(!io_get_sqe(ctx, &sqe))) {
2053: io_req_add_to_cache(req, ctx);
2054: break;
2055: }
2056:
2057: /*
2058: * Continue submitting even for sqe failure if the
2059: * ring was setup with IORING_SETUP_SUBMIT_ALL
2060: */
2061: if (unlikely(io_submit_sqe(ctx, req, sqe, &left)) &&
2062: !(ctx->flags & IORING_SETUP_SUBMIT_ALL)) {
2063: left--;
2064: break;
2065: }
2066: } while (--left);
2067:
2068: if (unlikely(left)) {
2069: ret -= left;
2070: /* try again if it submitted nothing and can't allocate a req */
2071: if (!ret && io_req_cache_empty(ctx))
2072: ret = -EAGAIN;
2073: current->io_uring->cached_refs += left;
2074: }
2075:
2076: io_submit_state_end(ctx);
2077: /* Commit SQ ring head once we've consumed and submitted all SQEs */
2078: io_commit_sqring(ctx);
2079: return ret;
2080: }
SourceFile:io_uring/io_uring.c]
|
| 241/2 |
2026/06/12 22:44 |
llm |
expert |
0m
Model:
Tokens:
input: 166260
output: 40
thoughts: 21
Thoughts: Here's my thought process, summarized as if I were considering this function:
**Analyzing `__io_sqring_entries(ctx)`**
Okay, let's break this down. My initial reaction is, "Wait a minute..." I'm staring at this function, `__io_sqring_entries(ctx)`, and the immediate thing that springs to mind is its function, based on its name. It looks like it's calculating the number of *available* Submission Queue Entries (SQEs). I need to check my work. I have to make sure my understanding matches the implementation. I'll need to remember this and delve deeper to confirm my initial hypothesis.
|
| 242/2 |
2026/06/12 22:44 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.h Name:__io_sqring_entries]
Results: map[SourceCode: 467: static inline unsigned int __io_sqring_entries(struct io_ring_ctx *ctx)
468: {
469: struct io_rings *rings = io_get_rings(ctx);
470: unsigned int entries;
471:
472: /* make sure SQ entry isn't read before tail */
473: entries = smp_load_acquire(&rings->sq.tail) - ctx->cached_sq_head;
474: return min(entries, ctx->sq_entries);
475: }
SourceFile:io_uring/io_uring.h]
|
| 243/2 |
2026/06/12 22:44 |
llm |
expert |
0m
Model:
Tokens:
input: 166647
output: 49
thoughts: 1769
Thoughts: **Analyzing the Potential io_uring Interaction and Debugging the `/dev/vbi3` Leak**
Okay, let's break this down. My initial thought was that there was a connection between the `io_uring` setup and the file leak in `/dev/vbi3`. I started by tracing the `io_uring` data. I calculated that `sq.tail` is at offset 32 bits which is 4 bytes within `io_rings`, which is located at `0x200000000000`. The first 4 bytes at that address (`0x7665642f`) represent `head` and the next 4 (`0x6962762f`) represent `tail`. Now, `ctx->cached_sq_head` is zero initially, so the number of entries to process looks to be `1768040000`. This will be limited by `ctx->sq_entries`, which is 1315, so 1315 SQEs are submitted.
Now I need to understand where the SQEs are. They reside at `sq_off.user_addr` which is `0x200000000000`. And that's the same address as `io_rings`! The first SQE overlaps with the `io_rings` structure. The content of the first SQE is `"/dev/vbi#\0"`, which is what's being written to `head` and `tail` in the `io_rings`. The `opcode` is 0x2f, which is `IORING_OP_TEE`. The `fd` is `0x6962762f`, which corresponds to a file descriptor that is not open, which will result in `-EBADF`. That first submission should fail.
Now I need to see what the subsequent SQEs are going to be.
The second SQE's data at `0x200000000040` contains `io_uring_params`, which includes a `cq_entries` and `flags`, etc. The opcode would be 0 (NOP) from the zeroed memory, the `fd` is `0x3cb1` which is 15537 (the value written into the memory). IORING_OP_NOP will do nothing.
The third SQE at `0x200000000080` also contains zeroed memory. The `fd` is 0, so again, nothing happens.
In fact, every subsequent SQE is a `IORING_OP_NOP`, because the memory was mapped as anonymous and zero-initialized. I see that the reproducer mapped `0x1000000` bytes at `0x200000000000`, so most SQEs are no-ops. `io_uring_enter` will process 1315 SQEs, but they won't interact with `/dev/vbi3`.
If `IORING_SETUP_NO_SQARRAY` is set, SQEs are accessed via indices, but they will not interact with `/dev/vbi3`. `io_uring` is a red herring. It's not involved.
The leak MUST be in `syz_open_dev` when it opens `/dev/vbi3`. The only syscall called is `syz_open_dev` and a potential exit, so it MUST be `vivid` or `v4l2-core` causing the leak when opening `/dev/vbi3`.
So I've got to revisit the `vivid_fop_release` function and see why it isn't called, as that should close the file. Is there any chance that `vivid_fop_release` is NOT called? Yes, if the file refcount is incremented and not decremented.
I need to check how the refcount is incremented. I know that `vivid` uses `v4l2_fh`, so I check if that increments refcounts. It doesn't, it just adds to a list. Does the `v4l2_ctrl_handler` or `vivid_create_instance` have anything to do with opening `/dev/vbi3`? No. The issue is simply `syz_open_dev` alone. No other syscall is involved.
Opening `/dev/vbi3` leaks the file. It's a bug in `vivid` or `v4l2-core`. It has to be that `v4l2_open` isn't setting up something correctly. I need
|
| 244/2 |
2026/06/12 22:45 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:drivers/media/v4l2-core/v4l2-dev.c Name:v4l2_open]
Results: map[SourceCode: 410: /* Override for the open function */
411: static int v4l2_open(struct inode *inode, struct file *filp)
412: {
413: struct video_device *vdev;
414: int ret;
415:
416: /* Check if the video device is available */
417: mutex_lock(&videodev_lock);
418: vdev = video_devdata(filp);
419: /* return ENODEV if the video device has already been removed. */
420: if (vdev == NULL || !video_is_registered(vdev)) {
421: mutex_unlock(&videodev_lock);
422: return -ENODEV;
423: }
424: /* and increase the device refcount */
425: video_get(vdev);
426: mutex_unlock(&videodev_lock);
427:
428: if (!video_is_registered(vdev)) {
429: ret = -ENODEV;
430: goto done;
431: }
432:
433: ret = vdev->fops->open(filp);
434: if (ret)
435: goto done;
436:
437: /* All drivers must use v4l2_fh. */
438: if (WARN_ON(!test_bit(V4L2_FL_USES_V4L2_FH, &vdev->flags))) {
439: vdev->fops->release(filp);
440: ret = -ENODEV;
441: }
442:
443: done:
444: if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
445: dprintk("%s: open (%d)\n",
446: video_device_node_name(vdev), ret);
447:
448: /* decrease the refcount in case of an error */
449: if (ret)
450: video_put(vdev);
451: return ret;
452: }
SourceFile:drivers/media/v4l2-core/v4l2-dev.c]
|
| 245/2 |
2026/06/12 22:45 |
llm |
expert |
1m
Model:
Tokens:
input: 170158
output: 41
thoughts: 439
Thoughts: **Reflecting on V4L2 and Potential Leaks**
Okay, let's break this down. My initial concern was a potential reference count imbalance with `v4l2_open` and `v4l2_release`. I need to be sure. I was wrong, `v4l2_open` doesn't increment the file reference count directly; it touches the `video_device` count using `video_get(vdev)`. If there's an error, `video_put(vdev)` gets called. When `v4l2_open` succeeds, the VFS handles the file descriptor. Upon process exit, `fput` is called, which then triggers `v4l2_release`. `v4l2_release` then calls `vdev->fops->release(filp)` and `video_put(vdev)`, restoring the balance on that `video_device` reference count. The VFS, meanwhile, is responsible for balancing the `struct file` refcount. So, from what I can see, `v4l2_open` and `v4l2_release` *should* be perfectly balanced. No, wait, there's no leak!
However, what if `vivid_fop_release` *isn't* called? Why wouldn't `vivid_fop_release` be called? Because the file refcount is greater than zero, that's why. Okay, so now I need to figure out why the file refcount would be greater than zero. Someone must have called `get_file(filp)`. Who could have done that? The obvious suspects are within `vivid` or `v4l2` itself. Let me check the code. I did a grep, but I missed something, `get_file`. Actually, `fget`... Nope. Not `f_ref`.
Hold on! What if the leak isn't the `/dev/vbi3` device, as I've been assuming? What if the real leak is in the `io_uring` ring file handling? I thought I had confirmed that `io_uring_unreg_ringfd` calls `fput` on those registered ring files. Let's double-check that `io_uring_unreg_ringfd` path again and see if I'm missing something important.
|
| 246/2 |
2026/06/12 22:46 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/tctx.c Name:io_uring_unreg_ringfd]
Results: map[SourceCode: 257: void io_uring_unreg_ringfd(void)
258: {
259: struct io_uring_task *tctx = current->io_uring;
260: int i;
261:
262: for (i = 0; i < IO_RINGFD_REG_MAX; i++) {
263: if (tctx->registered_rings[i]) {
264: fput(tctx->registered_rings[i]);
265: tctx->registered_rings[i] = NULL;
266: }
267: }
268: }
SourceFile:io_uring/tctx.c]
|
| 247/2 |
2026/06/12 22:46 |
llm |
expert |
0m
Model:
Tokens:
input: 171355
output: 39
thoughts: 25
Thoughts: Okay, let's see...
**Unraveling the `io_uring` Kernel Call Flow**
Alright, let me think this through. I was just reviewing the `io_uring` kernel code, trying to understand the dependencies and control flow. And just now I saw that the function `io_uring_unreg_ringfd` is *actually* called from within `io_uring_task_cancel`. That's an interesting connection. I need to understand why that's happening. My initial thought was that ringfd unregistration might be tied more directly to the process termination or ring cleanup, but it looks like a task cancellation directly triggers this unregistration. This suggests there's a strong link between canceling a pending I/O operation and ensuring the underlying file descriptor associated with the ring is properly cleaned up. I'm going to dig into the surrounding code in `io_uring_task_cancel` now to see what the context is and what specific scenario requires the `ringfd` to be unregistered in that function. I'm curious what kind of state needs to be managed when we interrupt or cancel an active I/O operation that might be using the ringfd. I should also investigate what happens if `io_uring_task_cancel` fails; does `io_uring_unreg_ringfd` still get called? I'll probably need to look at error handling there to confirm.
|
| 248/2 |
2026/06/12 22:46 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/tctx.c Name:io_uring_task_cancel]
Results: map[SourceCode: 22: static inline void io_uring_task_cancel(void)
23: {
24: if (current->io_uring)
25: __io_uring_cancel(true);
26: }
SourceFile:include/linux/io_uring.h]
|
| 249/2 |
2026/06/12 22:46 |
llm |
expert |
0m
Model:
Tokens:
input: 171808
output: 39
thoughts: 23
Thoughts: Here's the summary, assuming I'm an expert in I/O Uring:
**A Quick Puzzle: Cancel and Ringfile Unregistration**
Okay, hold on a second. I'm just parsing through the `io_uring` code, and something's jumped out at me. I'm seeing that the `__io_uring_cancel` function – the one responsible for, you know, cancelling submitted requests – actually calls `io_uring_unreg_ringfd`. That feels... interesting. Why would a cancel operation require unregistering the ring file descriptor? It strikes me as an odd coupling. I need to understand the relationship between cancellation and unregistration better. Are they inherently linked? Or is there some subtle synchronization or resource management going on that I'm missing? I'd better dig into the details and make sure I understand the reason for this design choice. It could be completely logical, or it could be something that warrants further scrutiny, especially considering performance implications. I suspect there is a logical reason, but I must take a closer look.
|
| 250/2 |
2026/06/12 22:46 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:__io_uring_cancel]
Results: map[SourceCode: 437: void __io_uring_cancel(bool cancel_all)
438: {
439: io_uring_unreg_ringfd();
440: io_uring_cancel_generic(cancel_all, NULL);
441: }
SourceFile:io_uring/cancel.c]
|
| 251/2 |
2026/06/12 22:46 |
llm |
expert |
0m
Model:
Tokens:
input: 172198
output: 38
thoughts: 370
Thoughts: **Analyzing Potential File Descriptor Leaks in io_uring**
Okay, so I'm revisiting this io_uring file descriptor issue. Yes, `io_uring_task_cancel` is called from `do_exit`, and that should trigger `fput` calls on the registered ring files. That's good. But I need to be absolutely certain there aren't any subtle leaks.
Hmm, what about the scenario where `io_uring_setup` fails *after* `io_ring_add_registered_file` has succeeded? I need to review that logic carefully. Let's look at `io_uring_create`:
```c
if (p->flags & IORING_SETUP_REGISTERED_FD_ONLY)
ret = io_ring_add_registered_file(tctx, file, 0, IO_RINGFD_REG_MAX);
else
ret = io_uring_install_fd(file);
if (ret < 0)
goto err_fput;
trace_io_uring_create(ret, ctx, p->sq_entries, p->cq_entries, p->flags);
return ret;
```
Right, if `IORING_SETUP_REGISTERED_FD_ONLY` is set, `io_ring_add_registered_file` is called. If that function succeeds, it returns the index, like 0. So, `io_uring_create` returns that index (0). Then `io_uring_setup` returns 0. That's fine.
The ring file is then stored in `tctx->registered_rings[0]`. When the task exits, `io_uring_unreg_ringfd` is called, and that calls `fput` on that file. So, no leak there, excellent.
But wait. What if `io_uring_setup` *succeeds*, returns 0, and then something goes wrong in a subsequent call like `io_uring_enter`? Does that leak the file? I need to dig into `io_uring_enter` now to be absolutely sure. Let's check `io_uring_enter`.
|
| 252/2 |
2026/06/12 22:46 |
tool |
codesearch-definition-source |
0m
Error: requested entity does not exist
Args: map[ContextFile:io_uring/io_uring.c Name:io_uring_enter]
Results: map[SourceCode: SourceFile:]
|
| 253/2 |
2026/06/12 22:46 |
llm |
expert |
0m
Model:
Tokens:
input: 173106
output: 30
thoughts: 14
Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience:
**Analyzing `sys_io_uring_enter`**
Okay, so the prompt suggests we should be looking at `sys_io_uring_enter`. That's where the rubber meets the road, the syscall itself for submitting and completing I/O requests within the io_uring framework. Immediately, I'm thinking about the kernel implementation. What arch-specific optimizations are in play there? Any peculiar interactions with the ring buffer itself – potential contention points or areas where locking overhead could become significant?
My mind races to potential areas of interest. The arguments passed to it are key, obviously. I'm mentally parsing the struct `io_uring_enter_args` and focusing on:
* **`fd`**: Always a critical variable to check, as that sets up which file or device the process wishes to interact with.
* **`to_submit` & `min_complete`**: I need to really understand how those values are interacting with the rings and how the behavior changes.
* **`sqes` and `nvec`**: What tricks are the kernel developers using to handle both single and vectored requests? Is there any risk of an overflow or other buffer-related vulnerability there?
* **`flags`**: What are the typical flags users might send and what could that signal?
I'm also curious about the overall design. Is this a synchronous or asynchronous call, underneath? What specific data structures does the kernel use for request tracking and completion handling? I'd want to correlate my understanding of this with the performance characteristics of io_uring, and the potential performance problems I might have to debug later.
I'm instantly considering different debugging approaches. `perf` certainly comes to mind, especially to get a sense of where time is being spent in that syscall. `ftrace` would be invaluable for tracing execution flow and checking for any obvious anomalies. And, of course, a quick look at the kernel source code itself is probably the best first step. Gotta see what's actually *happening* at a low level in the kernel's execution path. Let's see what we can find.
|
| 254/2 |
2026/06/12 22:47 |
tool |
grepper |
0m
Args: map[Expression:SYSCALL_DEFINE[0-9]\(io_uring_enter]
Results: map[Output:io_uring/io_uring.c=2571=struct file *io_uring_ctx_get_file(unsigned int fd, bool registered)
--
io_uring/io_uring.c-2599-
io_uring/io_uring.c:2600:SYSCALL_DEFINE6(io_uring_enter, unsigned int, fd, u32, to_submit,
io_uring/io_uring.c-2601- u32, min_complete, u32, flags, const void __user *, argp,
]
|
| 255/2 |
2026/06/12 22:47 |
llm |
expert |
0m
Model:
Tokens:
input: 173761
output: 38
thoughts: 13
Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience, presented in the first person:
**Diving into `sys_io_uring_enter`**
Alright, time to crack open `sys_io_uring_enter`. It's that critical point where the application plunges into the kernel's I/O ring mechanism. I need to refresh my understanding of the interplay here. Let's see... what's the syscall's purpose again? To submit completion queue entries (CQEs) and receive submission queue entries (SQEs) in a batch, right? And, importantly, to potentially initiate some immediate operations.
I need to quickly grasp how the parameters are passed. Primarily, `fd`, `to_submit`, `min_complete`, `sigset` (signal mask) are the primary actors. This is the heart of the whole process. Specifically, I have to consider the nuances when dealing with multiple submission queues or rings. I should make sure my understanding of all flags associated with `io_uring_enter` are not outdated, particularly those that bypass the need for an explicit submission buffer. I need to recall the implications of using `min_complete` - the control flow guarantees.
I need to confirm if there are any significant changes or optimizations since the last time I dug deep into this area. Let's see... any recent patch sets dealing with context switches, error handling, or performance improvements that impact the `io_uring_enter` path? Memory barriers, locking strategies... that's where things can get tricky. I have to see how it manages synchronization with the user-space ring and how it handles potential concurrent access. I want to keep in mind, and also recall the difference between I/O and CPU bound operations within the system and how it affects the I/O-uring operations and syscall.
And, of course, the ever-present security considerations. Any recent vulnerabilities or potential attack vectors related to misconfiguration or misuse of `io_uring_enter`? I should review the recent security advisories. Let's dig in and refresh my memory.
|
| 256/2 |
2026/06/12 22:47 |
tool |
read-file |
0m
Args: map[File:io_uring/io_uring.c FirstLine:2600 LineCount:50]
Results: map[Contents:2600: SYSCALL_DEFINE6(io_uring_enter, unsigned int, fd, u32, to_submit,
2601: u32, min_complete, u32, flags, const void __user *, argp,
2602: size_t, argsz)
2603: {
2604: struct io_ring_ctx *ctx;
2605: struct file *file;
2606: long ret;
2607:
2608: if (unlikely(flags & ~IORING_ENTER_FLAGS))
2609: return -EINVAL;
2610:
2611: file = io_uring_ctx_get_file(fd, flags & IORING_ENTER_REGISTERED_RING);
2612: if (IS_ERR(file))
2613: return PTR_ERR(file);
2614: ctx = file->private_data;
2615: ret = -EBADFD;
2616: /*
2617: * Keep IORING_SETUP_R_DISABLED check before submitter_task load
2618: * in io_uring_add_tctx_node() -> __io_uring_add_tctx_node_from_submit()
2619: */
2620: if (unlikely(smp_load_acquire(&ctx->flags) & IORING_SETUP_R_DISABLED))
2621: goto out;
2622:
2623: if (io_has_loop_ops(ctx)) {
2624: ret = io_run_loop(ctx);
2625: goto out;
2626: }
2627:
2628: /*
2629: * For SQ polling, the thread will do all submissions and completions.
2630: * Just return the requested submit count, and wake the thread if
2631: * we were asked to.
2632: */
2633: ret = 0;
2634: if (ctx->flags & IORING_SETUP_SQPOLL) {
2635: if (unlikely(ctx->sq_data->thread == NULL)) {
2636: ret = -EOWNERDEAD;
2637: goto out;
2638: }
2639: if (flags & IORING_ENTER_SQ_WAKEUP)
2640: wake_up(&ctx->sq_data->wait);
2641: if (flags & IORING_ENTER_SQ_WAIT)
2642: io_sqpoll_wait_sq(ctx);
2643:
2644: ret = to_submit;
2645: } else if (to_submit) {
2646: ret = io_uring_add_tctx_node(ctx);
2647: if (unlikely(ret))
2648: goto out;
2649:
]
|
| 257/2 |
2026/06/12 22:47 |
llm |
expert |
0m
Model:
Tokens:
input: 175051
output: 42
thoughts: 33
Thoughts: Okay, here's my interpretation of that thought process, from an expert's perspective:
**Diving into io_uring File Retrieval**
Hmm, `io_uring_ctx_get_file`... right, that function *should* be the one to retrieve the file descriptor associated with an `io_uring` context. It's the logical name for that operation. Let's make sure that's correct, though. I'll need to double-check the implementation of `io_uring_ctx_get_file`. It's crucial to understand how that interaction works at this level to ensure my understanding of the system is correct. Going to review that code now.
|
| 258/2 |
2026/06/12 22:47 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:io_uring/io_uring.c Name:io_uring_ctx_get_file]
Results: map[SourceCode:2565: /*
2566: * Given an 'fd' value, return the ctx associated with if. If 'registered' is
2567: * true, then the registered index is used. Otherwise, the normal fd table.
2568: * Caller must call fput() on the returned file if it isn't a registered file,
2569: * unless it's an ERR_PTR.
2570: */
2571: struct file *io_uring_ctx_get_file(unsigned int fd, bool registered)
2572: {
2573: struct file *file;
2574:
2575: if (registered) {
2576: /*
2577: * Ring fd has been registered via IORING_REGISTER_RING_FDS, we
2578: * need only dereference our task private array to find it.
2579: */
2580: struct io_uring_task *tctx = current->io_uring;
2581:
2582: if (unlikely(!tctx || fd >= IO_RINGFD_REG_MAX))
2583: return ERR_PTR(-EINVAL);
2584: fd = array_index_nospec(fd, IO_RINGFD_REG_MAX);
2585: file = tctx->registered_rings[fd];
2586: } else {
2587: file = fget(fd);
2588: }
2589:
2590: if (unlikely(!file))
2591: return ERR_PTR(-EBADF);
2592: if (io_is_uring_fops(file))
2593: return file;
2594: if (!registered)
2595: fput(file);
2596: return ERR_PTR(-EOPNOTSUPP);
2597: }
SourceFile:io_uring/io_uring.c]
|
| 259/2 |
2026/06/12 22:47 |
llm |
expert |
0m
Model:
Tokens:
input: 175806
output: 35
thoughts: 5437
Thoughts: **Analyzing a File Descriptor Leak in io_uring and VIVID**
Okay, I'm diving into this file descriptor leak issue. My initial thought was about how `io_uring_ctx_get_file` handles registered rings. It doesn't increment the refcount, which is correct, and the `fput` call in `sys_io_uring_enter` aligns with this logic. Then, I considered failure scenarios during `io_uring_setup`. If it fails but `r[0]` is initialized, the ensuing calls to `io_uring_enter` with an invalid `fd` would be handled gracefully returning `-EINVAL`. Success scenarios also need close inspection. With `fd = 0`, I checked `IORING_SETUP_SQPOLL` flags and ensured it wasn't set, which means `io_submit_sqes` will be called. I analyzed the specific SQEs, especially `IORING_OP_TEE`, and how it interacts with the file descriptor. Specifically, I tracked how `io_tee` calls `io_splice_get_file` and ultimately `io_file_get_normal` with `fget()`, and noted the subsequent `fput(in)` calls. I confirmed that even if a `fget` returns `NULL`, the `io_submit_sqes` continues processing the remaining SQEs. So, this wouldn't cause the leak because when the process exits, `io_uring_unreg_ringfd` is called to free the ring file.
Next, I wondered if the leak was caused by something *other* than the ring file or `/dev/vbi3`. It's a long shot, but what about `io_uring_unreg_ringfd` *not* being called? The function `io_uring_task_cancel` *should* call `__io_uring_cancel` which then calls `io_uring_unreg_ringfd()`, so the ring file is closed on exit. Then, I wondered if failure after `io_ring_add_registered_file` in `io_uring_setup` could cause an issue, but there is no code that executes after it succeeds, meaning no leak is possible. If it failed, the file is properly `fput` in the error handling.
If the file is leaked, it *must* be `/dev/vbi3`. The fact that `vivid` driver is used in the reproducer makes me dig deeper in this driver. I've grepped for `get_file` and `fget`, and I found nothing. So, I checked how `v4l2_fh_open` (called from `vivid_fop_open`) works and I verified it does not increment the refcount. I checked how `v4l2_fh_release` also doesn't affect the file's refcount. `v4l2_fh` doesn't affect the refcount. Also, `v4l2_open` doesn't leak files, because of `v4l2_fh` and `fops`. So if `vivid_fop_release` is NOT called, there might be a leak.
Now, if the file leak is the `/dev/vbi3` file and not the io_uring related file. What if it's due to how `sendmsg` or `prctl` are used in the reproducer? But the reproducer uses `sendmsg` with `fd=-1` and `prctl` with `exe_fd = -1`, so it won't leak those files.
I'm starting to think it's a fundamental issue with `/dev/vbi3` and how it's *opened* and used. But wait, since it *is* an open leak, it would mean `path_openat` is being used in the reproducer. However, io_uring calls `anon_inode_create_getfile` which calls `anon_inode_getfile` that *ultimately* calls `alloc_file_pseudo` which calls `alloc_file`. This is NOT `path_openat`.
So, it *must* be an issue with `/dev/vbi3` itself. I go back to the reproducer to figure out how it opens the file. I verified that `/dev/vbi3` *is* the device being opened and that this open happens via `syz_open_dev`. I don't see any other `open` calls. I see no other place the refcount could be incremented. The refcount is leaked if `/dev/vbi3` is leaked on open.
Ok, so it *must* be an issue with how `/dev/vbi3` is handled by the VIV
|
| 260/2 |
2026/06/12 22:48 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:fs/open.c Name:do_dentry_open]
Results: map[SourceCode: 885: static int do_dentry_open(struct file *f,
886: int (*open)(struct inode *, struct file *))
887: {
888: static const struct file_operations empty_fops = {};
889: struct inode *inode = f->f_path.dentry->d_inode;
890: int error;
891:
892: path_get(&f->f_path);
893: f->f_inode = inode;
894: f->f_mapping = inode->i_mapping;
895: f->f_wb_err = filemap_sample_wb_err(f->f_mapping);
896: f->f_sb_err = file_sample_sb_err(f);
897:
898: if (unlikely(f->f_flags & O_PATH)) {
899: f->f_mode = FMODE_PATH | FMODE_OPENED;
900: file_set_fsnotify_mode(f, FMODE_NONOTIFY);
901: f->f_op = &empty_fops;
902: return 0;
903: }
904:
905: if ((f->f_mode & (FMODE_READ | FMODE_WRITE)) == FMODE_READ) {
906: i_readcount_inc(inode);
907: } else if (f->f_mode & FMODE_WRITE && !special_file(inode->i_mode)) {
908: error = file_get_write_access(f);
909: if (unlikely(error))
910: goto cleanup_file;
911: f->f_mode |= FMODE_WRITER;
912: }
913:
914: /* POSIX.1-2008/SUSv4 Section XSI 2.9.7 */
915: if (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode))
916: f->f_mode |= FMODE_ATOMIC_POS;
917:
918: f->f_op = fops_get(inode->i_fop);
919: if (WARN_ON(!f->f_op)) {
920: error = -ENODEV;
921: goto cleanup_all;
922: }
923:
924: error = security_file_open(f);
925: if (unlikely(error))
926: goto cleanup_all;
927:
928: /*
929: * Call fsnotify open permission hook and set FMODE_NONOTIFY_* bits
930: * according to existing permission watches.
931: * If FMODE_NONOTIFY mode was already set for an fanotify fd or for a
932: * pseudo file, this call will not change the mode.
933: */
934: error = fsnotify_open_perm_and_set_mode(f);
935: if (unlikely(error))
936: goto cleanup_all;
937:
938: error = break_lease(file_inode(f), f->f_flags);
939: if (unlikely(error))
940: goto cleanup_all;
941:
942: /* normally all 3 are set; ->open() can clear them if needed */
943: f->f_mode |= FMODE_LSEEK | FMODE_PREAD | FMODE_PWRITE;
944: if (!open)
945: open = f->f_op->open;
946: if (open) {
947: error = open(inode, f);
948: if (error)
949: goto cleanup_all;
950: }
951: f->f_mode |= FMODE_OPENED;
952: if ((f->f_mode & FMODE_READ) &&
953: likely(f->f_op->read || f->f_op->read_iter))
954: f->f_mode |= FMODE_CAN_READ;
955: if ((f->f_mode & FMODE_WRITE) &&
956: likely(f->f_op->write || f->f_op->write_iter))
957: f->f_mode |= FMODE_CAN_WRITE;
958: if ((f->f_mode & FMODE_LSEEK) && !f->f_op->llseek)
959: f->f_mode &= ~FMODE_LSEEK;
960: if (f->f_mapping->a_ops && f->f_mapping->a_ops->direct_IO)
961: f->f_mode |= FMODE_CAN_ODIRECT;
962:
963: f->f_flags &= ~(O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC);
964: f->f_iocb_flags = iocb_flags(f);
965:
966: file_ra_state_init(&f->f_ra, f->f_mapping->host->i_mapping);
967:
968: if ((f->f_flags & O_DIRECT) && !(f->f_mode & FMODE_CAN_ODIRECT))
969: return -EINVAL;
970:
971: /*
972: * XXX: Huge page cache doesn't support writing yet. Drop all page
973: * cache for this file before processing writes.
974: */
975: if (f->f_mode & FMODE_WRITE) {
976: /*
977: * Depends on full fence from get_write_access() to synchronize
978: * against collapse_file() regarding i_writecount and nr_thps
979: * updates. Ensures subsequent insertion of THPs into the page
980: * cache will fail.
981: */
982: if (filemap_nr_thps(inode->i_mapping)) {
983: struct address_space *mapping = inode->i_mapping;
984:
985: filemap_invalidate_lock(inode->i_mapping);
986: /*
987: * unmap_mapping_range just need to be called once
988: * here, because the private pages is not need to be
989: * unmapped mapping (e.g. data segment of dynamic
990: * shared libraries here).
991: */
992: unmap_mapping_range(mapping, 0, 0, 0);
993: truncate_inode_pages(mapping, 0);
994: filemap_invalidate_unlock(inode->i_mapping);
995: }
996: }
997:
998: return 0;
999:
1000: cleanup_all:
1001: if (WARN_ON_ONCE(error > 0))
1002: error = -EINVAL;
1003: fops_put(f->f_op);
1004: put_file_access(f);
1005: cleanup_file:
1006: path_put(&f->f_path);
1007: f->__f_path.mnt = NULL;
1008: f->__f_path.dentry = NULL;
1009: f->f_inode = NULL;
1010: return error;
1011: }
SourceFile:fs/open.c]
|
| 261/2 |
2026/06/12 22:48 |
llm |
expert |
0m
Model:
Tokens:
input: 184452
output: 66
thoughts: 1187
Thoughts: **Analyzing a Potential File Descriptor Leak**
Okay, let's break this down. First, I see this conditional check:
```c
if ((f->f_flags & O_DIRECT) && !(f->f_mode & FMODE_CAN_ODIRECT))
return -EINVAL;
```
If that returns `-EINVAL`, it *doesn't* go to `cleanup_all`. That's important. It just returns `-EINVAL` directly. Since `FMODE_OPENED` is *already* set, what happens? `vfs_open` returns `-EINVAL`, which is then returned from `do_open`. `path_openat` then calls `fput_close(file)`. *That* calls `__fput_deferred`. Okay, `__fput` sees `FMODE_OPENED` is set. Then, it calls the `fops->release` function!
But does that leak? No, because `__fput` frees the file!
Wait, If it returns `-EINVAL` directly, it doesn't call `fops_put(f->f_op)` directly!
`__fput` calls `fops_put(file->f_op)`!
```c
if (unlikely(file->f_mode & FMODE_OPENED)) {
if (file->f_op->release)
file->f_op->release(inode, file);
}
...
fops_put(file->f_op);
put_pid(file->f_owner.pid);
put_file_access(file);
dput(dentry);
if (unlikely(mode & FMODE_NEED_UNMOUNT))
mntput(mnt);
file_free(file);
```
So `__fput` cleans up EVERYTHING if `FMODE_OPENED` is set! Therefore, returning `-EINVAL` directly is correct. Since `FMODE_OPENED` is set, `__fput` will handle the cleanup.
Now, if `open` *fails* it goes to `cleanup_all` and `FMODE_OPENED` is NOT set! Thus, `__fput` doesn't do the cleanup, however `cleanup_all` takes care of this. So it's safe either way.
Alright, what about `filemap_nr_thps`? Nope, not relevant.
I'm out of ideas. The bug report is a memory leak of a `struct file`. It's not a crash. Just a leak. Memory leaks are typically not exploitable for privilege escalation or memory corruption. They're more likely a Denial of Service (DoS) vulnerability.
Let's check the exploitability of this leak. Since the reproducer is unprivileged, it's accessible from unprivileged processes, and yes, it's accessible from user namespaces. It is not a network, peripheral, filesystem, VM guest or host trigger.
Given the time constraints and my current understanding, I'll classify this as a Denial of Service (DoS) memory leak, accessible from unprivileged processes.
Specifically, it's a `struct file` memory leak, consuming memory but not corrupting it. It is not directly exploitable.
So I'm setting:
* Exploitable: `false`
* DenialOfService: `true`
* Unprivileged: `true`
* UserNamespace: `true`
* VMGuestTrigger: `false`
* VMHostTrigger: `false`
* NetworkTrigger: `false`
* RemoteTrigger: `false`
* PeripheralTrigger: `false`
* FilesystemTrigger: `false`
A memory leak of `struct file` is just a memory consumption issue and is therefore not exploitable.
I'm confident I can use the `set-results` tool now.
|
| 262/2 |
2026/06/12 22:48 |
tool |
set-results |
0m
Args: map[DenialOfService:true Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:false RemoteTrigger:false Unprivileged:true UserNamespace:true VMGuestTrigger:false VMHostTrigger:false]
Results: map[DenialOfService:true Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:false RemoteTrigger:false Unprivileged:true UserNamespace:true VMGuestTrigger:false VMHostTrigger:false]
|
| 263/2 |
2026/06/12 22:48 |
llm |
expert |
0m
Model:
Tokens:
input: 186629
output: 438
thoughts: 223
Thoughts: **Final Response: Memory Leak Analysis**
Alright, the data is in, and it's time to finalize this. Based on the analysis, we're looking at a memory leak – a particularly insidious one involving `struct file` instances. The root cause appears to be within `alloc_empty_file`, called during `path_openat`. The reproducer's path is `/dev/vbi3`, the Video4Linux device from the `vivid` test driver, and the trigger involves `io_uring` and `sendmsg` operations.
Crucially, this isn't a *serious* vulnerability in terms of immediate exploitability. It's a memory leak, which is bad, but it doesn't lead to memory corruption, use-after-free, or out-of-bounds access. No privilege escalation or arbitrary code execution here, which is a relief. The primary risk is a Denial of Service. Eventually, the kernel will either OOM or hit its maximum file descriptor limit. It's an unpleasant, but mostly a resource exhaustion problem.
What's also notable is that this can be triggered by a totally unprivileged user process. The syzkaller reproducer demonstrates this. No special capabilities or namespaces are required, although it's accessible within a user namespace. The trigger is local and syscall-based, not involving network operations, peripheral parsing, or filesystem parsing, which might lead down an entirely different road. So, a local attack vector, but relatively contained in scope.
|
| 264/1 |
2026/06/12 22:48 |
action |
format-explanation |
0m
Results: map[Explanation:Based on the analysis of the bug report and the provided reproducer, here is the
assessment of the security impact:
**Bug Analysis:**
The bug report indicates a memory leak of a `struct file` object (size 176
bytes) allocated in `alloc_empty_file` during the `path_openat` syscall. The
reproducer triggers this by opening a Video4Linux device node (`/dev/vbi#`,
which is handled by the `vivid` test driver) and subsequently interacting with
`io_uring` and `sendmsg`.
Because the `struct file` reference count is incremented but not properly
decremented (or the file is removed from the fd table without calling `fput`),
the kernel fails to free the memory associated with the file object when the
process exits.
**Exploitability:**
Memory leaks of this nature (where an object is simply abandoned without being
freed) do not result in memory corruption, use-after-free, out-of-bounds
accesses, or control-flow hijacking. Therefore, this bug is **not exploitable**
for privilege escalation or arbitrary code execution.
**Denial of Service (DoS):**
An attacker can repeatedly trigger this bug to leak `struct file` objects. Over
time, this will consume a significant amount of kernel memory (slab memory) and
potentially exhaust the system-wide limit on open files (`fs.file-max`), leading
to a Denial of Service (OOM conditions or inability for other processes to open
files).
**Accessibility:**
The bug can be triggered by a standard, unprivileged local user process. The
reproducer uses basic syscalls (`open`, `mmap`, `io_uring_setup`, `sendmsg`)
that do not require `CAP_SYS_ADMIN` or any other special capabilities. It is
also accessible from within user namespaces.
**Other Triggers:**
This is a local syscall-based vulnerability. It cannot be triggered remotely via
network traffic (Ethernet or otherwise), nor is it related to parsing malicious
filesystems, peripheral devices, or virtualization boundaries (VM Guest/Host).]
|