Re: [PATCH net v2] can: isotp: check register_netdevice_notifier() error in module init
[email protected] Wed, 29 Jul 2026 09:13:46 +0000
| Newsgroups | org.kernel.vger.linux-can |
|---|---|
| Message-ID | <[email protected]> |
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: Pre-existing issues: - [High] Missing error checks for can_rx_register() in isotp_bind(). -- --- Patch [1]: [PATCH net v2] can: isotp: check register_netdevice_notifier() error in module init --- commit 059042597b87e317cf8905dce3a8140167d9528a Author: Minhong He <[email protected]> can: isotp: check register_netdevice_notifier() error in module init This commit registers the netdevice notifier before calling can_proto_register() and checks its return value. If the protocol registration fails, it properly unregisters the notifier before returning the error. > diff --git a/net/can/isotp.c b/net/can/isotp.c > index 54becaf6898f1..ae6260e98a7a6 100644 > --- a/net/can/isotp.c > +++ b/net/can/isotp.c [ ... ] This is a pre-existing issue, but I noticed a potential problem in isotp_bind() when reviewing this file: net/can/isotp.c:isotp_bind() { ... if (isotp_register_rxid(so)) can_rx_register(net, dev, rx_id, SINGLE_MASK(rx_id), isotp_rcv, sk, "isotp", sk); /* no consecutive frame echo skb in flight */ so->cfecho = 0; /* register for echo skb's */ can_rx_register(net, dev, tx_id, SINGLE_MASK(tx_id), isotp_rcv_echo, sk, "isotpe", sk); /* switch to new settings */ so->ifindex = ifindex; ... } [Severity: High] Does this code silently ignore the return values of can_rx_register()? If an unprivileged user inside a container calls bind() under memory pressure, can_rx_register() could fail and return -ENOMEM. Because the error is not handled, the socket would proceed to be marked as bound. Later during close, isotp_release() calls can_rx_unregister() unconditionally. Since the receiver was never successfully registered, this would trigger the pr_warn("can: receive list entry not found...") inside af_can.c. Could a user repeatedly trigger this to generate unbounded kernel log spam, creating a denial of service vector? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1