Most recent entries from all

Withdrawn: BELL-CVE-2026-90131 — CVE-2026-90131 does not affect BellSoft software

Withdrawn by the publisher.

fkie_cve-2026-90131

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

ntfs: serialize resident iomap reads with mrec_lock

ntfs_read_iomap_begin_resident() walks the MFT record through ntfs_attr_lookup() -> ntfs_attr_find() without taking ni->mrec_lock, while ntfs_attr_record_resize(), ntfs_make_room_for_attr() and ntfs_resident_attr_record_add() memmove() the same base_ni->mrec buffer under that lock. map_mft_record() only takes a reference and does not serialize, so the reader can observe torn attribute length and offset fields while a writer is relocating the records.

KCSAN reports the race between the mmap read fault path and both link() and unlink():

BUG: KCSAN: data-race in ntfs_attr_find / ntfs_attr_record_resize

write to 0xffff888100af1018 of 4 bytes by task 96 on cpu 1: ntfs_attr_record_resize+0xd2/0x130 ntfs_attr_record_rm+0xad/0x530 ntfs_delete+0x224/0x640 ntfs_unlink+0x14d/0x280 vfs_unlink+0x157/0x520

read to 0xffff888100af1018 of 4 bytes by task 95 on cpu 0: ntfs_attr_find+0x104/0x5b0 ntfs_attr_lookup+0x39c/0x10c0 ntfs_read_iomap_begin_resident+0xc6/0x230 ntfs_read_iomap_begin+0x5d/0xa0 iomap_iter+0x2e2/0x6e0 iomap_read_folio+0x147/0x2a0 ntfs_read_folio+0x108/0x170 filemap_read_folio+0x35/0x100 filemap_fault+0x993/0x1000

value changed: 0x00000250 -> 0x000001f0

The address is mrec + 0x18, i.e. mft_record.bytes_in_use, and the change is the 96 bytes of one $FILE_NAME attribute being removed.

Keep base_ni->mre…

GHSA-p65r-ghh2-3f2q

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

ntfs: serialize resident iomap reads with mrec_lock

KCSAN reports the race between the mmap read fault path and both link() and unlink():

BUG: KCSAN: data-race in ntfs_attr_find / ntfs_attr_record_resize

write to 0xffff888100af1018 of 4 bytes by task 96 on cpu 1: ntfs_attr_record_resize+0xd2/0x130 ntfs_attr_record_rm+0xad/0x530 ntfs_delete+0x224/0x640 ntfs_unlink+0x14d/0x280 vfs_unlink+0x157/0x520

value changed: 0x00000250 -> 0x000001f0

The address is mrec + 0x18, i.e. mft_record.bytes_in_use, and the change is the 96 bytes of one $FILE_NAME attribute being removed.

Keep base_ni->mre…

openSUSE-SU-2026:11880-1 — kernel-devel-7.2.7-1.1 on GA media

kernel-devel-7.2.7-1.1 on GA media

UBUNTU-CVE-2026-90131

Affected: Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 96 more

In the Linux kernel, the following vulnerability has been resolved: ntfs: serialize resident iomap reads with mrec_lock ntfs_read_iomap_begin_resident() walks the MFT record through ntfs_attr_lookup() -> ntfs_attr_find() without taking ni->mrec_lock, while ntfs_attr_record_resize(), ntfs_make_room_for_attr() and ntfs_resident_attr_record_add() memmove() the same base_ni->mrec buffer under that lock. map_mft_record() only takes a reference and does not serialize, so the reader can observe torn attribute length and offset fields while a writer is relocating the records. KCSAN reports the race between the mmap read fault path and both link() and unlink(): BUG: KCSAN: data-race in ntfs_attr_find / ntfs_attr_record_resize write to 0xffff888100af1018 of 4 bytes by task 96 on cpu 1: ntfs_attr_record_resize+0xd2/0x130 ntfs_attr_record_rm+0xad/0x530 ntfs_delete+0x224/0x640 ntfs_unlink+0x14d/0x280 vfs_unlink+0x157/0x520 read to 0xffff888100af1018 of 4 bytes by task 95 on cpu 0: ntfs_attr_find+0x104/0x5b0 ntfs_attr_lookup+0x39c/0x10c0 ntfs_read_iomap_begin_resident+0xc6/0x230 ntfs_read_iomap_begin+0x5d/0xa0 iomap_iter+0x2e2/0x6e0 iomap_read_folio+0x147/0x2a0 ntfs_read_folio+0x108/0x170 filemap_read_folio+0x35/0x100 filemap_fault+0x993/0x1000 value changed: 0x00000250 -> 0x000001f0 The address is mrec + 0x18, i.e. mft_record.bytes_in_use, and the change is the 96 bytes of one $FILE_NAME attribute being removed. Keep base_ni->mrec_lock fr…