linux-kernel - Re: [PATCH 06/21] can: netlink: add can_validate

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: <8009fd35-421b-4091-99a5-fda86e1cfaaa@kernel.org>
Date: Fri, 5 Sep 2025 23:55:26 +0900
From: Vincent Mailhol <mailhol@...nel.org>
To: kernel test robot <lkp@...el.com>, Marc Kleine-Budde
 <mkl@...gutronix.de>, Oliver Hartkopp <socketcan@...tkopp.net>
Cc: llvm@...ts.linux.dev, oe-kbuild-all@...ts.linux.dev,
 Stéphane Grosjean <stephane.grosjean@...-networks.com>,
 Robert Nawrath <mbro1689@...il.com>, Minh Le <minh.le.aj@...esas.com>,
 Duy Nguyen <duy.nguyen.rh@...esas.com>, linux-can@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 06/21] can: netlink: add can_validate_databittiming()

On 05/09/2025 at 03:46, kernel test robot wrote:
> Hi Vincent,
> 
> kernel test robot noticed the following build warnings:
> 
> [auto build test WARNING on 2fd4161d0d2547650d9559d57fc67b4e0a26a9e3]

OK. I will silence it in v2, but I don't think this is anyhow problematic.

> url:    https://github.com/intel-lab-lkp/linux/commits/Vincent-Mailhol/can-dev-move-struct-data_bittiming_params-to-linux-can-bittiming-h/20250903-170807
> base:   2fd4161d0d2547650d9559d57fc67b4e0a26a9e3
> patch link:    https://lore.kernel.org/r/20250903-canxl-netlink-prep-v1-6-904bd6037cd9%40kernel.org
> patch subject: [PATCH 06/21] can: netlink: add can_validate_databittiming()
> config: x86_64-kexec (https://download.01.org/0day-ci/archive/20250905/202509050259.NjPdQyAD-lkp@intel.com/config)
> compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250905/202509050259.NjPdQyAD-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@...el.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202509050259.NjPdQyAD-lkp@intel.com/
> 
> All warnings (new ones prefixed by >>):
> 
>>> drivers/net/can/dev/netlink.c:111:6: warning: variable 'is_on' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
>      111 |         if (ifla_can_data_bittiming == IFLA_CAN_DATA_BITTIMING) {
>          |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    drivers/net/can/dev/netlink.c:119:6: note: uninitialized use occurs here
>      119 |         if (is_on) {
>          |             ^~~~~
>    drivers/net/can/dev/netlink.c:111:2: note: remove the 'if' if its condition is always true

That's it. This if condition is always true at the moment because all the
callers specify ifla_can_data_bittiming as IFLA_CAN_DATA_BITTIMING. But I do not
want to remove the else branch because is serves to show to the reader what is
coming up next and help to understand the refactor logic.
>      111 |         if (ifla_can_data_bittiming == IFLA_CAN_DATA_BITTIMING) {
>          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>      112 |                 data_tdc = data[IFLA_CAN_TDC];
>      113 |                 tdc_flags = flags & CAN_CTRLMODE_FD_TDC_MASK;
>      114 |                 is_on = flags & CAN_CTRLMODE_FD;
>      115 |         } else {
>          |           ~~~~~~
>      116 |                 WARN_ON(1); /* Place holder for CAN XL */
>          |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The WARN_ON(1) was to point out that the else branch should never be reached.

I will change this to:

	return -EOPNOTSUPP; /* Place holder for CAN XL */

in v2. This will serve the same purpose as the current WARN_ON(1) but will
suppress the warning.

I will do the exact same on patches 11/21 and 18/21 on which the kernel test
robot also sent a similar report.


Yours sincerely,
Vincent Mailhol