linux-kernel - Re: Determining corresponding mainline patch for stable patches Re: [PATCH 5.10 125/135] drm/i915: avoid uninitialised var in eb

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]

Date:   Thu, 19 Aug 2021 10:52:14 +0200
From:   Willy Tarreau <w@....eu>
To:     Pavel Machek <pavel@...x.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Theodore Ts'o" <tytso@....edu>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, jason@...kstrand.net,
        Jonathan Gray <jsg@....id.au>
Subject: Re: Determining corresponding mainline patch for stable patches Re:
 [PATCH 5.10 125/135] drm/i915: avoid uninitialised var in eb_parse()

Hi Pavel,

On Thu, Aug 19, 2021 at 10:22:42AM +0200, Pavel Machek wrote:
> I agree that submitters would need to know about the tag; OTOH I
> believe that if it looked like a tag, people would be more likely to
> get it right. We moved from "mention what this fixes in body" to
> "Fixes: " and I believe that was an improvement.
> 
> Anyway, three new entries in stable queues have format I have not seen
> before:
> 
> |ec547f971 None .: 4.19| KVM: nSVM: always intercept VMLOAD/VMSAVE when nested (CVE-2021-3656)
> |dbfcc0f75 None o: 4.19| KVM: nSVM: avoid picking up unsupported bits from L2 in int_ctl (CVE-2021-3653)
> |b79b08940 None o: 4.4| KVM: nSVM: avoid picking up unsupported bits from L2 in int_ctl (CVE-2021-3653)

I can't find these commits.

> [ upstream commit 0f923e07124df069ba68d8bb12324398f4b6b709 ]

I've seen them a few times, mostly in the bpf subsystem or in net
components whose backports were provided later by the original
patch authors (or users) trying to use the same format and using
a different case on "upstream".

> I guess I'll simply update the script.

That's clearly how it ought to be done. Again, I don't remember having
faced issues during 2.6.32/3.10 in the past using the trivial script I
shared and which used to ignore the case, so I don't see any particular
difficulty there :-/

Cheers,
Willy