linux-kernel-module cataloger doesn't extract version
What happened: I scanned usr/lib using the newest syft (1.0.7) I see that some packages are extracted without versions. I would like to know if this is the expected behavour. What you expected to happen: All packages contain versions. Steps to reproduce the issue:
- build a basic ec2
- scan with syft /usr/lib Anything else we need to know?: I'm attaching some additional information:
"id": "4c09ac4b6900071d",
"name": "ceph",
"version": "",
"type": "linux-kernel-module",
"foundBy": "linux-kernel-cataloger",
"locations": [
{
"path": "/modules/5.10.217-205.860.amzn2.aarch64/kernel/fs/ceph/ceph.ko",
"accessPath": "/modules/5.10.217-205.860.amzn2.aarch64/kernel/fs/ceph/ceph.ko",
"annotations": {
"evidence": "primary"
}
}
],
"licenses": [
{
"value": "GPL",
"spdxExpression": "",
"type": "declared",
"urls": [],
"locations": [
{
"path": "/modules/5.10.217-205.860.amzn2.aarch64/kernel/fs/ceph/ceph.ko",
"accessPath": "/modules/5.10.217-205.860.amzn2.aarch64/kernel/fs/ceph/ceph.ko",
Environment:
- Output of
syft version: 1.0.7 - OS (e.g:
cat /etc/os-releaseor similar): linux arm (ec2)
any ETA for this bug ? got the same issue
Having the same issue, is there any solution in the horizon?
Same issue here, looking forward for a solution.
NOTE: here's a dockerfile to reproduce this issue:
FROM amazonlinux:2023.5.20240624.0@sha256:5bf791027b4659e73c33a88a3fa2b314b8e2c0ee60cb1088a097171ee7f180db
RUN yum update && \
yum install -y tar gzip kernel.x86_64
Ok, I've done some digging into this. I think there just isn't any version information in many of these kernel modules (including ceph). If you run Syft against the image mentioned above, you'll see a LOT of kernel modules which don't have versions. In fact, the vast majority don't have versions. Using ceph as an example, Syft extracts this modinfo (the modinfo CLI reports the same thing), but it doesn't have a version field:
license=GPL
description=Ceph filesystem for Linux
author=Patience Warnick <[email protected]>
author=Yehuda Sadeh <[email protected]>
author=Sage Weil <[email protected]>
parm=disable_send_metrics:Enable sending perf metrics to ceph cluster (default: on)
alias=fs-ceph
srcversion=152EEABE682FDEA0A59808B
depends=libceph,fscache,netfs
retpoline=Y
intree=Y
name=ceph
vermagic=6.1.94-99.176.amzn2023.x86_64 SMP preempt mod_unload modversions
So, what should Syft do here? I don't think vermagic or srcversion fields are reporting the ceph version, are they?
It seems to me, if a user has a cataloger enabled we should surface packages, even if they don't have a version. But vuln matching with packages without versions seems like it's likely to have false positives, so maybe we might want to make Grype default to skip matching when no version is present, but provide an option to enable it? (I think this issue originated from: https://github.com/anchore/grype/issues/1956)
I'm happy to hear thoughts about this.
Hi! Thanks for your answer. From your experience, does it makes sense packages from the kernel will be without versions? sounds weird? how can they see the differences between packages without having this kind of information?
btw, I remember once that a package didn't have a name in this cataloger, but I can't reproduce it.
regarding grype - I am not sure skipping the packages is the best practice, need to think about it..
I don't know a lot about kernel modules, but generally speaking: executable code works fine without having a version identifier. I assume these were obtained from known sources and compiled to the appropriate format but just didn't have anything that included the version information in the build.
I'm also assuming the srcversion is some sort of Git hash (or other similar SCM identifier), so a distro could probably use that to understand what code was built. But this doesn't give enough information by itself to be useful as a version for vuln matching in Grype or really for identifying the version of the software to a human. It's possible there is some online/data lookup that could resolve a real version identifier from the srcversion, but we're certainly not doing that today and I don't know offhand how involved that would be (it might be pretty difficult if each distro has a different SCM copy of these in different locations, etc.; and maybe they don't even have versions as such but just rely on the SCM hashes). So, without any sort of further data, we're a bit stuck in what Syft is able to surface.
Hi, here is a Dockerfile which worked for me (the example above didn't work for me):
FROM amazonlinux:2023.5.20240624.0@sha256:5bf791027b4659e73c33a88a3fa2b314b8e2c0ee60cb1088a097171ee7f180db
# Update repositories and install necessary packages
RUN yum update -y && \
yum install -y tar gzip && \
yum search kernel | grep 'kernel-' && \
yum install -y kernel
# Optionally, you can list installed packages to confirm
RUN rpm -qa | grep kernel
From my point of view it looks weird so many packages are without version, I suggest to further check it.. I wonder if the parser is missing something.