linux-kernel - Re: [PATCH] can: dev: alloc_candev_mqs(): add missing default CAN capabilitied

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fc7ea750-78bf-42a6-ba3e-4db53a24ca25@hartkopp.net>
Date: Fri, 16 Jan 2026 14:10:44 +0100
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Marc Kleine-Budde <mkl@...gutronix.de>,
 Vincent Mailhol <mailhol@...nel.org>
Cc: linux-can@...r.kernel.org, linux-kernel@...r.kernel.org,
 kernel@...gutronix.de
Subject: Re: [PATCH] can: dev: alloc_candev_mqs(): add missing default CAN
 capabilitied



On 16.01.26 13:44, Marc Kleine-Budde wrote:
> The idea behind series 6c1f5146b214 ("Merge patch series "can: raw: better
> approach to instantly reject unsupported CAN frames"") is to set the
> capabilities of a CAN device (CAN-CC, CAN-FD, CAN-XL, and listen only) [1]
> and, based on these capabilities, reject unsupported CAN frames in the
> CAN-RAW protocol [2].
> 
> This works perfectly for CAN devices configured in CAN-FD or CAN-XL mode.
> CAN devices with static CAN control modes define their capabilities via
> can_set_static_ctrlmode() -> can_set_cap_info(). CAN devices configured by
> the user space for CAN-FD or CAN-XL set their capabilities via
> can_changelink() -> can_ctrlmode_changelink() -> can_set_cap_info().
> 
> However, in commit 166e87329ce6 ("can: propagate CAN device capabilities
> via ml_priv"), the capabilities of CAN devices are not initialized.
> This results in CAN-RAW rejecting all CAN frames on devices directly
> after ifup if the user space has not changed the CAN control mode.

Ah! It's about setting the bitrate without changing the control mode.

Sorry. I tested multiple configurations several times but missed the 
most simple one as initial test :-/

Acked-by: Oliver Hartkopp <socketcan@...tkopp.net>

Best regards,
Oliver

> 
> Fix this problem by setting the default capabilities to CAN-CC in
> alloc_candev_mqs() as soon as the CAN specific ml_priv is allocated.
> 
> [1] commit 166e87329ce6 ("can: propagate CAN device capabilities via ml_priv")
> [2] commit faba5860fcf9 ("can: raw: instantly reject disabled CAN frames")
> 
> Fixes: 166e87329ce6 ("can: propagate CAN device capabilities via ml_priv")
> Signed-off-by: Marc Kleine-Budde <mkl@...gutronix.de>
> ---
>   drivers/net/can/dev/dev.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/can/dev/dev.c b/drivers/net/can/dev/dev.c
> index 7ab9578f5b89..769745e22a3c 100644
> --- a/drivers/net/can/dev/dev.c
> +++ b/drivers/net/can/dev/dev.c
> @@ -332,6 +332,7 @@ struct net_device *alloc_candev_mqs(int sizeof_priv, unsigned int echo_skb_max,
>   
>   	can_ml = (void *)priv + ALIGN(sizeof_priv, NETDEV_ALIGN);
>   	can_set_ml_priv(dev, can_ml);
> +	can_set_cap(dev, CAN_CAP_CC);
>   
>   	if (echo_skb_max) {
>   		priv->echo_skb_max = echo_skb_max;
> 
> ---
> base-commit: a74c7a58ca2ca1cbb93f4c01421cf24b8642b962
> change-id: 20260116-can_add_missing_set_caps-388627edda13
> 
> Best regards,
> --
> Marc Kleine-Budde <mkl@...gutronix.de>
>