Re: [PATCH] can: af_can: reject can rx unregister if dev is not can

[Oliver Hartkopp]

On 26.05.26 01:46, Edward Adam Davis wrote:
> On Mon, 25 May 2026 20:15:21 +0200, Oliver Hartkopp 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+8ed98cbd0161632bce95@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > Closes: https://syzkaller.appspot.com/bug?extid=8ed98cbd0161632bce95
> > > Tested-by: syzbot+8ed98cbd0161632bce95@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > Signed-off-by: Edward Adam Davis <eadavis@xxxxxx>
> >
> > 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.
> 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.

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