Re: List linux CVEs for a given stable release?

                Greg Kroah-Hartman wrote on Wed, May 29, 2024 at 09:23:50PM +0200:

(pedantic: `if cve=$(cve_search "$id"); then` is a bit simpler/failproof)

That's roughly what I had done earlier this week (handpicking the
commits that could impact our users), but this doesn't address my second
point as it won't catch any new CVE introduced before that tree that
wasn't fixed.
(also probably a bit more efficient to go by version tag since we have
the info in the json, more below)

Right; I don't need this to be 100% complete -- as long as a couple of
issues turn up it's probably good enough motivation.

In practice just listing a bunch of numbers probably won't change the
way people think, so I'm taking the time to briefly describe potential
impacts (what component, very broad trigger conditions e.g. network
packet or local access, likely risk if exploited e.g. RCE, memory
leak...); so ultimately it requires looking at things in more details
than I have time to check for all CVEs and will likely keep checking a
few "juicy" ones...
But it's a very good point, we should check again regularly and update
that list if some new bad thing stands out.

I didn't think of checking the mails, that's certainly easier to grep
than json as it's line-oriented.
It's going to take a bit more of processing to check not just bugs that
were backported in the stable trees, but things introduced in earlier
kernels... Someting like this?

  rg -l 'Issue introduced in ([234]\.[0-9]* |5\.[0-9] |5\.10\.[0-9]* )' | sort > introduced_before_5.10
  xargs rg -l 'fixed in 5\.10' < introduced_before_5.10 | sort > fixed_in_5.10
  comm -3 introduced_before_5.10 fixed_in_5.10 |tail
cve/published/2024/CVE-2024-35844.mbox
cve/published/2024/CVE-2024-35904.mbox
cve/published/2024/CVE-2024-35951.mbox
cve/published/2024/CVE-2024-35971.mbox
cve/published/2024/CVE-2024-36009.mbox
cve/published/2024/CVE-2024-36013.mbox
   grep 'Issue introdu' cve/published/2024/CVE-2024-35971.mbox
Issue introduced in 5.8 with commit 797047f875b5 and fixed in 6.1.87 with commit 492337a4fbd1
Issue introduced in 5.8 with commit 797047f875b5 and fixed in 6.6.28 with commit cba376eb036c
Issue introduced in 5.8 with commit 797047f875b5 and fixed in 6.8.7 with commit 49d5d70538b6
Issue introduced in 5.8 with commit 797047f875b5 and fixed in 6.9 with commit be0384bf599c

The regex is a bit too manual to make a generic search script, and that
feels very kludgy (at least mbox files do look like they get updated
together with json), but that can be enough for my local needs for now.

I was thinking something more along the line of parsing all the json
files for containers.cna.affected by release version item (versionType
!= git);
It should be possible for a given stable tag to check if a given CVE
applies or not immediately so it would be a matter of making this a bit
more searchable -- probably make a reverse index with all the edges for
faster search and keep appending new CVEs as they pop up.

But it's a bit more work, so I'll gratefully take the grep mailboxes
version for now :)

Yes, these (basically patches without a Fixes:) will always be
problematic; basically would need to also check all mails with "Fixed in
[newer versions]" without the "Issue introduced in" text.

Capitalization on Fixed can differentiate this so something like this?

  rg -l 'Issue introduced in ([234]\.[0-9]* |5\.[0-9] |5\.10\.[0-9]* )|Fixed in' 

This is bringing up the list of candidates from 101 to 543 so the
initial check is going to be "fun"; I'll probably stick to the first
variant for now...

Also, in this case the json properly defaults to affected so a search by
json as suggested above would also turn them up for further inspection.

Well, either way we won't get around the problem that much manual work
is still required; as said in my first mail my time is quite limited but
I'll try to check a few from time to time.

Ideally we'll want to limit duplicating this work for other
downstreams... So:
 - get more people to look at these
   - if unaffected (e.g. CVE-2024-35867 you singled out above as not
     affecting 5.10), report it so the reference files can be updated
   - if affected backport patch, so it can be fixed and the refernece
     file can also be updated.
 - less work for everyone else!

But finding volunteers for that kind of work might not be quite as easy
as I make it sound like :)

Cheers,
-- 
Dominique Martinet | Asmadeus