[syzbot] [can?] general protection fault in can_rx_unregister (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 4b4362973b6f Merge branch 'for-next/core' into for-kernelci
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=15e86d96580000
kernel config: https://syzkaller.appspot.com/x/.config?x=a834c6344141a58b
dashboard link: https://syzkaller.appspot.com/bug?extid=8ed98cbd0161632bce95
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
userspace arch: arm64
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=111f147e580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17942ac8580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/f69f86c90ee5/disk-4b436297.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/79fa7b33aaab/vmlinux-4b436297.xz
kernel image: https://storage.googleapis.com/syzbot-assets/ef080156d0de/Image-4b436297.gz.xz

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

bond1: (slave vxcan3): Setting fail_over_mac to active for active-backup mode
bond1: (slave vxcan3): making interface the new active one
bond1: (slave vxcan3): Enslaving as an active interface with an up link
Unable to handle kernel paging request at virtual address dfff800000000005
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
Mem abort info:
ESR = 0x0000000096000005
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x05: level 1 translation fault
Data abort info:
ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[dfff800000000005] address between user and kernel address ranges
Internal error: Oops: 0000000096000005 [#1] SMP
Modules linked in:
CPU: 0 UID: 0 PID: 4947 Comm: syz.0.86 Not tainted syzkaller #0 PREEMPT
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : can_rx_unregister+0x124/0x560 net/can/af_can.c:537
lr : can_rx_unregister+0x11c/0x560 net/can/af_can.c:531
sp : ffff800096267a40
x29: ffff800096267a60 x28: dfff800000000000 x27: ffff700012c4cf5c
x26: ffff0000d755ae48 x25: ffff0000c5c9ec00 x24: 0000000000000000
x23: ffff80008597d660 x22: ffff0000d9aa8000 x21: ffff0000cc740000
x20: 0000000000000028 x19: ffff0000cc740108 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 00000000ffff8000 x13: 0000000000000001 x12: 0000000000000004
x11: ffff700012c4cf30 x10: 0000000000ff0100 x9 : 0000000000000201
x8 : 0000000000000005 x7 : ffff80008594bef0 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffff80008594ba58
x2 : 0000000000000001 x1 : ffff0000d5110000 x0 : 0000000000000028
Call trace:
can_rx_unregister+0x124/0x560 net/can/af_can.c:531 (P)
isotp_release+0x500/0x9d8 net/can/isotp.c:1232
__sock_release+0xa0/0x1d4 net/socket.c:722
sock_close+0x24/0x38 net/socket.c:1514
__fput+0x340/0x744 fs/file_table.c:510
____fput+0x20/0x30 fs/file_table.c:538
task_work_run+0x1c4/0x254 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:67 [inline]
exit_to_user_mode_loop+0x10c/0x17c kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:230 [inline]
arm64_syscall_exit_to_user_mode arch/arm64/kernel/entry-common.c:88 [inline]
el0_svc+0x18c/0x260 arch/arm64/kernel/entry-common.c:741
el0t_64_sync_handler+0x48/0x148 arch/arm64/kernel/entry-common.c:759
el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:594
Code: aa1803e2 97ffff00 d343fc08 aa0003f4 (387c6908)
---[ end trace 0000000000000000 ]---
----------------
Code disassembly (best guess):
0: aa1803e2 mov x2, x24
4: 97ffff00 bl 0xfffffffffffffc04
8: d343fc08 lsr x8, x0, #3
c: aa0003f4 mov x20, x0
* 10: 387c6908 ldrb w8, [x8, x28] <-- trapping instruction


---
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

[Edward Adam Davis]

#syz test

diff --git a/net/can/af_can.c b/net/can/af_can.c
index 7bc86b176b4d..c9a79e087ed3 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -528,6 +528,8 @@ void can_rx_unregister(struct net *net, struct net_device *dev, canid_t can_id,
spin_lock_bh(&net->can.rcvlists_lock);

dev_rcv_lists = can_dev_rcv_lists_find(net, dev);
+ if (!dev_rcv_lists)
+ goto out;
rcv_list = can_rcv_list_find(&can_id, &mask, dev_rcv_lists);

/* Search the receiver list for the item to delete. This should

[syzbot]

Hello,

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

Reported-by: syzbot+8ed98c...@syzkaller.appspotmail.com
Tested-by: syzbot+8ed98c...@syzkaller.appspotmail.com

Tested on:

commit: 4b436297 Merge branch 'for-next/core' into for-kernelci

git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci

console output: https://syzkaller.appspot.com/x/log.txt?x=1657155e580000

kernel config: https://syzkaller.appspot.com/x/.config?x=a834c6344141a58b
dashboard link: https://syzkaller.appspot.com/bug?extid=8ed98cbd0161632bce95
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
userspace arch: arm64

patch: https://syzkaller.appspot.com/x/patch.diff?x=11d2047a580000

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

[Edward Adam Davis]

#syz test

diff --git a/net/can/af_can.c b/net/can/af_can.c

index 7bc86b176b4d..72831b4e0776 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -519,7 +519,7 @@ void can_rx_unregister(struct net *net, struct net_device *dev, canid_t can_id,
struct can_rcv_lists_stats *rcv_lists_stats = net->can.rcv_lists_stats;
struct can_dev_rcv_lists *dev_rcv_lists;

- if (dev && dev->type != ARPHRD_CAN)
+ if (dev && (dev->type != ARPHRD_CAN || !can_get_ml_priv(dev)))
return;

if (dev && !net_eq(net, dev_net(dev)))

[syzbot]

Hello,

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

Reported-by: syzbot+8ed98c...@syzkaller.appspotmail.com
Tested-by: syzbot+8ed98c...@syzkaller.appspotmail.com

Tested on:

commit: 4b436297 Merge branch 'for-next/core' into for-kernelci
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci

console output: https://syzkaller.appspot.com/x/log.txt?x=13b0c62e580000

kernel config: https://syzkaller.appspot.com/x/.config?x=a834c6344141a58b
dashboard link: https://syzkaller.appspot.com/bug?extid=8ed98cbd0161632bce95
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
userspace arch: arm64

patch: https://syzkaller.appspot.com/x/patch.diff?x=1474b61f980000

[Edward Adam Davis]

When a user binds a non-CAN device to a socket, the vulnerability reported
in [1] is triggered during the socket's closure and release phase, due to
the inability to find the expected receive list.

Added checks for Mid-layer private and type during the rx unregistration
process.

[1]

KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]

pc : can_rx_unregister+0x124/0x560 net/can/af_can.c:537

Call trace:
can_rx_unregister+0x124/0x560 net/can/af_can.c:531 (P)
isotp_release+0x500/0x9d8 net/can/isotp.c:1232
__sock_release+0xa0/0x1d4 net/socket.c:722
sock_close+0x24/0x38 net/socket.c:1514

Fixes: bdfb5765e45b ("can: af_can: remove NULL-ptr checks from users of can_dev_rcv_lists_find()")
Reported-by: syzbot+8ed98c...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=8ed98cbd0161632bce95
Tested-by: syzbot+8ed98c...@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <ead...@qq.com>
---
net/can/af_can.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--
2.43.0

[Oliver Hartkopp]

On 25.05.26 15:56, Edward Adam Davis wrote:
> When a user binds a non-CAN device to a socket, the vulnerability reported
> in [1] is triggered during the socket's closure and release phase, due to
> the inability to find the expected receive list.
>
> Added checks for Mid-layer private and type during the rx unregistration
> process.
>
> [1]
> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
> pc : can_rx_unregister+0x124/0x560 net/can/af_can.c:537
> Call trace:
> can_rx_unregister+0x124/0x560 net/can/af_can.c:531 (P)
> isotp_release+0x500/0x9d8 net/can/isotp.c:1232
> __sock_release+0xa0/0x1d4 net/socket.c:722
> sock_close+0x24/0x38 net/socket.c:1514
>
> Fixes: bdfb5765e45b ("can: af_can: remove NULL-ptr checks from users of can_dev_rcv_lists_find()")
> Reported-by: syzbot+8ed98c...@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=8ed98cbd0161632bce95
> Tested-by: syzbot+8ed98c...@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <ead...@qq.com>

Hello Edward,

many thanks for your investigation an effort to address the syzcaller issue!

Btw. the root cause of the problem, that the receive lists can not be
accessed is the bonding process that the bonding driver mutates
and modifies the network device states to fit an Ethernet-like
aggregation model. Which destroys the can_ml_priv.

When CAN netdevices are left alone the can_ml_priv data is always valid
and therefore does not need to be checked. Additionally this bonding
process and your fix will lead to memleaks of CAN filter data.

Syzcaller can continue its work to test the CAN API also without bonding.

So it seems to be the better solution to reject CAN interfaces to be
bonded. See my patch here:

https://lore.kernel.org/linux-can/20260525175639.1...@hartkopp.net/T/#u

I intentionally missed to add the bonding maintainers - and I'm not yet
clear what Fixes: tag would be appropriate. Does it fix the

commit ccb29637991f [CAN]: Add virtual CAN netdevice driver

??

What do you think?

Best regards,
Oliver

[Edward Adam Davis]

I noticed the "bonding" aspect, but I haven't yet delved deeply into
understanding why a vxcan interface cannot be enslaved to a bonding
net dev. After testing your patch, I observed that sockets previously
bound to the bonding net dev are no longer bound to that bonding net dev.

BR,
Edward

[Oliver Hartkopp]

I don't understand this last sentence.

With my patch the CAN interfaces can not be enslaved anymore.
As Syzbot is simply doing whatever is possible, it get's an error and
this error path is closed. Of course Syzbot can still test AF_CAN sockets.

Regarding your observation the I assume that the bonding driver makes an
interface down/up cycle or something similar which might have such an
effect.

But in the end it doesn't crash anymore when the bonding driver is
trying to fiddle with CAN interfaces.

Best regards,
Oliver