[syzbot] [fs?] kernel BUG in sctp_getsockopt_peeloff_common

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 7d31f578f323 Add linux-next specific files for 20251128
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=156402b4580000
kernel config: https://syzkaller.appspot.com/x/.config?x=6336d8e94a7c517d
dashboard link: https://syzkaller.appspot.com/bug?extid=984a5c208d87765b2ee7
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16a2322c580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12a3c512580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/6b49d8ad90de/disk-7d31f578.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/dbe2d4988ca7/vmlinux-7d31f578.xz
kernel image: https://storage.googleapis.com/syzbot-assets/fc0448ab2411/bzImage-7d31f578.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+984a5c...@syzkaller.appspotmail.com

R10: 0000200000000340 R11: 0000000000000246 R12: 0000000000000002
R13: 00007f49009e5fa0 R14: 00007f49009e5fa0 R15: 0000000000000005
</TASK>
VFS_BUG_ON_INODE(inode_state_read_once(inode) & I_CLEAR) encountered for inode ffff88805d116e00
fs sockfs mode 140777 opflags 0xc flags 0x0 state 0x300 count 0
------------[ cut here ]------------
kernel BUG at fs/inode.c:1971!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 5997 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
RIP: 0010:iput+0xfc9/0x1030 fs/inode.c:1971
Code: 8b 7c 24 18 48 c7 c6 e0 f2 79 8b e8 51 f8 e6 fe 90 0f 0b e8 a9 6f 80 ff 48 8b 7c 24 18 48 c7 c6 80 f2 79 8b e8 38 f8 e6 fe 90 <0f> 0b 44 89 e9 80 e1 07 80 c1 03 38 c1 0f 8c cd fb ff ff 4c 89 ef
RSP: 0018:ffffc90003987b18 EFLAGS: 00010282
RAX: 000000000000009f RBX: dffffc0000000000 RCX: e99d72d115a78d00
RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
RBP: 1ffffffff1ed7c72 R08: ffffc900039877c7 R09: 1ffff92000730ef8
R10: dffffc0000000000 R11: fffff52000730ef9 R12: 1ffff1100ba22e00
R13: ffff88805d117000 R14: 0000000000000200 R15: 1ffffffff1f02c74
FS: 000055557d588500(0000) GS:ffff888125e4f000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000000200 CR3: 0000000074b6e000 CR4: 00000000003526f0
Call Trace:
<TASK>
sctp_getsockopt_peeloff_common+0x6b7/0x8a0 net/sctp/socket.c:5733
sctp_getsockopt_peeloff_flags+0x102/0x140 net/sctp/socket.c:5779
sctp_getsockopt+0x3a5/0xb90 net/sctp/socket.c:8111
do_sock_getsockopt+0x2b4/0x3d0 net/socket.c:2389
__sys_getsockopt net/socket.c:2418 [inline]
__do_sys_getsockopt net/socket.c:2425 [inline]
__se_sys_getsockopt net/socket.c:2422 [inline]
__x64_sys_getsockopt+0x1a5/0x250 net/socket.c:2422
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f490078f749
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffed38d1688 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
RAX: ffffffffffffffda RBX: 00007f49009e5fa0 RCX: 00007f490078f749
RDX: 000000000000007a RSI: 0000000000000084 RDI: 0000000000000003
RBP: 00007ffed38d16e0 R08: 0000200000000040 R09: 0000000000000000
R10: 0000200000000340 R11: 0000000000000246 R12: 0000000000000002
R13: 00007f49009e5fa0 R14: 00007f49009e5fa0 R15: 0000000000000005
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:iput+0xfc9/0x1030 fs/inode.c:1971
Code: 8b 7c 24 18 48 c7 c6 e0 f2 79 8b e8 51 f8 e6 fe 90 0f 0b e8 a9 6f 80 ff 48 8b 7c 24 18 48 c7 c6 80 f2 79 8b e8 38 f8 e6 fe 90 <0f> 0b 44 89 e9 80 e1 07 80 c1 03 38 c1 0f 8c cd fb ff ff 4c 89 ef
RSP: 0018:ffffc90003987b18 EFLAGS: 00010282
RAX: 000000000000009f RBX: dffffc0000000000 RCX: e99d72d115a78d00
RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
RBP: 1ffffffff1ed7c72 R08: ffffc900039877c7 R09: 1ffff92000730ef8
R10: dffffc0000000000 R11: fffff52000730ef9 R12: 1ffff1100ba22e00
R13: ffff88805d117000 R14: 0000000000000200 R15: 1ffffffff1f02c74
FS: 000055557d588500(0000) GS:ffff888125e4f000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000000200 CR3: 0000000074b6e000 CR4: 00000000003526f0


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[Mateusz Guzik]

The inode is I_FREEING | I_CLEAR.

I suspect this is botched error handling in the recent conversion to
FD_PREPARE machinery.

#syz test

diff --git b/net/sctp/socket.c a/net/sctp/socket.c
index 1e59ac734f91..ed8293a34240 100644
--- b/net/sctp/socket.c
+++ a/net/sctp/socket.c
@@ -5664,45 +5664,47 @@ static int sctp_do_peeloff(struct sock *sk, sctp_assoc_t id,
return err;
}

-static int sctp_getsockopt_peeloff_common(struct sock *sk,
- sctp_peeloff_arg_t *peeloff, int len,
- char __user *optval,
- int __user *optlen, unsigned flags)
+static int sctp_getsockopt_peeloff_common(struct sock *sk, sctp_peeloff_arg_t *peeloff,
+ struct file **newfile, unsigned flags)
{
struct socket *newsock;
int retval;

retval = sctp_do_peeloff(sk, peeloff->associd, &newsock);
if (retval < 0)
- return retval;
+ goto out;

- FD_PREPARE(fdf, flags & SOCK_CLOEXEC, sock_alloc_file(newsock, 0, NULL));
- if (fdf.err) {
+ /* Map the socket to an unused fd that can be returned to the user. */
+ retval = get_unused_fd_flags(flags & SOCK_CLOEXEC);
+ if (retval < 0) {
sock_release(newsock);
- return fdf.err;
+ goto out;
}

- pr_debug("%s: sk:%p, newsk:%p, sd:%d\n", __func__, sk, newsock->sk,
- fd_prepare_fd(fdf));
-
- if (flags & SOCK_NONBLOCK)
- fd_prepare_file(fdf)->f_flags |= O_NONBLOCK;
+ *newfile = sock_alloc_file(newsock, 0, NULL);
+ if (IS_ERR(*newfile)) {
+ put_unused_fd(retval);
+ retval = PTR_ERR(*newfile);
+ *newfile = NULL;
+ return retval;
+ }

- /* Return the fd mapped to the new socket. */
- if (put_user(len, optlen))
- return -EFAULT;
+ pr_debug("%s: sk:%p, newsk:%p, sd:%d\n", __func__, sk, newsock->sk,
+ retval);

- peeloff->sd = fd_prepare_fd(fdf);
- if (copy_to_user(optval, peeloff, len))
- return -EFAULT;
+ peeloff->sd = retval;

- return fd_publish(fdf);
+ if (flags & SOCK_NONBLOCK)
+ (*newfile)->f_flags |= O_NONBLOCK;
+out:
+ return retval;
}

-static int sctp_getsockopt_peeloff(struct sock *sk, int len,
- char __user *optval, int __user *optlen)
+static int sctp_getsockopt_peeloff(struct sock *sk, int len, char __user *optval, int __user *optlen)
{
sctp_peeloff_arg_t peeloff;
+ struct file *newfile = NULL;
+ int retval = 0;

if (len < sizeof(sctp_peeloff_arg_t))
return -EINVAL;
@@ -5710,13 +5712,33 @@ static int sctp_getsockopt_peeloff(struct sock *sk, int len,
if (copy_from_user(&peeloff, optval, len))
return -EFAULT;

- return sctp_getsockopt_peeloff_common(sk, &peeloff, len, optval, optlen, 0);
+ retval = sctp_getsockopt_peeloff_common(sk, &peeloff, &newfile, 0);
+ if (retval < 0)
+ goto out;
+
+ /* Return the fd mapped to the new socket. */
+ if (put_user(len, optlen)) {
+ fput(newfile);
+ put_unused_fd(retval);
+ return -EFAULT;
+ }
+
+ if (copy_to_user(optval, &peeloff, len)) {
+ fput(newfile);
+ put_unused_fd(retval);
+ return -EFAULT;
+ }
+ fd_install(retval, newfile);
+out:
+ return retval;
}

static int sctp_getsockopt_peeloff_flags(struct sock *sk, int len,
char __user *optval, int __user *optlen)
{
sctp_peeloff_flags_arg_t peeloff;
+ struct file *newfile = NULL;
+ int retval = 0;

if (len < sizeof(sctp_peeloff_flags_arg_t))
return -EINVAL;
@@ -5724,8 +5746,26 @@ static int sctp_getsockopt_peeloff_flags(struct sock *sk, int len,
if (copy_from_user(&peeloff, optval, len))
return -EFAULT;

- return sctp_getsockopt_peeloff_common(sk, &peeloff.p_arg, len, optval,
- optlen, peeloff.flags);
+ retval = sctp_getsockopt_peeloff_common(sk, &peeloff.p_arg,
+ &newfile, peeloff.flags);
+ if (retval < 0)
+ goto out;
+
+ /* Return the fd mapped to the new socket. */
+ if (put_user(len, optlen)) {
+ fput(newfile);
+ put_unused_fd(retval);
+ return -EFAULT;
+ }
+
+ if (copy_to_user(optval, &peeloff, len)) {
+ fput(newfile);
+ put_unused_fd(retval);
+ return -EFAULT;
+ }
+ fd_install(retval, newfile);
+out:
+ return retval;
}

/* 7.1.13 Peer Address Parameters (SCTP_PEER_ADDR_PARAMS)

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+984a5c...@syzkaller.appspotmail.com
Tested-by: syzbot+984a5c...@syzkaller.appspotmail.com

Tested on:

commit: 95cb2fd6 Add linux-next specific files for 20251201
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=142b58c2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=caadf525b0ab8d17

dashboard link: https://syzkaller.appspot.com/bug?extid=984a5c208d87765b2ee7
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8

patch: https://syzkaller.appspot.com/x/patch.diff?x=10a62512580000

Note: testing is done by a robot and is best-effort only.

[Al Viro]

On Mon, Dec 01, 2025 at 01:57:11PM +0100, Mateusz Guzik wrote:

> I suspect this is botched error handling in the recent conversion to
> FD_PREPARE machinery.

Quite. FWIW, at that point I believe that FD_ADD/FD_PREPARE branch
is simply not ready - too little time in -next, if nothing else.

Christian, drop that pull request, please.

[syzbot]

syzbot has bisected this issue to:

commit 457528eb27c3a3053181939ca65998477cc39c49
Author: Christian Brauner <bra...@kernel.org>
Date: Sun Nov 23 16:33:47 2025 +0000

net/sctp: convert sctp_getsockopt_peeloff_common() to FD_PREPARE()

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1136a512580000
start commit: 7d31f578f323 Add linux-next specific files for 20251128
git tree: linux-next
final oops: https://syzkaller.appspot.com/x/report.txt?x=1336a512580000
console output: https://syzkaller.appspot.com/x/log.txt?x=1536a512580000

kernel config: https://syzkaller.appspot.com/x/.config?x=6336d8e94a7c517d
dashboard link: https://syzkaller.appspot.com/bug?extid=984a5c208d87765b2ee7

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16a2322c580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12a3c512580000

Reported-by: syzbot+984a5c...@syzkaller.appspotmail.com
Fixes: 457528eb27c3 ("net/sctp: convert sctp_getsockopt_peeloff_common() to FD_PREPARE()")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

[Christian Brauner]

Fwiw, this conversion isn't in mainline. This is -next being out of
sync. Sorry I was too eager to push this. I just got excited about it.
I'm happy to send a revert in case Linus wants that.