Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 29 May 2024 21:23:50 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Dominique Martinet <asmadeus@...ewreck.org>
Cc: oss-security@...ts.openwall.com
Subject: Re: List linux CVEs for a given stable release?

On Wed, May 29, 2024 at 09:53:48AM +0900, Dominique Martinet wrote:
> 
> With the new vulns[3] repo I thought I could do similar search there,
> but while there are scripts to search by commit ID or by CVE I don't see
> anything allowing search for issues affecting a given stable release.
> 
> [3] https://git.kernel.org/pub/scm/linux/security/vulns.git/

True, we don't have that yet, but with the scripts in there, it should
be easy to knock this up (hint, pass the id to scripts/cve_search) if
you need it.

> My motivation here is double:
> - We notify our users of notable CVEs fixed on every update to encourage
> them to upgrade every time (it's sad, but in the embedded world not
> updating is still the norm despite our efforts to make upgrades as
> painless as possible... New regulations are coming so hopefully that
> will slowly improve, but as of now such motivations help)

The issue is, CVEs are assigned usually long _AFTER_ the stable release
has happened.  So if you want to do this type of report for the latest
stable release, it will look like there are no CVEs.  But if you wait a
few weeks, suddenly that old release will have many CVEs assigned to
them.

This is just due to the process we currently have where we review each
commit in the stable releases to determine if a CVE should be assigned
or not.  Obviously this takes time and we are running a few weeks behind
the current releases.

So you would have to run the script a lot, to keep it up to date, which
is why a "how many CVEs are listed in the latest release" isn't really
going to be all that valuable to your users.

> - 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

But note that for some issues, we don't have the information for when
they are introduced, so if they are not fixed in the 5.10 branch, does
that mean the branch _is_ vulnerable, or is not?  One example of a "is
not" might be CVE-2024-35867 as we think the code isn't present in 5.10,
but we don't have an automated way of determining that.  So that would
take more work than just a simple grep of the tree.

> The information is there in the json files, so it's just a matter of
> writing some scripts to check them, but I can't believe there's none so
> I probably have missed something.
> 
> Does someone have such a script that'd list the latest CVEs for a given
> tree?

How about something as simple as the following to see what is in
5.10.101:

	for id in $(git log --format="%H" v5.10.100..v5.10.101); do
		cve=$(cve_search ${id})
		cve_found=$?
		if [[ "${cve_found}" == "0" ]]; then
			echo "${cve} is in range"
		fi
	done

Note, typed in email client, not tested, use at your own risk...

hope this helps,

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.