Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: locks use-after-free stable request
To:     Greg KH <gregkh@linuxfoundation.org>
Cc:     stable <stable@vger.kernel.org>,
        Android Kernel Team <kernel-team@android.com>,
        LKML <linux-kernel@vger.kernel.org>
References: <52be02d3-3a6a-c8b8-4177-5cc1d67aedd4@android.com>
 <20200324144338.GA2507446@kroah.com>
From:   Mark Salyzyn <salyzyn@android.com>
Message-ID: <29c96b7a-5964-5d89-304a-92673b68e8ef@android.com>
Date:   Tue, 24 Mar 2020 07:53:52 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <20200324144338.GA2507446@kroah.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 3/24/20 7:43 AM, Greg KH wrote:
> On Tue, Mar 24, 2020 at 07:24:49AM -0700, Mark Salyzyn wrote:
>> Referencing upstream fixes commit dcf23ac3e846ca0cf626c155a0e3fcbbcf4fae8a
>> ("locks: reinstate locks_delete_block optimization") and commit
>> 6d390e4b5d48ec03bb87e63cf0a2bff5f4e116da ("locks: fix a potential
>> use-after-free problem when wakeup a waiter") and possibly address
>> CVE-2019-19769.
>>
>> Please apply to all relevant stable trees including 5.4, 4.19 and below.
>> Confirmed they apply cleanly to 5.4 and 4.19.
>>
>>
>> Signed-off-by: Mark Salyzyn <salyzyn@android.com>
>>
>> Cc: stable@vger.kernel.org
>>
>> Cc: linux-kernel@vger.kernel.org
>>
>> Cc: kernel-team@android.com
>>
> These are all queued up for the next round of 5.4 and 5.5 stable
> releases,but they do not seem to apply to 4.19.
>
> And why do you think they apply to 4.19, that's not what 6d390e4b5d48
> ("locks: fix a potential use-after-free problem when wakeup a waiter")
> says.

When I used my tool to apply the pair by sha, I failed to notice that 
they were _both_ skipped because they are _both_ already present and 
read that as clean without looking at _what_ got applied or not.

(I will be fixing my tool)

> confused,

<sorry>

>
> greg k-h