Re: Uninitialized Stack Variable / NULL Pointer Dereference in __sys_socket_create via BPF LSM hooks

[Jiayuan Chen <jiayuan.chen@linux.dev>]

On 4/21/26 2:32 PM, Quan Sun wrote:
> Our fuzzing found an Uninitialized Stack Variable vulnerability in the 
> Linux Socket Subsystem. The issue is triggered when a 
> `BPF_PROG_TYPE_LSM` attached to the `bpf_lsm_socket_create` cgroup 
> hook uses the `bpf_set_retval()` helper to return a value greater than 
> 0 (e.g., `1`). This bypasses the actual `socket_create` execution but 
> returns a success status back to `__sys_socket_create`, which then 
> accesses the uninitialized stack variable `sock` leading to a NULL 
> pointer dereference or potential privilege escalation.
>
> Reported-by: Quan Sun <2022090917019@std.uestc.edu.cn>
> Reported-by: Yinhao Hu <dddddd@hust.edu.cn>
> Reported-by: Kaiyan Mei <M202472210@hust.edu.cn>
> Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
>
> ## Root Cause
>
> This vulnerability is caused by treating a manipulated return value 
> from an LSM hook as complete success in `__sys_socket_create` without 
> ensuring that the underlying object has been fully initialized.
>
> 1. `__sys_socket_create()` in `net/socket.c` reserves a pointer 
> variable `struct socket *sock;` on the kernel stack without 
> zero-initializing it.
> 2. It calls `sock_create(family, type, protocol, &sock);` to allocate 
> and initialize the socket object.
> 3. `sock_create` proceeds to allocate the socket internally and 
> invokes the `security_socket_create` LSM hook (which triggers 
> `bpf_lsm_socket_create`).
> 4. If a BPF program is attached to the cgroup LSM hook for 
> `bpf_lsm_socket_create`, it can call `bpf_set_retval(1)` and return `1`.
> 5. Because the BPF hook completes without an error code (< 0), 
> `sock_create` interprets this bypass as success and promptly returns 
> `1` (or a positive bypass value) back to `__sys_socket_create()`. 
> However, the critical variable `sock` is never populated.
> 6. The caller `__sys_socket_create()` checks if `sock_create()`'s 
> return value is `< 0`. Since `1` is not less than `0`, it assumes the 
> `sock` pointer is valid.
> 7. Subsequent socket operations inside `__sys_socket_create()`, such 
> as `sock_map_fd(sock, ...)`, attempt to dereference the uninitialized 
> `sock` stack pointer.
>

A similar topic to the one you reported before [1], and it seems Feng is 
working on this [2].

[1] 
https://lore.kernel.org/bpf/973a1b7b-8ee7-407a-890a-11455d9cc5bf@std.uestc.edu.cn/

[2] 
https://lore.kernel.org/all/20260408094816.228322-1-yangfeng59949@163.com/


If you really want to panic the kernel, you can see that the following 
hooks probably cause this problem as well:

- security_task_alloc
- security_inode_readlink
- security_task_movememory
- security_inode_follow_link
- security_fs_context_submount
- security_dentry_create_files_as
- security_perf_event_alloc
- security_inode_get_acl