netfilter/x_tables patches for v4.4.y..v4.14.y

netfilter/x_tables patches for v4.4.y..v4.14.y

[Guenter Roeck]

Hi Greg,

please consider applying the following two patches to v4.4.y, v4.9.y, and v4.14.y

80055dab5de0 ("netfilter: x_tables: make xt_replace_table wait until old rules are not used anymore")
175e476b8cdf ("netfilter: x_tables: Use correct memory barriers.")

to fix CVE-2021-29650 in those branches.

Thanks,
Guenter

Re: netfilter/x_tables patches for v4.4.y..v4.14.y

[Greg Kroah-Hartman]

On Thu, Apr 15, 2021 at 09:28:15AM -0700, Guenter Roeck wrote:
> Hi Greg,
> 
> please consider applying the following two patches to v4.4.y, v4.9.y, and v4.14.y
> 
> 80055dab5de0 ("netfilter: x_tables: make xt_replace_table wait until old rules are not used anymore")
> 175e476b8cdf ("netfilter: x_tables: Use correct memory barriers.")

The second patch here says that it's only needed to go back until:
	    Fixes: 7f5c6d4f665b ("netfilter: get rid of atomic ops in fast path")

Which is only backported to 4.19.  So why do older kernels need that, is
the fixes tag wrong?

thanks,

greg k-h

Re: netfilter/x_tables patches for v4.4.y..v4.14.y

[Guenter Roeck]

On Thu, Apr 15, 2021 at 06:37:41PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Apr 15, 2021 at 09:28:15AM -0700, Guenter Roeck wrote:
> > Hi Greg,
> > 
> > please consider applying the following two patches to v4.4.y, v4.9.y, and v4.14.y
> > 
> > 80055dab5de0 ("netfilter: x_tables: make xt_replace_table wait until old rules are not used anymore")
> > 175e476b8cdf ("netfilter: x_tables: Use correct memory barriers.")
> 
> The second patch here says that it's only needed to go back until:
> 	    Fixes: 7f5c6d4f665b ("netfilter: get rid of atomic ops in fast path")
> 
> Which is only backported to 4.19.  So why do older kernels need that, is
> the fixes tag wrong?
> 
Where do you get that from ? 7f5c6d4f665b is, from what I can see, in v3.0.

$ git describe 7f5c6d4f665b
v2.6.39-rc1-159-g7f5c6d4f665b
$ git log --oneline v2.6.39..v3.0 | grep "netfilter: get rid of atomic ops in fast path"
7f5c6d4f665b netfilter: get rid of atomic ops in fast path

Thanks,
Guenter

Re: netfilter/x_tables patches for v4.4.y..v4.14.y

[Guenter Roeck]

On Thu, Apr 15, 2021 at 06:37:41PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Apr 15, 2021 at 09:28:15AM -0700, Guenter Roeck wrote:
> > Hi Greg,
> > 
> > please consider applying the following two patches to v4.4.y, v4.9.y, and v4.14.y
> > 
> > 80055dab5de0 ("netfilter: x_tables: make xt_replace_table wait until old rules are not used anymore")
> > 175e476b8cdf ("netfilter: x_tables: Use correct memory barriers.")
> 
> The second patch here says that it's only needed to go back until:
> 	    Fixes: 7f5c6d4f665b ("netfilter: get rid of atomic ops in fast path")
> 
> Which is only backported to 4.19.  So why do older kernels need that, is
> the fixes tag wrong?
> 

Outch, it looks like 80055dab5de0 was fixed later with cc00bcaa5899, which in
turn was fixed with 443d6e86f821. Ok, back to the drawing board, but it may
just be easier to forget about this. I'll let you know.

Thanks,
Guenter

Re: netfilter/x_tables patches for v4.4.y..v4.14.y

[Guenter Roeck]

On Thu, Apr 15, 2021 at 10:49:50AM -0700, Guenter Roeck wrote:
> On Thu, Apr 15, 2021 at 06:37:41PM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Apr 15, 2021 at 09:28:15AM -0700, Guenter Roeck wrote:
> > > Hi Greg,
> > > 
> > > please consider applying the following two patches to v4.4.y, v4.9.y, and v4.14.y
> > > 
> > > 80055dab5de0 ("netfilter: x_tables: make xt_replace_table wait until old rules are not used anymore")
> > > 175e476b8cdf ("netfilter: x_tables: Use correct memory barriers.")
> > 
> > The second patch here says that it's only needed to go back until:
> > 	    Fixes: 7f5c6d4f665b ("netfilter: get rid of atomic ops in fast path")
> > 
> > Which is only backported to 4.19.  So why do older kernels need that, is
> > the fixes tag wrong?
> > 
> 
> Outch, it looks like 80055dab5de0 was fixed later with cc00bcaa5899, which in
> turn was fixed with 443d6e86f821. Ok, back to the drawing board, but it may
> just be easier to forget about this. I'll let you know.
> 
I tried to apply cc00bcaa5899 on top of the above, and got lots of conflicts.
Please ignore this request; it adds more risk than gain. Sorry for the noise.

Guenter

Re: netfilter/x_tables patches for v4.4.y..v4.14.y

[Greg Kroah-Hartman]

On Thu, Apr 15, 2021 at 10:41:46AM -0700, Guenter Roeck wrote:
> On Thu, Apr 15, 2021 at 06:37:41PM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Apr 15, 2021 at 09:28:15AM -0700, Guenter Roeck wrote:
> > > Hi Greg,
> > > 
> > > please consider applying the following two patches to v4.4.y, v4.9.y, and v4.14.y
> > > 
> > > 80055dab5de0 ("netfilter: x_tables: make xt_replace_table wait until old rules are not used anymore")
> > > 175e476b8cdf ("netfilter: x_tables: Use correct memory barriers.")
> > 
> > The second patch here says that it's only needed to go back until:
> > 	    Fixes: 7f5c6d4f665b ("netfilter: get rid of atomic ops in fast path")
> > 
> > Which is only backported to 4.19.  So why do older kernels need that, is
> > the fixes tag wrong?
> > 
> Where do you get that from ? 7f5c6d4f665b is, from what I can see, in v3.0.
> 
> $ git describe 7f5c6d4f665b
> v2.6.39-rc1-159-g7f5c6d4f665b
> $ git log --oneline v2.6.39..v3.0 | grep "netfilter: get rid of atomic ops in fast path"
> 7f5c6d4f665b netfilter: get rid of atomic ops in fast path

Ah, my tool that checks where a patch comes from doesn't look past 3.1
if it finds that it was mentioned in a released tree for various
reasons, but when I look at the full sha1, it finds it properly, my
fault...

thanks,

greg k-h

Re: netfilter/x_tables patches for v4.4.y..v4.14.y

[Greg Kroah-Hartman]

On Thu, Apr 15, 2021 at 10:54:17AM -0700, Guenter Roeck wrote:
> On Thu, Apr 15, 2021 at 10:49:50AM -0700, Guenter Roeck wrote:
> > On Thu, Apr 15, 2021 at 06:37:41PM +0200, Greg Kroah-Hartman wrote:
> > > On Thu, Apr 15, 2021 at 09:28:15AM -0700, Guenter Roeck wrote:
> > > > Hi Greg,
> > > > 
> > > > please consider applying the following two patches to v4.4.y, v4.9.y, and v4.14.y
> > > > 
> > > > 80055dab5de0 ("netfilter: x_tables: make xt_replace_table wait until old rules are not used anymore")
> > > > 175e476b8cdf ("netfilter: x_tables: Use correct memory barriers.")
> > > 
> > > The second patch here says that it's only needed to go back until:
> > > 	    Fixes: 7f5c6d4f665b ("netfilter: get rid of atomic ops in fast path")
> > > 
> > > Which is only backported to 4.19.  So why do older kernels need that, is
> > > the fixes tag wrong?
> > > 
> > 
> > Outch, it looks like 80055dab5de0 was fixed later with cc00bcaa5899, which in
> > turn was fixed with 443d6e86f821. Ok, back to the drawing board, but it may
> > just be easier to forget about this. I'll let you know.
> > 
> I tried to apply cc00bcaa5899 on top of the above, and got lots of conflicts.
> Please ignore this request; it adds more risk than gain. Sorry for the noise.

No worries, now ignored :)

Re: netfilter/x_tables patches for v4.4.y..v4.14.y

[Guenter Roeck]

On 4/15/21 10:21 PM, Greg Kroah-Hartman wrote:
> On Thu, Apr 15, 2021 at 10:41:46AM -0700, Guenter Roeck wrote:
>> On Thu, Apr 15, 2021 at 06:37:41PM +0200, Greg Kroah-Hartman wrote:
>>> On Thu, Apr 15, 2021 at 09:28:15AM -0700, Guenter Roeck wrote:
>>>> Hi Greg,
>>>>
>>>> please consider applying the following two patches to v4.4.y, v4.9.y, and v4.14.y
>>>>
>>>> 80055dab5de0 ("netfilter: x_tables: make xt_replace_table wait until old rules are not used anymore")
>>>> 175e476b8cdf ("netfilter: x_tables: Use correct memory barriers.")
>>>
>>> The second patch here says that it's only needed to go back until:
>>> 	    Fixes: 7f5c6d4f665b ("netfilter: get rid of atomic ops in fast path")
>>>
>>> Which is only backported to 4.19.  So why do older kernels need that, is
>>> the fixes tag wrong?
>>>
>> Where do you get that from ? 7f5c6d4f665b is, from what I can see, in v3.0.
>>
>> $ git describe 7f5c6d4f665b
>> v2.6.39-rc1-159-g7f5c6d4f665b
>> $ git log --oneline v2.6.39..v3.0 | grep "netfilter: get rid of atomic ops in fast path"
>> 7f5c6d4f665b netfilter: get rid of atomic ops in fast path
> 
> Ah, my tool that checks where a patch comes from doesn't look past 3.1
> if it finds that it was mentioned in a released tree for various
> reasons, but when I look at the full sha1, it finds it properly, my
> fault...
> 

Yes, but still please don't apply anything. As mentioned in the other patch,
80055dab5de0 was fixed twice subsequently, and those fixes don't apply cleanly.
Better leave this alone.

Thanks,
Guenter