The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal() There's issue as follows: ...
    EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1     with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1):
    Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs     (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation     failed for inode 206 at logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should     not happen!! Data will be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at     logical offset 0 with max blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will     be lost EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max     blocks 1 with error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs     (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with     error 117 EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost EXT4-fs (mmcblk0p1): error count     since last fsck: 1 EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760     EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760 ... According to the log     analysis, blocks are always requested from the corrupted block group. This may happen as follows:
    ext4_mb_find_by_goal ext4_mb_load_buddy ext4_mb_load_buddy_gfp ext4_mb_init_cache     ext4_read_block_bitmap_nowait ext4_wait_block_bitmap ext4_validate_block_bitmap if (!grp ||     EXT4_MB_GRP_BBITMAP_CORRUPT(grp)) return -EFSCORRUPTED; // There's no logs. if (err) return err; // Will     return error ext4_lock_group(ac->ac_sb, group); if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)))     // Unreachable goto out; After commit 9008a58e5dce (ext4: make the bitmap read routines return real error     codes) merged, Commit 163a203ddb36 (ext4: mark block group as corrupt on block bitmap error) is no real     solution for allocating blocks from corrupted block groups. This is because if     'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then 'ext4_mb_load_buddy()' may return an error. This     means that the block allocation will fail. Therefore, check block group if corrupted when     ext4_mb_load_buddy() returns error. (CVE-2026-43068)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Published	Updated	Severity
312301	Linux Distros Unpatched Vulnerability : CVE-2026-43068	Nessus	Misc.	5/5/2026	5/7/2026	medium
313522	Amazon Linux 2023 : bpftool, kernel, kernel-devel (ALAS2023-2026-1681)	Nessus	Amazon Linux Local Security Checks	5/9/2026	5/11/2026	high

Detections

Analytics

Plugins Search

medium

high