netdev - Re: [stable 2.6.32.y PATCH 0/6] net: fixes for cached dsts are never invalidated

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: <20121019194822.GF17417@1wt.eu>
Date:	Fri, 19 Oct 2012 21:48:22 +0200
From:	Willy Tarreau <w@....eu>
To:	Benjamin LaHaise <bcrl@...ck.org>
Cc:	David Miller <davem@...emloft.net>, stable@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [stable 2.6.32.y PATCH 0/6] net: fixes for cached dsts are never invalidated

Hi Ben,

On Fri, Oct 19, 2012 at 03:13:48PM -0400, Benjamin LaHaise wrote:
> This is v2 of an attempt to pull in the relevant fixes for a problem in
> v2.6.32 kernels where invalid cached routes are retained even after changes
> to the routing table have been made.  A simple test case can be found at 
> http://marc.info/?l=linux-netdev&m=135015076708950&w=2 .  Based on feedback 
> from David Miller, additional changes have been pulled in, including fixes
> for the same issue in IPv6.  Most of the patches required some rework owing
> to the large differences in the networking stack between 2.6.32 and 3.6.
> 
> I have performed basic tests to confirm that the cases I was hitting are
> now fixed, including a couple of tests with IPv4 and IPv6.  Comments?  
> Thanks again to David for the pointers to the additional fixes required in
> this area.

Looks like you've done an amazing work. I'm not the best person to judge
if these changes are valid or not, so I'll trust you and David on this.

I just have two questions: since you had to backport them from 3.6 to 2.6.32,
I'm assuming that the equivalent was not ready in closer LTS kernels (2.6.34,
3.0, 3.2, 3.4). Does this mean they're affected by the same issue too or are
they immune ? And if they're affected, are you going to proceed with forward
porting of your work for the closest ones (.34 and 3.0 come to mind) ? And if
they aren't affected, do you think that picking some changes there would have
been easier ?

As you probably know, we want to ensure that people who upgrade from an old
LTS to a newer one won't experience regressions due to problems which were
fixed only in the older version.

Thanks !
Willy

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html