| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
net: qualcomm: rmnet: restore skb->dev on deaggregated frames
rmnet_map_deaggregate() allocates each sub-frame with alloc_skb() and
leaves skb->dev NULL. __rmnet_map_ingress_handler() assigns
skb->dev = ep->egress_dev only on the data path, but a MAP command frame
is dispatched to rmnet_map_command() before that, so rmnet_map_send_ack()
runs netif_tx_lock(skb->dev) on a NULL device. An unprivileged user
reaches this by unsharing a user+net namespace, creating an rmnet link
over a tap device with INGRESS_DEAGGREGATION and INGRESS_MAP_COMMANDS,
and writing an aggregated frame carrying a flow-control command to the
tap fd.
Restore the assignment dropped by 378e25357ac7, so every skb leaving
rmnet_map_deaggregate() has a valid device.
BUG: KASAN: null-ptr-deref in _raw_spin_lock (kernel/locking/spinlock.c:158)
Write of size 4 at addr 00000000000004b4 by task exploit/144
Call Trace:
_raw_spin_lock (kernel/locking/spinlock.c:158)
netif_tx_lock (net/sched/sch_generic.c:497)
rmnet_map_command (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c:67)
rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:125)
__netif_receive_skb_core.constprop.0 (net/core/dev.c:6103)
...
__netif_receive_skb_one_core (net/core/dev.c:6214)
netif_receive_skb (net/core/dev.c:6474)
tun_get_user (drivers/net/tun.c:1966)
tun_chr_write_iter (drivers/net/tun.c:2012)
vfs_write (fs/read_write.c:687)
ksys_write (fs/read_write.c:739)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
Kernel panic - not syncing: Fatal exception in interrupt |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: validate ef->size covers the record's name and value
When an EA record has a non-zero ef->size, ntfs_read_ea() only checks
that the record fits in the remaining buffer (ea_size > bytes), not that
ef->size is large enough to hold the record's own name_len + 1 + elength.
A crafted image can pass validation with, e.g., ef->size = 24 but
elength = 0xffff. ntfs_get_ea() then trusts elength and copies it out of
the undersized record, reading past the kmalloc(info->size) allocation
and leaking heap memory to userspace via getxattr():
BUG: KASAN: slab-out-of-bounds in ntfs_get_ea (fs/ntfs3/xattr.c:302)
Read of size 65535 at addr ffff888100794550 by task exploit
__asan_memcpy (mm/kasan/shadow.c:105)
ntfs_get_ea (fs/ntfs3/xattr.c:302)
ntfs_getxattr (fs/ntfs3/xattr.c:848)
__vfs_getxattr (fs/xattr.c:441)
vfs_getxattr (fs/xattr.c:474)
do_getxattr (fs/xattr.c:800)
path_getxattrat (fs/xattr.c:868)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
The buggy address is located 80 bytes inside of
allocated 84-byte region in cache kmalloc-96
Compute the size the record needs and require ef->size to cover it. |
| In the Linux kernel, the following vulnerability has been resolved:
isofs: fix out-of-bounds page array access on empty zisofs block
zisofs_uncompress_block()'s empty-block fast path returns
pcount << PAGE_SHIFT, ignoring the incoming poffset, unlike the
decompression path which returns bytes produced relative to poffset.
zisofs_fill_pages() uses that return to advance its page cursor, so when
the zisofs block size is below PAGE_SIZE and a sub-page block leaves
poffset partway into a page, a following empty block over-counts and
advances pages[] one element past its end, after which
"if (poffset && *pages)" reads pages[1] out of bounds. rock.c only
rejects a block-size shift > 17, so a crafted "ZF" Rock Ridge record can
set it below PAGE_SHIFT; the bug is reached by an ordinary read() of a
compressed file on such a mounted ISO9660 image.
Return the byte count relative to poffset and zero only
[poffset, PAGE_SIZE) of the first page, matching the decompression path.
The page-aligned case (poffset == 0) is unaffected.
BUG: KASAN: slab-out-of-bounds in zisofs_read_folio (fs/isofs/compress.c:290)
Read of size 8 at addr ffff88800f5eac48 by task exploit/142
zisofs_read_folio (fs/isofs/compress.c:290)
read_pages (mm/readahead.c:184)
...
filemap_read (mm/filemap.c:2814)
vfs_read (fs/read_write.c:574)
__x64_sys_pread64 (fs/read_write.c:769)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
The buggy address is located 0 bytes to the right of the
allocated 8-byte region in the kmalloc-8 cache |
| In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: clear vdev->msi_perm after freeing it on init failure
vfio_msi_cap_len() lazily allocates the per-device MSI permission table:
vdev->msi_perm = kmalloc_obj(struct perm_bits, GFP_KERNEL_ACCOUNT);
if (!vdev->msi_perm)
return -ENOMEM;
ret = init_pci_cap_msi_perm(vdev->msi_perm, len, flags);
if (ret) {
kfree(vdev->msi_perm);
return ret; /* vdev->msi_perm left dangling */
}
When init_pci_cap_msi_perm() -> alloc_perm_bits() fails with -ENOMEM, the
error path frees vdev->msi_perm but leaves the freed pointer stored in
it. vdev->msi_perm is not re-zeroed later because struct
vfio_pci_core_device is per-device and persists across open/close cycles,
and the vfio_config_init() error path returns without calling
vfio_config_free(). So the dangling pointer outlives the failed open.
That leads to two use-after-frees on the same device:
1. Reuse. The next vfio_config_init() sees the stale pointer at
"if (vdev->msi_perm) return len;" and reuses the freed object. MSI
config accesses in vfio_pci_config_rw_single() then dereference and
call the freed perm->readfn / perm->writefn function pointers.
2. Double free. A later vfio_config_free() runs free_perm_bits() and
kfree() on the already-freed object.
Fix it by NULLing vdev->msi_perm after the kfree(), matching the
NULL-after-free discipline already used in free_perm_bits() and
vfio_config_free().
BUG: KASAN: slab-use-after-free in vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961)
Read of size 8 at addr ffff88800fcc88d0 by task exploit/143
Call Trace:
...
kasan_report (mm/kasan/report.c:595)
vfio_pci_config_rw_single (drivers/vfio/pci/vfio_pci_config.c:1961)
vfio_pci_config_rw (drivers/vfio/pci/vfio_pci_config.c:1986)
vfio_pci_rw (drivers/vfio/pci/vfio_pci_core.c:1599)
vfs_read (fs/read_write.c:572)
__x64_sys_pread64 (fs/read_write.c:764)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
...
Followed on device close by a double free of the same object:
Oops: general protection fault, probably for non-canonical address
0x1f63e0e8000008: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:kfree (mm/slub.c:6711)
Call Trace:
vfio_config_free (drivers/vfio/pci/vfio_pci_config.c:1861)
vfio_pci_core_disable (drivers/vfio/pci/vfio_pci_core.c:685)
vfio_pci_core_close_device (drivers/vfio/pci/vfio_pci_core.c:777)
vfio_df_close (drivers/vfio/vfio_main.c:602)
vfio_device_fops_release (drivers/vfio/vfio_main.c:648)
__fput (fs/file_table.c:512)
__x64_sys_close (fs/open.c:1496)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
...
Kernel panic - not syncing: Fatal exception |
| In the Linux kernel, the following vulnerability has been resolved:
vxlan: vnifilter: enforce exact length of GROUP/GROUP6 attributes
The VXLAN VNI filter entry policy declares the GROUP/GROUP6 address
attributes as NLA_BINARY with only a maximum length, so validate_nla()
accepts a payload shorter than the address. The GROUP consumer reads it
with nla_get_in_addr(), an unconditional 4-byte load, so a short
attribute over-reads up to 3 bytes of uninitialised slab data, which are
stored into remote_ip and echoed back via RTM_GETTUNNEL, disclosing
kernel memory.
Switch both entries to NLA_POLICY_EXACT_LEN() so the validator rejects
any GROUP/GROUP6 that is not exactly 4 / 16 bytes; a valid address is
always sent at full width. |
| An authentication issue was addressed with improved state management. This issue is fixed in iOS 27 and iPadOS 27. An attacker with physical access to an unlocked device may be able to view Wi-Fi passwords without authentication. |
| An integer overflow was addressed with improved input validation. This issue is fixed in macOS Golden Gate 27. Processing a maliciously crafted file may lead to a denial-of-service or potentially disclose memory contents. |
| A path handling issue was addressed with improved validation. This issue is fixed in iOS 27 and iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. An app may be able to access user-sensitive data. |
| A use-after-free issue was addressed with improved memory management. This issue is fixed in iOS 26.7 and iPadOS 26.7, iOS 27 and iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7, tvOS 27, visionOS 27, watchOS 27. Connecting to a malicious NFS server may lead to kernel memory corruption. |
| A race condition was addressed with improved locking. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. A local user may be able to read kernel memory. |
| This issue was addressed through improved state management. This issue is fixed in Safari 27, iOS 27 and iPadOS 27, macOS Golden Gate 27. A malicious website may be able to determine what apps a user has installed. |
| In BharatMLStack up to and including v1.3.0, Trufflebox UI stores the JWT authentication token, full user object, and session ID in the browser's localStorage, which is fully accessible to any JavaScript running on the page. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Handle negative S1 walk levels in VNCR TLB size evaluation
Computing the effects of a TLB invalidation involves looking at
the size of the mapping cached by the TLB. For S1 mappings such as
VNCR, this is deducted from the combination of the base granule size
and the mapping level.
However, this implies that the S1 MMU is *on*. When the MMU is off,
we indicate this with the level being set to a "creative" value of
-127 (S1_MMU_DISABLED).
This ends-up being misinterpreted by pgshift_level_to_ttl() as it
doesn't handle negative levels at all (the level is immediately cast
to a u8 and only the bottom two bits considered), leading to an
invalidation size of 0. Not helpful.
Tidy-up pgshift_level_to_ttl() to handle these negative levels, and
ttl_to_size() to always return SZ_1G when no valid TTL is present.
This allows the removal of open-coded checks for similar situations.
Note that the check for a negative value not explicitely checking for
S1_MMU_DISABLED is deliberate, so that actual negative levels introduced
with LVA2 and D128 can take the same path if we ever support them. |
| On affected platforms running Arista EOS with gRPC Network Management Interface (gNMI) enabled, a specially crafted request could allow a malicious authenticated client with gRPC Network Management Interface (gNMI) access to execute arbitrary code with root privileges on the switch. |
| Novel vulnerabilities to launch algorithmic complexity attacks on DNSSEC have been researched under the term 'ReTrap'. These result in degradation of service when malicious zones are used to serve the algorithmic complexity vulnerabilities. NLnet Labs Unbound up to and including 1.26.0 is vulnerable to some of them. TagTrap, where the triple(Zone, Algo, KeyTag) matching mechanism introduces a significant attack vector when resolvers handle malicious responses containing numerous mismatched DNSKEY, RRSIG, and DS record. DelegationTrap, where constructing the chain-of-trust requires iterative validation of DNSKEY and DS records from the root zone downward. For deeply nested domains, this results in significant computational overhead. NsecTrap, where responses with excessive invalid NSEC records compel the resolver to validate each one. AdditionalTrap, where Unbound by default would try to DNSSEC validate the ADDITIONAL section as well. This can be exploited to waste validation resources by malicious users. |
| NLnet Labs Unbound 1.12.0 up to and including 1.26.0 has a use-after-free vulnerability when compiled for DNS-over-HTTPs support with '--with-libnghttp2'. During failure code paths (i.e., RPZ drop query, jostle due to heavy traffic), a dropped DoH stream brings down the whole DoH session and does not account properly for other DoH streams in the same session. This leads to use-after-free in those code paths. If the prerequisites are satisfied (possible RPZ drop or heavy client traffic), a malicious actor can trigger the vulnerability with a single DoH connection and the appropriate traffic. Impact is limited as the reads are not user controlled and the use-after-free leads to early returns. However, a hardened allocator can catch the use-after-free and controllably terminate the process resulting to denial of service. |
| In NLnet Labs Unbound up to and including 1.26.0, a vulnerability was found in that can progressively corrupt heap memory and under certain systems and compilation options could lead to remote code execution. The vulnerability starts when CNAME synthesis during an upstream response needs to enforce(rewrite) a max TTL value in the packet buffer. Coupled with a compression pointer that points to the overwritten value and invalidates the domain name, it leads to an error path that does not properly move the buffer position and allows for the heap buffer overflow. Since this is heavily reliant on heap memory layout, results are memory corruption that eventually leads to a crash and under specific systems and compilation options remote code execution. |
| In NLnet Labs Unbound up to and including 1.26.0, a vulnerability was found in the DNSSEC validator that enables denial of service and possible remote code execution as a result of digesting DNSKEYs. A DNSKEY with an owner compression pointer to its own RDATA can overflow the digest buffer. Remote code execution is possible through attacker controlled data. An adversary can exploit the vulnerability by controlling a malicious zone and querying a vulnerable Unbound. |
| An out-of-bounds read issue was addressed with improved input validation. This issue is fixed in iOS 27 and iPadOS 27, macOS Golden Gate 27, tvOS 27, visionOS 27, watchOS 27. Processing a maliciously crafted font may result in the disclosure of process memory. |
| A denial-of-service issue was addressed with improved validation. This issue is fixed in iOS 18.7.10 and iPadOS 18.7.10. A remote attacker may be able to cause a denial-of-service. |
