add CVE-2026-31433 to security.toml

[oleole39]

No description provided.

[tituspijean]

Suggested change

	fixed_in_version.bookworm = "6.1.999" # FIXME : to be updated once we know the actual version number
	fixed_in_version.trixie = "6.12.999" # FIXME : to be updated once we know the actual version number
	fixed_in_version.bookworm = "6.1.170-1"
	fixed_in_version.trixie = "6.12.85-1"

https://security-tracker.debian.org/tracker/CVE-2026-31431

[tituspijean]

@alexAubin I might be misreading the code, but if I understand correctly, the system package we match here is simply linux. I do not have that on my system, however I do have linux-image-amd64 that would match the version we are looking for.

[oleole39]

@tituspijean Yes, good point. I had taken the name from https://security-tracker.debian.org/tracker/CVE-2026-31431 where the package is called as such. But it actually links to https://tracker.debian.org/pkg/linux which includes a long list of binaries. The closest match I can find with dpkg -l is indeed linux-image-amd64 or other installed earlier versions (vulnerable too) which are named with version number, e.g. linux-image-6.1.0-44-amd64.

Also I believe the arch name here will be specific to the machine's arch.
So do we have to declare vulnerability for each arch version - i.e. one entry for pacakge linux-image-amd64, one for linux-image-arm, etc. ?

[oleole39]

hmm but Yunohost system upgrade also offers a lib upgrade with same version than kernel:

linux-image-amd64 de 6.1.164-1 à 6.1.170-1
linux-libc-dev de 6.1.164-1 à 6.1.170-1 

Maybe it should be added as well?

This package provides userspaces headers from the Linux kernel. These headers are used by the installed headers for GNU libc and other system libraries.

https://packages.debian.org/bookworm/linux-libc-dev

[oleole39]

pushed a commit based on arch names for this package available there: https://packages.debian.org/search?suite=default&arch=armhf&searchon=names&keywords=linux-image-

[alexAubin]

The plot thickens ... on an RPi I don't have any of the debian kernel packages but I do have linux-image-rpiv6 and v7 along with linux-image-6.12.x (note the 6.12, despite that i'm on bookworm...).

I do have the linux-libc-dev package tho, though digging with aptitude why, it's installed because of build-essential, which is not a hundred percent guaranteed to be on the system I suppose ... and most importantly it's of course in 6.12.x too despite that i'm on bookworm, because the RPi apt repo ships more recent kernels I suppose merf

[oleole39]

I do have linux-image-rpiv6 and v7

Hmm can't find track of this in debian packages https://packages.debian.org/search?suite=default&section=all&arch=any&searchon=names&keywords=rpiv6

Have you already been offered an upgrade with the patch for this arch?
Is YNH Rpi version based directly on Debian, or something like Raspbian?

I do have the linux-libc-dev package tho, though digging with aptitude why

amd64 YNH 12.x shows:

me@machine:~$ sudo aptitude why linux-libc-dev
i   it-tools-ynh-deps Depends g++                                   
i A g++               Depends g++-12 (>= 12.2.0-1~)                 
i A g++-12            Depends libstdc++-12-dev (= 12.2.0-14+deb12u1)
i A libstdc++-12-dev  Depends libc6-dev (>= 2.23-1~)                
i A libc6-dev         Depends linux-libc-dev

me@machine:~$ sudo aptitude why libc-dev
i   privatebin-ynh-deps Depends zlib1g-dev          
i A zlib1g-dev          Depends libc6-dev | libc-dev

me@machine:~$ sudo aptitude why libc6-dev
i   it-tools-ynh-deps Depends g++                                   
i A g++               Depends g++-12 (>= 12.2.0-1~)                 
i A g++-12            Depends libstdc++-12-dev (= 12.2.0-14+deb12u1)
i A libstdc++-12-dev  Depends libc6-dev (>= 2.23-1~)  

[tituspijean]

Then I would suggest to patch the code that looks for the package version: iif the package is linux, then the version check should be done on uname -r with a bit of regex to only keep the actual kernel version.

Example on my server:

uname -r
6.12.73+deb13-amd64

Additionally, downloading the linux-image-... is not enough: the system needs to be rebooted for the kernel change to be effective. Maybe we should suggest that in the CVE alert.

[oleole39]

Then I would suggest to patch the code that looks for the package version: iif the package is linux, then the version check should be done on uname -r with a bit of regex to only keep the actual kernel version.

Is that a scripting suggestion (i.e. changing https://github.com/YunoHost/yunohost/blob/57020f46441556a246affb72aa6b9effb71e382d/src/diagnosers/00-basesystem.py probably) or just finding people using the 4 arch and get the value to update manually this PR ?

Additionally, downloading the linux-image-... is not enough: the system needs to be rebooted for the kernel change to be effective. Maybe we should suggest that in the CVE alert.

Yes I guess this is an evolution required in the security.toml structure: add a "comment" field (to allow adding instructions), or a "action" field (bash command that would open a confirmation popup and be run by the system, but maybe too instrusive).

[Josue-T]

We also need to keep in mind that there are many cases. For instance in case of lxc we need to check the kernel version on the host. And the host could have a different Debian version or also an other Debian distribution.

Also we can have a case when the workaround was applied without upgradings the kernel.

So to me at last for this CVE the easiest and the strongest way to check is by running a script.

"action" field (bash comment that would open a confirmation popup and be run by the system, but maybe too instrusive).

Seem to me a good idea.

[alexAubin]

For instance in case of lxc we need to check the kernel version on the host.

uuuh but I would expect uname -r ran inside a LXC to return the kernel version of the host ?

[Josue-T]

For instance in case of lxc we need to check the kernel version on the host.

uuuh but I would expect uname -r ran inside a LXC to return the kernel version of the host ?

Yes it's true but depending of the distribution of the host it might be complicated to know if the versions has been patched or not I'm my option because it could be any Linux distribution so having an exhaustive list of patched version is probably really complicated.