Most recent entries from all

bdu:2026-02719

BELL-CVE-2025-40100

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

certfr-2025-avi-0966 — De multiples vulnérabilités ont été découvertes dans les produits Microsoft. Elles permettent à un attaquant de provoqu…

certfr-2025-avi-0966

EUVD-2026-314896

fkie_cve-2025-40100

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

btrfs: do not assert we found block group item when creating free space tree

Currently, when building a free space tree at populate_free_space_tree(), if we are not using the block group tree feature, we always expect to find block group items (either extent items or a block group item with key type BTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree with btrfs_search_slot_for_read(), so we assert that we found an item. However this expectation is wrong since we can have a new block group created in the current transaction which is still empty and for which we still have not added the block group's item to the extent tree, in which case we do not have any items in the extent tree associated to the block group.

The insertion of a new block group's block group item in the extent tree happens at btrfs_create_pending_block_groups() when it calls the helper insert_block_group_item(). This typically is done when a transaction handle is released, committed or when running delayed refs (either as part of a transaction commit or when serving tickets for space reservation if we are low on free space).

So remove the assertion at populate_free_space_tree() even when the block group tree feature is not enabled and update the comment to mention this case.

Syzbot reported this with the following stack trace:

BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in f…

GHSA-g2r9-36vv-r5vp

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

btrfs: do not assert we found block group item when creating free space tree

So remove the assertion at populate_free_space_tree() even when the block group tree feature is not enabled and update the comment to mention this case.

Syzbot reported this with the following stack trace:

BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in f…

msrc_CVE-2025-40100 — btrfs: do not assert we found block group item when creating free space tree

msrc_CVE-2025-40100

openSUSE-SU-2025:15702-1 — kernel-devel-6.17.7-1.1 on GA media

kernel-devel-6.17.7-1.1 on GA media

SUSE-SU-2025:21040-1 — Security update for the Linux Kernel

Security update for the Linux Kernel

UBUNTU-CVE-2025-40100

Affected: Ubuntu:Pro:14.04:LTS: linux-azure, 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, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 222 more

In the Linux kernel, the following vulnerability has been resolved: btrfs: do not assert we found block group item when creating free space tree Currently, when building a free space tree at populate_free_space_tree(), if we are not using the block group tree feature, we always expect to find block group items (either extent items or a block group item with key type BTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree with btrfs_search_slot_for_read(), so we assert that we found an item. However this expectation is wrong since we can have a new block group created in the current transaction which is still empty and for which we still have not added the block group's item to the extent tree, in which case we do not have any items in the extent tree associated to the block group. The insertion of a new block group's block group item in the extent tree happens at btrfs_create_pending_block_groups() when it calls the helper insert_block_group_item(). This typically is done when a transaction handle is released, committed or when running delayed refs (either as part of a transaction commit or when serving tickets for space reservation if we are low on free space). So remove the assertion at populate_free_space_tree() even when the block group tree feature is not enabled and update the comment to mention this case. Syzbot reported this with the following stack trace: BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in fs/btrf…

WID-SEC-W-2025-2450 — Linux Kernel: Mehrere Schwachstellen

Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service-Situation führen oder eine Speicherbeschädigung verursachen können.