[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2024092740-straw-wavy-9fc6@gregkh>
Date: Fri, 27 Sep 2024 10:21:29 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: oss-security@...ts.openwall.com
Cc: Dominique Martinet <asmadeus@...ewreck.org>
Subject: Re: List linux CVEs for a given stable release?
Digging up an old thread, as we have new tools now....
On Thu, May 30, 2024 at 12:03:55PM +0200, Greg Kroah-Hartman wrote:
> > > > - I'm currently not watching patches entering newer stable branches as
> > > > closely, so if there are any new CVEs not fixed in the latest 5.10 I'd
> > > > like to check if some impact us and will help with backports as possible
> > > > (we're a small company so my time is limited, but might as well give
> > > > back when I can)
> > >
> > > That would be great, for where we know, we list when a vulnerability was
> > > added to the tree, and where it was fixed. That can leave many branches
> > > still vulnerable where we have not fixed the issue yet. One example
> > > would be CVE-2024-26629.
> > >
> > > You can see these in our repo by just doing:
> > > git grep "5\.10" | grep introduced | grep -v fixed
> >
> > 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.
>
> The mbox files do get updated along with the json, but please, let's not
> parse mbox files, that was a bad example I gave here, sorry.
>
> > I was thinking something more along the line of parsing all the json
> > files for containers.cna.affected by release version item (versionType
> > != git);
>
> That might be good, but really, we already have the needed information
> here with the tool that creates all of this 'dyad', in the scripts/
> directory. The output of that should be _much_ easier to parse:
>
> $ ./scripts/dyad be0384bf599c
> # ./scripts/dyad version: efdbc505ff2f
> # getting vulnerable:fixed pairs for git id be0384bf599cf1eb8d337517feeb732d71f75a6f
> 5.8:797047f875b5463719cc70ba213eb691d453c946:6.1.87:492337a4fbd1421b42df684ee9b34be2a2722540
> 5.8:797047f875b5463719cc70ba213eb691d453c946:6.6.28:cba376eb036c2c20077b41d47b317d8218fe754f
> 5.8:797047f875b5463719cc70ba213eb691d453c946:6.8.7:49d5d70538b6b8f2a3f8f1ac30c1f921d4a0929b
> 5.8:797047f875b5463719cc70ba213eb691d453c946:6.9:be0384bf599cf1eb8d337517feeb732d71f75a6f
>
> That tool generates a list of "vulnerable:fixed" pairs of version and
> git ids. I have thought about checking in that output into the git repo
> as odds are that would be easier than forcing you to regenerate it all
> the time.
>
> Here you see that the 5.10.y branch does not have a fix yet, and might
> be easier than parsing the json files (which also show this), unless you
> have a good json parser (i.e. something other than just bash.)
>
> This output also catches where we introduce, and then fix, the issue in
> the same release. dyad will show this, but as the issue never was in a
> public release, CVE will not let us list it as that isn't relevent
> there. But it IS relevent for those that might cherry-pick random
> commits.
Note that the vulns.git repo on git.kernel.org is now checking in the
output as described above, so that people can parse this data better,
and simpler.
And there is a script in there called 'strak' that will show you all
outstanding CVEs that are NOT fixed for any git commit in the Linux
kernel tree (or tag), and will also show up all CVEs that are fixed, as
of this moment in time, for any specific kernel release (not git commit,
sorry.)
Hopefully that will help people determine what known-cve-entries are
still not fixed in their specific kernel tree, as well as show more
information as to what IS fixed for specific releases. If anyone has
problems with them, please let me know. I do know the tools are slow
when running, I wanted to make them work first, will work on
optimizations later (we make way too many calls to git that should be
cached...)
thanks,
greg k-h
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
