製品・ソフトウェアに関する情報
Vulnerability Search
LinuxのLinux Kernelにおける有効期限後のメモリの解放の欠如に関する脆弱性
Title LinuxのLinux Kernelにおける有効期限後のメモリの解放の欠如に関する脆弱性
Summary

Linuxカーネルにおいて、以下の脆弱性が修正されました。ext4の関数ext4_mb_find_by_goal()で、破損したグループからブロックを割り当てる問題があるためです。ログ解析によると、破損したブロックグループから常にブロックが要求される事象が発生しています。この問題は、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の流れで起こる可能性があります。具体的には、grpがNULLまたはEXT4_MB_GRP_BBITMAP_CORRUPT(grp)が真の場合、-EFSCORRUPTEDを返しますが、ログは記録されません。エラーがあればそのまま返されますが、ext4_lock_group(ac-ac_sb, group)内のEXT4_MB_GRP_BBITMAP_CORRUPT(e4b-bd_info)は通常到達できません。commit 9008a58e5dce（"ext4: make the bitmap read routines return real error codes"）の導入後、commit 163a203ddb36（"ext4: mark block group as corrupt on block bitmap error"）は、破損したブロックグループからのブロック割り当てを根本的に解決するものではありません。なぜなら、EXT4_MB_GRP_BBITMAP_CORRUPT(e4b-bd_info)が真の場合、ext4_mb_load_buddy()はエラーを返す可能性があり、それによってブロック割り当てが失敗するからです。したがって、ext4_mb_load_buddy()がエラーを返した場合は、ブロックグループが破損していないかを確認する必要があります。

Possible impacts 当該ソフトウェアが扱う情報について、外部への漏えいは発生しません。 また、当該ソフトウェアが扱う情報について、書き換えは発生しません。 さらに、当該ソフトウェアが完全に停止する可能性があります。 そして、この脆弱性を悪用した攻撃の影響は、他のソフトウェアには及びません。 
Solution

リリース情報、またはパッチ情報が公開されています。参考情報を参照して適切な対策を実施してください。

Publication Date May 5, 2026, midnight
Registration Date May 22, 2026, 10:54 a.m.
Last Update May 22, 2026, 10:54 a.m.
CVSS3.0 : 警告
Score 5.5
Vector CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Affected System
Linux
Linux Kernel 3.12 以上 5.10.253 未満
Linux Kernel 5.11 以上 5.15.203 未満
Linux Kernel 5.16 以上 6.1.168 未満
Linux Kernel 6.13 以上 6.18.21 未満
Linux Kernel 6.19 以上 6.19.11 未満
Linux Kernel 6.2 以上 6.6.131 未満
Linux Kernel 6.7 以上 6.12.80 未満
Linux Kernel 7.0
CVE (情報セキュリティ 共通脆弱性識別子)
CWE (共通脆弱性タイプ一覧)
その他
Change Log
No Changed Details Date of change
1 [2026年05月22日]
  掲載		 May 22, 2026, 10:54 a.m.
NVD Vulnerability Information
CVE-2026-43068
Summary

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

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.

Publication Date May 6, 2026, 1:16 a.m.
Registration Date May 6, 2026, 4:07 a.m.
Last Update May 6, 2026, 10:08 p.m.
Related information, measures and tools
Common Vulnerabilities List