netdev - Re: [PATCH net-next 16/27] can: raw: instantly reject unsupported CAN frames

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] [day] [month] [year] [list]

Message-ID: <68694081-b2db-42e3-8ff8-cb44a65492a5@hartkopp.net>
Date: Thu, 27 Nov 2025 21:15:25 +0100
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Vincent Mailhol <mailhol@...nel.org>,
 Marc Kleine-Budde <mkl@...gutronix.de>
Cc: netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
 linux-can@...r.kernel.org, kernel@...gutronix.de
Subject: Re: [PATCH net-next 16/27] can: raw: instantly reject unsupported CAN
 frames

Hello Vincent,

On 27.11.25 20:49, Vincent Mailhol wrote:
> On Wed. 26 Nov. 2025 at 13:01, Marc Kleine-Budde <mkl@...gutronix.de> wrote:
>> From: Oliver Hartkopp <socketcan@...tkopp.net>

>> +static unsigned int raw_check_txframe(struct raw_sock *ro, struct sk_buff *skb,
>> +                                     struct net_device *dev)
>> +{
>> +       struct can_priv *priv = safe_candev_priv(dev);
> 
> Sorry for coming back to you too late after the series is already
> merged in net-next.
> 
> This dependency on safe_candev_priv() can break the kernel build.
> Indeed, when building the kernel with:
> 
>    CONFIG_CAN_RAW=y
> 
> and with CONFIG_CAN_DEV not set (or built as module) below build error occurs:
> 
>    ld: vmlinux.o: in function `raw_sendmsg':
>    raw.c:(.text+0x101ac4b): undefined reference to `safe_candev_priv'
> 
> This is because, under the current design, the CAN network layer is
> not supposed to depend on the CAN devices layer.
> 
> I do not have a fix for this, nor do I have time to work on such a
> fix. All I can do for the moment is escalate the issue (but it is just
> a matter of time before some build bot from linux-next would report
> the same issue).

Good point.

Indeed I always tried to decouple the layers as good as possible.
But with the new CAN XL features the MTU checks came to an end.
At least the virtual CAN is always selected by every distribution when 
CONFIG_CAN is enabled.

Although it is not a real-world problem, I'll post a patch for it.

Many thanks,
Oliver