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 for Android: free password hash cracker in your pocket

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

Message-ID: <aLAzki2ObTlTfSZd@auntie>
Date: Thu, 28 Aug 2025 10:46:42 +0000
From: Brett A C Sheffield <bacs@...recast.net>
To: Paolo Abeni <pabeni@...hat.com>
Cc: kernel test robot <oliver.sang@...el.com>, 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 2025-08-28 12:35, Paolo Abeni wrote:
> 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.

Correct. Jakub spotted the error, it was fixed in a v2 5 days ago, and has since
been superceded by Oscar's patch, so nothing to worry about.

Is there a way to indicate to bots not to check superceded patches. In this case
I'd have though my v2 would have been a signal? Is there something else I should
have done?

Brett
--