| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/tegra241-cmdqv: Synchronize the error ISR against VINTF (de)init
A user VINTF is torn down by tegra241_cmdqv_deinit_vintf(), which runs from
the destroy callback and from the init-failure unwind in the alloc handler.
It clears the cmdqv->vintfs[] slot and lets the iommufd core free it, but
nothing serializes that against the error interrupt: tegra241_cmdqv_isr()
reads cmdqv->vintfs[idx] and dereferences the vintf. A concurrent error can
make the ISR read a slot mid-clear (a NULL deref) or use a vintf which is
about to be freed (a use-after-free).
deinit_vintf() also returns idx to the IDA before clearing the slot, so a
concurrent create that reuses idx can publish its new vintf into the slot,
only for this teardown to erase it again with the stale NULL store.
On the other end, tegra241_cmdqv_init_vintf() publishes a new vintf with a
plain store to the cmdqv->vintfs[] slot, and the ISR dereferences fields of
a published vintf such as vintf->base. A plain store gives no ordering on a
weakly-ordered CPU, and a stale VINTF_ERR_MAP bit on a reused idx can make
the ISR pick a vintf the moment it is published, before its fields are set
or tegra241_vintf_hw_init() runs.
The cmdqv->vintfs[0] slot stays NULL until tegra241_cmdqv_init_structures()
first creates VINTF0, so the slot 0 read needs the same NULL check.
Publish every slot with an smp_store_release(), and read each slot in the
ISR with an smp_load_acquire() under a NULL check, so the ISR always sees
a fully built vintf or NULL. Also make deinit_vintf() clear the slot, and
synchronize_irq() prior to returning idx to the IDA, so no vintf is freed
under a running handler and no reused idx is clobbered. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Clear buf on error in __bpf_get_task_stack
Both bpf_get_task_stack and bpf_get_task_stack_sleepable helpers that
use __bpf_get_task_stack have buf defined as ARG_PTR_TO_UNINIT_MEM
argument and we should initialize the buf on every return path.
Adding missing buf memset for __bpf_get_task_stack fail paths. This
provides deterministic buffer contents, which is useful when the buffer
is used directly as a map key. |
| In the Linux kernel, the following vulnerability has been resolved:
ACPI: RISC-V: Check acpi_get_handle() status in riscv_acpi_add_prt_dep()
In riscv_acpi_add_prt_dep(), the acpi_get_handle() call can fail which
would leave link_handle uninitialized.
Fix it by checking the acpi_get_handle() return status and skip the entry
if it fails. |
| OpenSlide is a C library for reading whole slide image files. Prior to 4.0.1, a behavior change in libtiff 4.7.1 causes the indirect TIFF tile path in src/openslide-decode-tiff.c and _openslide_tiff_read_tile() to request a full-height destination for a partial bottom tile row, allowing uninitialized heap memory to enter pixel data returned by openslide_read_region(). A crafted but valid slide can trigger the issue in TIFF-based formats other than Hamamatsu NDPI when a network service renders attacker-provided slides. Successful extraction depends on pixel transparency handling and recompression, OpenSlide with libtiff 4.7.0 or earlier is not affected, and official binary builds 4.0.0.10 and 4.0.0.11 are affected. This issue is fixed in OpenSlide 4.0.1 and official binary build 4.0.0.12. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix infinite loop in pcpu_freelist push with one possible CPU
__pcpu_freelist_push() can loop forever when only one CPU is possible
and an NMI re-enters pcpu_freelist_push() while the interrupted context
holds that CPU's freelist lock.
After the current-CPU fast path fails, the fallback loop walks
cpu_possible_mask while skipping the current CPU. With CONFIG_SMP=n, or
when an SMP kernel is limited to one possible CPU with nr_cpus=1 or
possible_cpus=1, there are no other possible CPUs to examine. The loop
therefore makes no lock acquisition attempt and can never make progress.
The following stack was observed on a UP system:
NMI context:
pcpu_freelist_push
free_htab_elem
htab_map_delete_elem
[perf-event BPF program]
__perf_event_overflow
perf_event_nmi_handler
exc_nmi
Interrupted context:
__pcpu_freelist_push
pcpu_freelist_push
free_htab_elem
htab_map_delete_elem
[raw_tp/sys_enter BPF program]
__bpf_trace_sys_enter
do_syscall_64
raw_res_spin_lock() detects the same-CPU recursive acquisition and
returns -EDEADLK, but the subsequent fallback loop has no candidate head
on a system with one possible CPU.
Restore the extra fallback head that existed before the rqspinlock
conversion. Keep the current-CPU fast path, then try the other possible
CPUs and finally the extra head. The additional head lets a push, which
cannot fail without losing a preallocated element, make progress when the
only per-CPU head is held by the interrupted context.
Also check the extra head from the pop path so that nodes placed there
can be reused. |
| In the Linux kernel, the following vulnerability has been resolved:
fuse: publish io-uring queues with release semantics
fuse_uring_create_queue() initializes a fuse_ring_queue and then
publishes the pointer into ring->queues[qid] with WRITE_ONCE() under the
fch->lock. There are several readers that may concurrently be fetching
that pointer locklessly and then deferencing it.
WRITE_ONCE() doesn't ensure ordering of the queue's field
initialization before the ring->queues[qid] pointer assignment. The
queue must be published with smp_store_release() so the field
initialization is guaranteed to happen before.
Readers in paths where the read may happen concurrently with the store
need to use READ_ONCE() because any race involving a plain access is
undefined. |
| In the Linux kernel, the following vulnerability has been resolved:
net: bridge: mrp: fix uninitialised bytes on the wire
br_mrp_alloc_test_skb() builds MRP test frames on an skb from
dev_alloc_skb(), which does not clear the linear data area. On the MRA
ring-role branch the sub-option TLV header is appended with
sub_tlv = skb_put(skb, sizeof(*sub_tlv));
sub_tlv->type = BR_MRP_SUB_TLV_HEADER_TEST_AUTO_MGR;
so sub_tlv->length is never written, and the two trailing alignment bytes
are appended with a bare skb_put() that does not clear them either. The
neighbouring oui and sub_opt regions are explicitly zeroed, so three
uninitialised bytes are left in every MRA MRP_Test frame that goes out.
Put the sub-option TLV header and the alignment padding in a single
skb_put_zero(), which clears both. The AUTO_MGR sub-TLV carries no
payload, so the zeroed length field is already the value it should have. |
| In Eclipse OpenJ9 versions up to 0.60, when executing class files where a previously concrete superclass method has been recompiled as abstract, execution is incorrectly delegated to an interface default method. |
| RustCrypto CMOV provides conditional move CPU intrinsics which are guaranteed on major platforms to execute in constant-time and not be rewritten as branches by the compiler. From 0.1.1 until 0.5.4, the aarch64 implementations of Cmov and CmovEq in cmov/src/backends/aarch64.rs assume high bits are zero-extended when loading values smaller than a register, so set high bits such as [8..] in a Cmov selector or [16..] of self or other in the u16 and i16 CmovEq implementations can cause left.cmovz(&right, condition) to produce incorrect output. This issue is fixed in version 0.5.4. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_qca: fix NULL pointer dereference in qca_setup() for non-serdev device
hu->serdev is NULL for hci_uart attached via non-serdev paths, but
qca_setup() unconditionally calls serdev_device_get_drvdata(hu->serdev)
and dereferences the result, causing a NULL pointer dereference.
Fix by guarding the dereference with a NULL check, consistent with the
rest of qca_setup(). |
| In the Linux kernel, the following vulnerability has been resolved:
vdpa: solidrun: Fix UB bug with devres
In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to
pcim_iomap_regions() is placed on the stack. Neither
pcim_iomap_regions() nor the functions it calls copy that string.
Should the string later ever be used, this, consequently, causes
undefined behavior since the stack frame will by then have disappeared.
Fix the bug by allocating the strings on the heap through
devm_kasprintf(). |
| In the Linux kernel, the following vulnerability has been resolved:
iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP
generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem,
on huge=always tmpfs, issues a warning and then hangs (interruptibly):
WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9
CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2
...
copy_page_from_iter_atomic+0xa6/0x5ec
generic_perform_write+0xf6/0x1b4
shmem_file_write_iter+0x54/0x67
Fix copy_page_from_iter_atomic() by limiting it in that case
(include/linux/skbuff.h skb_frag_must_loop() does similar).
But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too
surprising, has outlived its usefulness, and should just be removed? |
| In the Linux kernel, the following vulnerability has been resolved:
net: phy: don't try to setup PHY-driven SFP cages when using genphy
We don't have support for PHY-driver SFP cages with the genphy code.
On top of that, it was found by sashiko that running
sfp_bus_add_upstream() for genphy deadlocks, as for genphy the PHY
probing runs under RTNL, which isn't the case for non-genphy drivers.
This problem was reproduced, and does lead to a deadlock on RTNL.
Before the blamed commit, the phy_sfp_probe() call was made by
individual PHY drivers, so there was no way to get to the SFP probing
path when using genphy.
Let's therefore only run phy_sfp_probe when not using genphy. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: prevent uninitialized lcn caused by zero len
syzbot reported a uninit-value in ntfs_iomap_begin [1].
Since runs was not touched yet, run_lookup_entry() immediately fails
and returns false, which makes the value of "*len" 0.
Simultaneously, the new value and err value are also 0, causing the
logic in attr_data_get_block_locked() to jump directly to ok, ultimately
resulting in *lcn being triggered before it is set [1].
In ntfs_iomap_begin(), the check for a 0 value in clen is moved forward
to before updating lcn to avoid this [1].
[1]
BUG: KMSAN: uninit-value in ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825
ntfs_iomap_begin+0x8c0/0x1460 fs/ntfs3/inode.c:825
iomap_iter+0x9b7/0x1540 fs/iomap/iter.c:110
Local variable lcn created at:
ntfs_iomap_begin+0x15d/0x1460 fs/ntfs3/inode.c:786 |
| Ghidra before 11.2 contains a use after free vulnerability in the Sleigh backend caused by undefined static initialization order of the SleighArchitecture::translators and XmlArchitectureCapability singletons. Attackers can trigger an infinite loop or denial of service during shutdown by exploiting the unsafe destruction order that causes iteration over deallocated memory. |
| BACnet Stack is a BACnet open source protocol stack C library for embedded systems. Prior to 1.4.3, decode_signed32() in src/bacnet/bacint.c reconstructs a 32-bit signed integer from four APDU bytes using signed left shifts. When any of the four bytes has bit 7 set (value ≥ 0x80), the left-shift operation overflows a signed int32_t, which is undefined behavior per the C standard. This is flagged thousands of times per minute by UndefinedBehaviorSanitizer on any BACnet input containing signed-integer property values with high-bit-set bytes. This vulnerability is fixed in 1.4.3. |
| iccDEV provides a set of libraries and tools for working with ICC color management profiles. Prior to version 2.3.1.6, there is an Undefined Behavior (UB) condition in IccUtil.cpp triggered by a crafted input profile. Under UndefinedBehaviorSanitizer, the issue is reported as invalid left shift operations on icUInt32Number (unsigned 32-bit) where the shifted value “cannot be represented” in that type. This issue has been patched in version 2.3.1.6. |
| iccDEV provides a set of libraries and tools for working with ICC color management profiles. Prior to version 2.3.1.6, an Undefined Behavior (UB) condition in IccUtil.cpp can be triggered by a crafted ICC profile when running iccDumpProfile. This issue has been patched in version 2.3.1.6. |
| iccDEV provides a set of libraries and tools for working with ICC color management profiles. Prior to version 2.3.1.6, a crafted ICC profile can trigger Undefined Behavior (UB) in CIccOpDefEnvVar::Exec() due to invalid enum values being loaded for icSigCmmEnvVar. The issue is observable under UBSan as a “load of value … not a valid value for type icSigCmmEnvVar”, indicating an invalid enum/type value being consumed during ICC profile processing. This issue has been patched in version 2.3.1.6. |
| iccDEV provides a set of libraries and tools for working with ICC color management profiles. Prior to version 2.3.1.6, a crafted ICC profile can trigger Undefined Behavior (UB) in CIccCalculatorFunc::ApplySequence() due to invalid enum values being loaded for icChannelFuncSignature. The issue is observable under UBSan as a “load of value … not a valid value for type icChannelFuncSignature”, indicating a type/enum value confusion scenario during ICC profile processing. This issue has been patched in version 2.3.1.6. |
