Add support for Wind River Linux

[joshbressers]

We have received a request to support scanning Wind River Linux container images in Grype.

The data we need to support this is all public

Wind River publishes vulnerability data for their images in a Git repo
https://distro.windriver.com/git/windriver-cve-tracker.git

They have told me that data is MIT licensed. I'm happy to file GrypeDB and Vunnel issues if needed.

There is are example wind river images in Docker Hub we can use for testing
https://hub.docker.com/r/windriver/wrlx-image

They also have a patchset against Trivy to support their images we can reference if needed
https://github.com/dreyna7399/wr-trivy-dist

[westonsteimel]

The vulnerability data format looks very similar to what ubuntu uses:

cat active/CVE-2024-4854
Candidate: CVE-2024-4854
PublicDate: 2024-05-14
Description:
 MONGO and ZigBee TLV dissector infinite loops in Wireshark 4.2.0
 to 4.2.4, 4.0.0 to 4.0.14, and 3.6.0 to 3.6.22 allow denial of
 service via packet injection or crafted capture file
Notes:
Priority:
Bugs:
 LIN1024-924
 LINCD-16624
 LIN1023-5421
 LIN1022-8159
 LIN1021-8747
 LIN1019-12366

Patches_wireshark:
10.24.33.1_wireshark: ignored (will not fix)
10.20.6.0_wireshark: ignored (will not fix)
10.23.30.1_wireshark: ignored (will not fix)
10.22.33.1_wireshark: ignored (will not fix)
10.21.20.1_wireshark: ignored (will not fix)
10.19.45.1_wireshark: ignored (will not fix)
10.17.41.1_wireshark: pending

cat active/CVE-2024-46688
Candidate: CVE-2024-46688
PublicDate: 2024-09-13
Description:
 In the Linux kernel, the following vulnerability has been resolved:

 erofs: fix out-of-bound access when z_erofs_gbuf_growsize() partially
 fails  If z_erofs_gbuf_growsize() partially fails on a global
 buffer due to memory allocation failure or fault injection (as
 reported by syzbot [1]), new pages need to be freed by comparing
 to the existing pages to avoid memory leaks.

 However, the old gbuf->pages[] array may not be large enough,
 which can lead to null-ptr-deref or out-of-bound access.

 Fix this by checking against gbuf->nrpages in advance.

 [1] https://lore.kernel.org/r/[email protected]
Notes:
Priority: medium
Bugs:
 LIN1024-4097
 LINCD-19375
 LIN1023-8182
 LIN1022-10846
 LIN1021-11308
 LIN1019-14758

Patches_linux:
10.24.33.1_linux: not-affected
10.20.6.0_linux: pending
10.23.30.1_linux: not-affected
10.22.33.1_linux: not-affected
10.21.20.1_linux: not-affected
10.19.45.1_linux: not-affected
10.17.41.1_linux: pending

cat active/CVE-2021-28861
Candidate: CVE-2021-28861
PublicDate: 2022-08-23
Description:
 Python 3.x through 3.10 has an open redirection vulnerability
 in lib/http/server.py due to no protection against multiple (/)
 at the beginning of URI path which may leads to information disclosure.
 NOTE: this is disputed by a third party because the http.server.html
 documentation page states "Warning: http.server is not recommended
 for production. It only implements basic security checks." 
Notes:
Priority: high
Bugs:
 LINCD-10092
 LIN1022-1430
 LIN1021-4195
 LIN1019-8724
 LIN10-10474

Patches_python:
10.20.6.0_python: released (10.22.41.0)
10.22.33.1_python: released (10.22.33.1)
10.21.20.1_python: released (10.21.20.14)
10.19.45.1_python: released (10.19.45.25)
10.17.41.1_python: released (10.17.41.27)

Patches_python2.7:
10.20.6.0_python2.7: released (10.22.41.0)
10.22.33.1_python2.7: released (10.22.33.1)
10.21.20.1_python2.7: released (10.21.20.14)
10.19.45.1_python2.7: released (10.19.45.25)
10.17.41.1_python2.7: released (10.17.41.27)

Patches_python3.4:
10.20.6.0_python3.4: released (10.22.41.0)
10.22.33.1_python3.4: released (10.22.33.1)
10.21.20.1_python3.4: released (10.21.20.14)
10.19.45.1_python3.4: released (10.19.45.25)
10.17.41.1_python3.4: released (10.17.41.27)

Patches_python3.5:
10.20.6.0_python3.5: released (10.22.41.0)
10.22.33.1_python3.5: released (10.22.33.1)
10.21.20.1_python3.5: released (10.21.20.14)
10.19.45.1_python3.5: released (10.19.45.25)
10.17.41.1_python3.5: released (10.17.41.27)

Patches_python3.6:
10.20.6.0_python3.6: released (10.22.41.0)
10.22.33.1_python3.6: released (10.22.33.1)
10.21.20.1_python3.6: released (10.21.20.14)
10.19.45.1_python3.6: released (10.19.45.25)
10.17.41.1_python3.6: released (10.17.41.27)

Patches_python3.7:
10.20.6.0_python3.7: released (10.22.41.0)
10.22.33.1_python3.7: released (10.22.33.1)
10.21.20.1_python3.7: released (10.21.20.14)
10.19.45.1_python3.7: released (10.19.45.25)
10.17.41.1_python3.7: released (10.17.41.27)

Patches_python3.8:
10.20.6.0_python3.8: released (10.22.41.0)
10.22.33.1_python3.8: released (10.22.33.1)
10.21.20.1_python3.8: released (10.21.20.14)
10.19.45.1_python3.8: released (10.19.45.25)
10.17.41.1_python3.8: released (10.17.41.27)

Patches_python3.9:
10.20.6.0_python3.9: released (10.22.41.0)
10.22.33.1_python3.9: released (10.22.33.1)
10.21.20.1_python3.9: released (10.21.20.14)
10.19.45.1_python3.9: released (10.19.45.25)
10.17.41.1_python3.9: released (10.17.41.27)

Patches_python3.10:
10.20.6.0_python3.10: released (10.22.41.0)
10.22.33.1_python3.10: released (10.22.33.1)
10.21.20.1_python3.10: released (10.21.20.14)
10.19.45.1_python3.10: released (10.19.45.25)
10.17.41.1_python3.10: released (10.17.41.27)

Patches_python3.11:
10.20.6.0_python3.11: released (10.22.41.0)
10.22.33.1_python3.11: released (10.22.33.1)
10.21.20.1_python3.11: released (10.21.20.14)
10.19.45.1_python3.11: released (10.19.45.25)
10.17.41.1_python3.11: released (10.17.41.27)

Notice that everything is based around the windriver release version rather than individual rpm package versions though, so that is definitely a difference

[westonsteimel]

distro block from image:

{
  "prettyName": "Wind River Linux Graphics LTS 22.33 Update 12",
  "name": "Wind River Linux Graphics LTS",
  "id": "wrlinux-graphics",
  "version": "10.22.33.12",
  "versionID": "10.22.33.12"
}