netdev - Re: [REGRESSION][BISECTED][PATCH] net: ipv4: fix regression in broadcast routes

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: <7090d5ae-c598-4db5-a051-b31720a27746@redhat.com>
Date: Thu, 28 Aug 2025 12:35:17 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: kernel test robot <oliver.sang@...el.com>,
 Brett A C Sheffield <bacs@...recast.net>
Cc: oe-lkp@...ts.linux.dev, lkp@...el.com, netdev@...r.kernel.org,
 regressions@...ts.linux.dev, stable@...r.kernel.org, davem@...emloft.net,
 dsahern@...nel.org, oscmaes92@...il.com, kuba@...nel.org
Subject: Re: [REGRESSION][BISECTED][PATCH] net: ipv4: fix regression in
 broadcast routes

On 8/28/25 10:17 AM, kernel test robot wrote:
> commit: a1b445e1dcd6ee9682d77347faf3545b53354d71 ("[REGRESSION][BISECTED][PATCH] net: ipv4: fix regression in broadcast routes")
> url: https://github.com/intel-lab-lkp/linux/commits/Brett-A-C-Sheffield/net-ipv4-fix-regression-in-broadcast-routes/20250825-181407
> patch link: https://lore.kernel.org/all/20250822165231.4353-4-bacs@librecast.net/
> patch subject: [REGRESSION][BISECTED][PATCH] net: ipv4: fix regression in broadcast routes
> 
> in testcase: trinity
> version: trinity-x86_64-ba2360ed-1_20241228
> with following parameters:
> 
> 	runtime: 300s
> 	group: group-04
> 	nr_groups: 5
> 
> 
> 
> config: x86_64-randconfig-104-20250826
> compiler: clang-20
> test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
> 
> (please refer to attached dmesg/kmsg for entire log/backtrace)

Since I just merged v3 of the mentioned patch and I'm wrapping the PR
for Linus, the above scared me more than a bit.

AFAICS the issue reported here is the  unconditional 'fi' dereference
spotted and fixed during code review, so no real problem after all.

/P