netdev - Re: [PATCH net-next 6/7] can: add drop reasons in the receive path of AF

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: <20250610155039.64ccdbda@kernel.org>
Date: Tue, 10 Jun 2025 15:50:39 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Marc Kleine-Budde <mkl@...gutronix.de>
Cc: netdev@...r.kernel.org, davem@...emloft.net, linux-can@...r.kernel.org,
 kernel@...gutronix.de, Davide Caratti <dcaratti@...hat.com>
Subject: Re: [PATCH net-next 6/7] can: add drop reasons in the receive path
 of AF_CAN

On Tue, 10 Jun 2025 11:46:21 +0200 Marc Kleine-Budde wrote:
> Besides the existing pr_warn_once(), use skb drop reasons in case AF_CAN
> layer drops non-conformant CAN{,FD,XL} frames, or conformant frames
> received by "wrong" devices, so that it's possible to debug (and count)
> such events using existing tracepoints:

Hm, I wonder if the protocol is really the most useful way 
to categorize. Does it actually help to identify problems on
production systems?

AFAIU we try to categorize by drop condition. So given the condition
is:

	if (unlikely(dev->type != ARPHRD_CAN || !can_get_ml_priv(dev) || !can_is_canfd_skb(skb))) 

my intuition would be to split this into two: "not a CAN device" and
"invalid CAN frame". The latter not split by proto - user can dig into
the stack traces of the relevant drop for more details.

But drop reasons are not uAPI so we can re-align later.