Most recent entries from all

BELL-CVE-2026-43338

Affected: Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts

certfr-2026-avi-0745 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…

certfr-2026-avi-0745

EUVD-2026-315893

fkie_cve-2026-43338

In the Linux kernel, the following vulnerability has been resolved:

btrfs: reserve enough transaction items for qgroup ioctls

Currently our qgroup ioctls don't reserve any space, they just do a transaction join, which does not reserve any space, neither for the quota tree updates nor for the delayed refs generated when updating the quota tree. The quota root uses the global block reserve, which is fine most of the time since we don't expect a lot of updates to the quota root, or to be too close to -ENOSPC such that other critical metadata updates need to resort to the global reserve.

However this is not optimal, as not reserving proper space may result in a transaction abort due to not reserving space for delayed refs and then abusing the use of the global block reserve.

For example, the following reproducer (which is unlikely to model any real world use case, but just to illustrate the problem), triggers such a transaction abort due to -ENOSPC when running delayed refs:

$ cat test.sh #!/bin/bash

DEV=/dev/nullb0 MNT=/mnt/nullb0

umount $DEV &> /dev/null # Limit device to 1G so that it's much faster to reproduce the issue. mkfs.btrfs -f -b 1G $DEV mount -o commit=600 $DEV $MNT

fallocate -l 800M $MNT/filler btrfs quota enable $MNT

for ((i = 1; i <= 400000; i++)); do btrfs qgroup create 1/$i $MNT done

umount $MNT

When running this, we can see in dmesg/syslog that a transaction abort happened:

[436.490] BTRFS error (device nullb0): fa…

GHSA-5h67-3fpf-pw2r

In the Linux kernel, the following vulnerability has been resolved:

btrfs: reserve enough transaction items for qgroup ioctls

However this is not optimal, as not reserving proper space may result in a transaction abort due to not reserving space for delayed refs and then abusing the use of the global block reserve.

$ cat test.sh #!/bin/bash

DEV=/dev/nullb0 MNT=/mnt/nullb0

umount $DEV &> /dev/null # Limit device to 1G so that it's much faster to reproduce the issue. mkfs.btrfs -f -b 1G $DEV mount -o commit=600 $DEV $MNT

fallocate -l 800M $MNT/filler btrfs quota enable $MNT

for ((i = 1; i <= 400000; i++)); do btrfs qgroup create 1/$i $MNT done

umount $MNT

When running this, we can see in dmesg/syslog that a transaction abort happened:

[436.490] BTRFS error (device nullb0): fa…

msrc_CVE-2026-43338 — btrfs: reserve enough transaction items for qgroup ioctls

msrc_CVE-2026-43338

openSUSE-SU-2026:20912-1 — Security update for the Linux Kernel

Security update for the Linux Kernel

SUSE-SU-2026:22043-1 — Security update for the Linux Kernel

Security update for the Linux Kernel

UBUNTU-CVE-2026-43338

Affected: Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 232 more

In the Linux kernel, the following vulnerability has been resolved: btrfs: reserve enough transaction items for qgroup ioctls Currently our qgroup ioctls don't reserve any space, they just do a transaction join, which does not reserve any space, neither for the quota tree updates nor for the delayed refs generated when updating the quota tree. The quota root uses the global block reserve, which is fine most of the time since we don't expect a lot of updates to the quota root, or to be too close to -ENOSPC such that other critical metadata updates need to resort to the global reserve. However this is not optimal, as not reserving proper space may result in a transaction abort due to not reserving space for delayed refs and then abusing the use of the global block reserve. For example, the following reproducer (which is unlikely to model any real world use case, but just to illustrate the problem), triggers such a transaction abort due to -ENOSPC when running delayed refs: $ cat test.sh #!/bin/bash DEV=/dev/nullb0 MNT=/mnt/nullb0 umount $DEV &> /dev/null # Limit device to 1G so that it's much faster to reproduce the issue. mkfs.btrfs -f -b 1G $DEV mount -o commit=600 $DEV $MNT fallocate -l 800M $MNT/filler btrfs quota enable $MNT for ((i = 1; i <= 400000; i++)); do btrfs qgroup create 1/$i $MNT done umount $MNT When running this, we can see in dmesg/syslog that a transaction abort happened: [436.490] BTRFS error (device nullb0): failed to run…

WID-SEC-W-2026-1454 — Linux Kernel: Mehrere Schwachstellen

Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren oder offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.