Re: [PATCH 4.14 053/118] Revert "Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find.""

[Nicolas Dichtel]

Le 16/01/2018 Ã 07:33, Steffen Klassert a ÃcritÂ:
> On Mon, Jan 15, 2018 at 11:56:12AM -0500, David Miller wrote:
>> From: Steffen Klassert <steffen.klassert@xxxxxxxxxxx>
>> Date: Mon, 15 Jan 2018 14:23:29 +0100
>>
>>> On Mon, Jan 15, 2018 at 01:34:40PM +0100, Greg Kroah-Hartman wrote:
>>>> 4.14-stable review patch.  If anyone has any objections, please let me know.
>>>>
>>>> ------------------
>>>>
>>>> From: "David S. Miller" <davem@xxxxxxxxxxxxx>
>>>>
>>>>
>>>> This reverts commit 94802151894d482e82c324edf2c658f8e6b96508.
>>>>
>>>> It breaks transport mode when the policy template has
>>>> wildcard addresses configured.
>>>>
>>>> Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
>>>
>>> Hm, this seems to be one revert too much.
>>>
>>> commit 94802151894d482e82c324edf2c658f8e6b96508 reverted already
>>> the buggy commit. Reverting the revert will bring the bug back.
>>
>> Steffen, in the email where you asked me to revert that is the
>> commit ID you referenced.
> 
> I think there was a misunderstanding. I asked you to queue the
> commit with that ID to stable on Dec 23 (this commit ID is the
> revert of the buggy patch). This commit was included to stable
> on Jan 4 then:
> 
> https://www.spinics.net/lists/stable/msg208727.html
> 
> So with this, everything was ok.
> 
> Maybe you started to look again into this because Nicolas Dichtel
> (Cced) asked to queue this patch on Jan 5, the patch was already
> in the stable tree (Jan 4) but probably not in an actual release
> at this time.
Oh, I didn't find it at this time in the linux-stable tree nor in the stable
patchwork. Bad timing :/

I still don't find it in the patchwork:
http://patchwork.ozlabs.org/bundle/davem/stable/?series=&submitter=1442&state=*&q=&archive=both
Am I missing something?

> 
>>
>> We can drop this, but you need to then tell us whether 4.14 needs
>> the revert any longer and if so what the correct SHA ID would
>> be.
> 
> I think we can we can just drop this.
> 
> Unless Nicolas knows something that is still missing, v4.14.12 and
> above should be ok as is.
I agree, we can drop this.


Thank you,
Nicolas