bpf_token_create() assigns bpf_token_fops to the inode, but initializes private_data only on the original token file. Reopening the token through /proc/self/fd/N creates another file with the same operations and NULL private_data. Reading its fdinfo or using it as a BPF token can dereference the NULL pointer. Keep the inode's default file operations so fresh opens fail with -ENXIO. The original token file continues to use bpf_token_fops, while duplicated and transferred token descriptors remain valid. Reproduced on x86-64 using virtme-ng. The fresh open succeeded before the change and returned -ENXIO afterward. Also tested all three ordinary open modes, O_PATH, dup(), SCM_RIGHTS and token FD lifetime. Fixes: 35f96de04127 ("bpf: Introduce BPF token object") Signed-off-by: Avi Weiss --- kernel/bpf/token.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/bpf/token.c b/kernel/bpf/token.c index aa42243af16b..df4962a40e4a 100644 --- a/kernel/bpf/token.c +++ b/kernel/bpf/token.c @@ -163,7 +163,6 @@ int bpf_token_create(union bpf_attr *attr) return PTR_ERR(inode); inode->i_op = &bpf_token_iops; - inode->i_fop = &bpf_token_fops; clear_nlink(inode); /* make sure it is unlinked */ FD_PREPARE(fdf, O_CLOEXEC, base-commit: 4b4eb7f44ee05754339d07e9df649809f45d14c5 -- 2.53.0