On Fri, 2025-09-26 at 07:54 +0000, Subhash wrote:
>
> Dear Debian Kernel/Security Team,
>
>
> I hope you're doing well. My name is Subhash, and I'm from the Qualys Security Research Team. I am examining the Debian security tracker entries (https://security-tracker.debian.org/tracker/CVE-xxxx-xxxx), which lists the Linux version as X.YY.ZZ-N as the fixed version. However, when reviewing the current source package listing athttps://packages.debian.org/source/trixie/linux, I see the latest version is A.BB.CC-N, while various subpackages have mixed versions. For Example-
> The Debian security tracker entry (https://security-tracker.debian.org/tracker/CVE-2024-57976), which lists the Linux version as 6.12.37-1 as the fixed version. However, when reviewing the current source package listing athttps://packages.debian.org/source/trixie/linux, I see the latest version is 6.12.48-1, while various subpackages have mixed versions like ata-modules-6.12.31-armmp-di, ata-modules-6.12.41+deb13-armmp-di,btrfs-modules-6.12.31-armmp-di, and xfs-modules-6.12.48-powerpc64le-di ..etc. I would like to request clarification on how fixed versions for Linux kernel CVEs map to binary subpackages in Debian. Specifically:
While there are often older versions still present in the archive, they
shouldn't be included in the package indices and therefore won't be
installable through APT.
> 1.
> Could you please clarify how these subpackage versions relate to the fixed source version and which ones include the CVE fix?
The security tracker records only source packages and versions.
Generally binary packages should have the same versions as their source
packages. (bpftool and usbip are exceptions to this; they have their
own version numbers which we combine with the source package version.)
This is complicated a bit by the code signing process:
source: linux
↓ build
binary: linux-image-<abiname>-unsigned, linux-image-<arch>-signed-template, …
↓ sign
source: linux-signed-<arch>
↓ build
binary: linux-image-<abiname>, …
The linux-signed-<arch> source packages have a different version number
than the linux source package due to Debian conventions for "native"
packages, but the final binary package versions will match the linux
source package.
> 2.
> When a fixed version is specified for the Linux source package, do all subsequent versions also include the fix by default?
All subsequent versions *for the same Debian release* will include the
fix, unless it's intentionally reverted for some reason. Later releases
should also get the fix, but aren't always updated in sync.
> 3.
> How can we determine the exact set of binary subpackages (xfs-modules-6.12.31-s390x-di,xfs-modules-6.12.41+deb13-riscv64-di,ata-modules-6.12.48+deb13-powerpc64le-di..etc) built from a given fixed source version?
In general, read the "Binary" field of the source package's .dsc file.
Because of the extra code signing step for linux, you'll need to also
read the .dsc files for linux-signed-amd64 and linux-signed-arm64.
> 4.
> What is the authoritative data source to retrieve this subpackage list for a particular version?
The FTP team's "projectb" database would be authoritative for packages
still in the main archive, but it's not public.
Probably the best source for you would be the snapshot.debian.org API:
<https://salsa.debian.org/snapshot-team/snapshot/raw/master/API>.
> 5.
> How can we confirm which subpackages are affected by or include a specific CVE fix?
The specific binary packages you listed are used only in the installer
(this is indicated by the ".udeb" suffix to the filename and the "-di"
suffix in the package name). They can't be installed on a normal Debian
system using APT. So I don't see any point in trying to work out which
of these an issue or fix applies to.
Ben.
--
Ben Hutchings
Horngren's Observation:
Among economists, the real world is often a special case.
Attachment:
signature.asc
Description: This is a digitally signed message part