Re: [RFC PATCH] can: dev: can_dev_dropped_skb: drop CAN FD skbs if FD is off

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 08.09.25 06:07, Vincent Mailhol wrote:
> On 08/09/2025 at 04:03, Oliver Hartkopp wrote:
>> Hi Vincent,
>>
>> can_dev_dropped_skb() is not what you are looking for.
>>
>> Whether a CAN frame fits to the CAN device is checked in raw_check_txframe() here:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/can/
>> raw.c#n884
>>
>> Or do I miss anything?
> 
> My point is not if it fits or not. Of course, if CAN XL is activated, CAN FD
> frames would fit.
> 
> My point is that activating CAN XL should not imply that CAN FD is also
> activated. Having CAN FD off and CAN XL on is a valid configuration.
> 
> Let me take an example, imagine that I configure my device with CAN FD off and
> CAN XL on, for example:
> 
>    ip link set can0 up type can bitrate 500000 \
>       fd off \
>       xl on xbitrate 10000000 tms on
> 

Ah, ok.

> Where is the check that, with this configuration, the device is not CAN FD
> capable and that the FD frames should be dropped? When I try this under my dummy
> driver, the FD frames pass the raw_check_txframe() check, reach the driver's
> xmit function and pass the can_dev_dropped_skb() checks. And that is the problem.
> 
> So, yes, the frame "fits" in above configuration and no buffer overflows nor any
> other security problems occurred. But CAN FD is off so the frame should have
> been discarded at some point.

Yes. I think your original patch with

 > +	if (!(priv->ctrlmode & CAN_CTRLMODE_FD) && can_is_canfd_skb(skb))
 > +		goto invalid_skb;

should do that job. Btw. I would also add a netdev_info_once() here too, 
so that we can give a heads up to the user.

> The same issue goes for probing. How do you detect if an interface is CAN FD
> capable? By checking that its MTU is at least CANFD_MTU? For example like this
> in cangen?
> 
>    https://github.com/linux-can/can-utils/blob/master/cangen.c#L802-L805
> 
> If I do this check, it would wrongly detect that my interface is CAN FD capable
> when in fact, it is turned off in the configuration. So, under my previous
> example, cangen is also fooled into believing that it can send CAN FD frames
> when in reality the option is turned off.
> 
> So, these are my point:
> 
>    - how do you configure a vcan so that CAN FD is off and CAN XL is on?

This is not possible due to the missing flags (netlink) infrastructure 
known from the real hardware drivers. And IMHO this is also not needed 
to be implemented for a virtual CAN interface which does not have those 
restrictions.

>    - when CAN FD is off and CAN XL is on, how do you drop CAN FD frames in the
>      kernel TX path ?

As you proposed in your extension for can_dev_dropped_skb() - with some 
more comments and a netdev_info_once(), of course ;-)

We might also try to access the CAN flags from the device in the network 
layer but this will become very ugly for a comparably unimportant 
use-case IMO. And it won't help for PF_PACKET users creating their own 
SKB content either.

>    - in the userland, how do you probe that an interface is CAN FD capable or
>      not?

Test ifr.ifr_mtu for

== CAN_MTU -> CC IF -> CAN CC
== CANFD_MTU -> FD IF -> CAN CC & CAN FD
 >= CANXL_MIN_MTU -> XL IF -> CAN CC & CAN FD & CAN XL

There is no way to have CAN CC with CAN XL without CAN FD right now as 
we can not detect this without accessing the netlink configuration.

Best regards,
Oliver