CVE Notify
19.6K subscribers
4 photos
338K links
Alert on the latest CVEs

Partner channel: @malwr
Download Telegram
๐Ÿšจ CVE-2026-97437
In the Linux kernel, the following vulnerability has been resolved:

ntfs3: fix out-of-bounds read in ntfs_dir_emit() and hdr_find_e()

The bounds check in ntfs_dir_emit() compares fname->name_len (a
character count) against e->size (a byte count) without accounting
for the 2-byte-per-character UTF-16LE encoding or the ATTR_FILE_NAME
header size:

if (fname->name_len + sizeof(struct NTFS_DE) > le16_to_cpu(e->size))

This computes: name_len + 16 > e_size

The correct check must account for the ATTR_FILE_NAME header (66 bytes
before the name) and the UTF-16LE character size (2 bytes each):

sizeof(NTFS_DE) + offsetof(ATTR_FILE_NAME, name) +
name_len * sizeof(short) > e_size

Which computes: 16 + 66 + name_len * 2 > e_size

The correct calculation already exists as fname_full_size() in ntfs.h
and is used in cmp_fnames(), namei.c, and fslog.c, but was not used
in the readdir path.

A crafted NTFS image with an index entry containing a small e->size
but large fname->name_len bypasses the current check, causing
ntfs_utf16_to_nls() to read past the entry boundary.

Additionally, add a key_size validation in hdr_find_e() to ensure the
declared key_size does not exceed the available entry data, preventing
comparison functions from reading past entry boundaries on the lookup
path.

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97438
In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: validate index entry key bounds

[BUG]
A malformed NTFS directory index entry can advertise a key_size larger
than the bytes actually present in its NTFS_DE payload. Directory lookup
then passes that malformed key to cmp_fnames(), which can read past the
end of the kmalloc'ed index buffer.

BUG: KASAN: slab-out-of-bounds in fname_full_size fs/ntfs3/ntfs.h:590 [inline]
BUG: KASAN: slab-out-of-bounds in cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46
Read of size 1 at addr ffff88801c313018 by task syz.6.3365/9279

Call Trace:
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xd1/0x650 mm/kasan/report.c:482
kasan_report+0xfb/0x140 mm/kasan/report.c:595
__asan_report_load1_noabort+0x14/0x30 mm/kasan/report_generic.c:378
fname_full_size fs/ntfs3/ntfs.h:590 [inline]
cmp_fnames+0x1ea/0x230 fs/ntfs3/index.c:46
hdr_find_e.isra.0+0x3ed/0x670 fs/ntfs3/index.c:762
indx_find+0x4b5/0x900 fs/ntfs3/index.c:1186
dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254
ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85
__lookup_slow+0x241/0x450 fs/namei.c:1816
lookup_slow fs/namei.c:1833 [inline]
walk_component+0x31c/0x570 fs/namei.c:2151
link_path_walk+0x592/0xd60 fs/namei.c:2519
path_lookupat+0x138/0x660 fs/namei.c:2675
filename_lookup+0x1f3/0x560 fs/namei.c:2705
filename_setxattr+0xad/0x1c0 fs/xattr.c:660
path_setxattrat+0x1d8/0x280 fs/xattr.c:713
__do_sys_lsetxattr fs/xattr.c:754 [inline]
__se_sys_lsetxattr fs/xattr.c:750 [inline]
__x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750
...

Allocated by task 9279:
kasan_save_stack+0x39/0x70 mm/kasan/common.c:56
kasan_save_track+0x14/0x40 mm/kasan/common.c:77
kasan_save_alloc_info+0x37/0x60 mm/kasan/generic.c:573
poison_kmalloc_redzone mm/kasan/common.c:400 [inline]
__kasan_kmalloc+0xc3/0xd0 mm/kasan/common.c:417
kasan_kmalloc include/linux/kasan.h:262 [inline]
__do_kmalloc_node mm/slub.c:5650 [inline]
__kmalloc_noprof+0x2bd/0x900 mm/slub.c:5662
kmalloc_noprof include/linux/slab.h:961 [inline]
indx_read+0x41d/0xad0 fs/ntfs3/index.c:1059
indx_find+0x447/0x900 fs/ntfs3/index.c:1179
dir_search_u+0x2c0/0x460 fs/ntfs3/dir.c:254
ntfs_lookup+0x1cc/0x2a0 fs/ntfs3/namei.c:85
__lookup_slow+0x241/0x450 fs/namei.c:1816
lookup_slow fs/namei.c:1833 [inline]
walk_component+0x31c/0x570 fs/namei.c:2151
link_path_walk+0x592/0xd60 fs/namei.c:2519
path_lookupat+0x138/0x660 fs/namei.c:2675
filename_lookup+0x1f3/0x560 fs/namei.c:2705
filename_setxattr+0xad/0x1c0 fs/xattr.c:660
path_setxattrat+0x1d8/0x280 fs/xattr.c:713
__do_sys_lsetxattr fs/xattr.c:754 [inline]
__se_sys_lsetxattr fs/xattr.c:750 [inline]
__x64_sys_lsetxattr+0xd0/0x150 fs/xattr.c:750
...

[CAUSE]
The index-header validators only validated INDEX_HDR-level geometry.
They did not walk each NTFS_DE to verify entry alignment, subnode
layout, or that key_size fit inside the entry payload. They also
allowed a last sentinel entry to carry a non-zero key_size.

[FIX]
Walk every NTFS_DE in ntfs3's index-header validators and reject
entries with invalid layout, mismatched subnode state, oversized
key_size, or non-zero sentinel keys before lookup or log replay can
consume them.

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97442
In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: fix invalid data access in ath11k_dp_rx_h_undecap_nwifi

In certain cases, hardware might provide packets with a
length greater than the maximum native Wi-Fi header length.
This can lead to accessing and modifying fields in the header
within the ath11k_dp_rx_h_undecap_nwifi() function for the
DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and
potentially result in invalid data access and memory corruption.

Kernel stack is corrupted in: ath11k_dp_rx_h_undecap+0x6b0/0x6b0 [ath11k]
Call trace:
ath11k_dp_rx_h_mpdu+0x0/0x2e8 [ath11k]
ath11k_dp_rx_h_mpdu+0x1e0/0x2e8 [ath11k]
ath11k_dp_rx_wbm_err+0x1e0/0x450 [ath11k]
ath11k_dp_rx_process_wbm_err+0x2fc/0x460 [ath11k]
ath11k_dp_service_srng+0x2e0/0x348 [ath11k]

Add a sanity check before processing the SKB to prevent invalid
data access in the undecap native Wi-Fi function for the
DP_RX_DECAP_TYPE_NATIVE_WIFI decap type.

This adapted from the discussion/patch of the ath12k driver [1].

Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97444
In the Linux kernel, the following vulnerability has been resolved:

ACPICA: add boundary checks in two places

Add boundary checks in acpi_ps_get_next_namestring() and
acpi_ps_peek_opcode() to prevent out-of-bounds access.

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97445
In the Linux kernel, the following vulnerability has been resolved:

ACPICA: Enhance buffer validation in acpi_ut_walk_aml_resources()

Enhance buffer validation in acpi_ut_walk_aml_resources() to prevent
buffer overflows.

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97448
In the Linux kernel, the following vulnerability has been resolved:

ACPICA: Add validation for node in acpi_ns_build_normalized_path()

Add validation for node in acpi_ns_build_normalized_path()
to prevent use-after-free vulnerabilities.

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97450
In the Linux kernel, the following vulnerability has been resolved:

ACPICA: validate handler object type in two places

ACPICA: validate handler object type in acpi_ev_has_default_handler()
and acpi_ev_find_region_handler().

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97451
In the Linux kernel, the following vulnerability has been resolved:

ACPICA: Fix integer overflow in acpi_ex_opcode_3A_1T_1R() (mid_op)

Add overflow check for Index + Length to prevent integer overflow
when calculating the truncation length. This prevents negative
size parameter being passed to memcpy().

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97452
In the Linux kernel, the following vulnerability has been resolved:

ACPICA: Prevent adding invalid references

Prevent adding references for local, argument, and debug objects
in acpi_ut_copy_simple_object().

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97454
In the Linux kernel, the following vulnerability has been resolved:

ACPICA: add boundary checks in acpi_ps_get_next_field()

Add boundary checks in acpi_ps_get_next_field() to prevent out-of-bounds
access.

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97455
In the Linux kernel, the following vulnerability has been resolved:

ACPICA: Fix use-after-free in acpi_ds_terminate_control_method()

Fix use-after-free issue in acpi_ds_terminate_control_method() by
clearing references to method locals and arguments.

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97474
In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mld: purge async notifications upon nic error

This fixes a kernel panic in reconfig failure:

1. we have a BSS connection
2. we have a NAN connection
3. FW error occurs
4. reconfig restores the BSS connection
5. however, restoring the NAN connection fails due to a FW error.
6. erroneously, ieee80211_handle_reconfig_failure is called and marks all
interfaces as not-in-driver (will be fixed in a different patch).
7. mac80211 frees the links of the BSS connection but doesn't tell the
driver about that, as it thinks that this vif is not in the driver.
8. in ieee80211_stop_device, *ALL* wiphy works are getting flushed
(erroneously?)
9. Therefore, async_handlers_wk is being executed, processing the
statistics notification that was received after we restored the BSS
connection.
10. the notification handler dereferences fw_id_to_bss_conf[id], which is
now a dangling pointer, as mac80211 already freed this link in (7).
11. On the first access to one of the links fields, we panic.

While this can and should be fixed by removing the call to
ieee80211_handle_reconfig_failure in (6), it is also not a good idea to
carry and maybe handle notifications from a dead FW.

We do purge the notifications when we stop the FW, but in reconfig
failure we stop the FW too late, after the notifications are processed.
In addition, async_handlers_wk can always be scheduled before the
reconfig work.

Purge the notifications immediately when transport notifies about a nic
error.

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97478
In the Linux kernel, the following vulnerability has been resolved:

virt: acrn: Fix irqfd use-after-free during eventfd shutdown

acrn_irqfd_deassign() and the eventfd EPOLLHUP wakeup can race and free
the same struct hsm_irqfd:

CPU0 CPU1
---- ----
eventfd_release()
wake_up_poll(EPOLLHUP)
hsm_irqfd_wakeup()
queue_work(&irqfd->shutdown)
acrn_irqfd_deassign()
hsm_irqfd_shutdown()
list_del_init()
eventfd_ctx_remove_wait_queue()
eventfd_ctx_put()
kfree(irqfd)
hsm_irqfd_shutdown_work()
container_of(work, ..., shutdown)
irqfd->vm <-- use-after-free

The deassign path freed the irqfd while a shutdown work item was
already queued by EPOLLHUP (or vice versa), so the work item could
resurrect a dangling pointer through container_of().

Switch to the lifetime model used by KVM irqfds:

- Deassign/deinit only deactivate the irqfd: remove it from vm->irqfds
under irqfds_lock and queue the cleanup work.
- hsm_irqfd_shutdown_work() becomes the sole owner that unhooks the
eventfd waitqueue entry, drops the eventfd reference and frees the
irqfd.
- A new HSM_IRQFD_FLAG_SHUTDOWN bit guarded by test_and_set_bit()
ensures the cleanup work is queued at most once, no matter how many
of {EPOLLHUP, deassign, deinit} fire concurrently. This is safe to
call from the waitqueue callback, which runs with wqh->lock held and
IRQs disabled and therefore cannot take irqfds_lock.
- acrn_irqfd_deassign() flushes vm->irqfd_wq before returning so the
eventfd is fully detached on return. acrn_irqfd_deinit() deactivates
every irqfd, flushes the workqueue and only then destroys it, so no
path can queue_work() onto a torn-down workqueue.
- acrn_irqfd_assign() now installs the eventfd waitqueue entry and
publishes the irqfd to vm->irqfds under irqfds_lock, so the irqfd is
never visible to deassign/deinit before its waitqueue entry is in
place, and any EPOLLHUP that fires in the assign window queues
cleanup work that blocks on irqfds_lock until publication is done.

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97496
In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Fix OOB memory exposure in get_wave_state()

The get_wave_state() function for v9 trusts cp_hqd_cntl_stack_size and
cp_hqd_cntl_stack_offset values read directly from the MQD, which are
written by GPU microcode and fully attacker-controlled on the
CRIU-restore path (via AMDKFD_IOC_RESTORE_PROCESS with H3).

this leads to an unbounded copy_to_user() that can leak adjacent
GTT/kernel memory. If offset > size, integer underflow produces a ~4 GiB
read length, if size is set to 1 MiB against a 4 KiB allocation, we leak
1 MiB of adjacent kernel memory (other queues' MQDs, ring buffers, KASLR
pointers).

Fix by clamping both cp_hqd_cntl_stack_size to the actual allocated
buffer size (q->ctl_stack_size) and cp_hqd_cntl_stack_offset to the
clamped size before performing arithmetic and copy_to_user().

This ensures we never read beyond the allocated kernel BO regardless of
attacker-supplied MQD field values.

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97497
In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Check bounds for allocate_sdma_queue restore_sdma_id

allocate_sdma_queue has an option where the sdma queue id can be
specified (used by CRIU). We weren't bounds-checking that
value.

Confirm it's less than the maximum number of queues.

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97508
In the Linux kernel, the following vulnerability has been resolved:

thunderbolt: Set tb->root_switch to NULL when domain is stopped

Similarly what we do with the firmware connection manager. This makes
tb_xdp_handle_request() return error to the remote host. However, we
need to make sure we keep the uuid alive so that we can reply until the
whole domain is released.

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97509
In the Linux kernel, the following vulnerability has been resolved:

thunderbolt: Keep XDomain reference during the lifetime of a service

This is needed because we release the service ID in tb_service_release()
and the ID array is owned by the parent XDomain.

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97513
In the Linux kernel, the following vulnerability has been resolved:

media: chips-media: wave5: Release m2m_ctx after Instance Removed from List

Possible use after free if IRQ thread manages to obtain spinlock between
m2m_ctx release and wave5_release function removing stream instance from
list of active instances. The IRQ thread looks for the m2m_ctx which is
freed so null pointer dereference occurs.

๐ŸŽ–@cveNotify
๐Ÿšจ CVE-2026-97520
In the Linux kernel, the following vulnerability has been resolved:

gfs2: move quota_init qc iterator increment

Move qc++ from the loop body into the for-loop increment
expression in gfs2_quota_init().

This keeps iterator progression explicit and avoids mixing pointer
advance with duplicate-slot handling in the loop body.

๐ŸŽ–@cveNotify