On 25/09/2025 at 00:13, Marc Kleine-Budde wrote:

On 24.09.2025 23:35:44, Vincent Mailhol wrote:

quoted

Under normal usage, the virtual interfaces do not call can_setup(),
unless if trigger by a call to can_link_ops->setup().

Patch [1] did not consider this scenario resulting in an out of bound
read in can_setup() when calling can_link_ops->setup() as reported by
syzbot ci in [2].

Replacing netdev_priv() by safe_candev_priv() may look like a
potential solution at first glance but is not: can_setup() is used as
a callback function in alloc_netdev_mqs(). At the moment this callback
is called, priv is not yet fully setup and thus, safe_candev_priv()
would fail on physical interfaces. In other words, safe_candev_priv()
is solving the problem for virtual interfaces, but adding another
issue for physical interfaces.

Remove the call to can_set_default_mtu() in can_setup(). Instead,
manually set the MTU the default CAN MTU. This decorrelates the two
functions, effectively removing the conflict.

[1] can: populate the minimum and maximum MTU values
Link: https://lore.kernel.org/linux-can/20250923-can-fix-mtu-v3-3-581bde113f52@kernel.org/ (local)

[2] https://lore.kernel.org/linux-can/68d3e6ce.a70a0220.4f78.0028.GAE@google.com/ (local)

Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
---
@Marc, please squash in

  [PATCH net-next 27/48] can: populate the minimum and maximum MTU values

I've not changed the commit message of "can: populate the minimum and
maximum MTU values", just added the note that I've squashed this fixup
patch.

Ack. That was my intent as well. The description remains accurate. I just wrote
the patch description to keep a record of that last minute change ;)

I saw that you just added a link to the fix at the bottom, this is all we need!

I've created a new tag: linux-can-next-for-6.18-20250924

Thanks!


Yours sincerely,
Vincent Mailhol