Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_event: fix potential UAF in hci_le_remote_conn_param_req_evt<br /> <br /> hci_conn lookup and field access must be covered by hdev lock in<br /> hci_le_remote_conn_param_req_evt, otherwise it&amp;#39;s possible it is freed<br /> concurrently.<br /> <br /> Extend the hci_dev_lock critical section to cover all conn usage.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/qaic: Handle DBC deactivation if the owner went away<br /> <br /> When a DBC is released, the device sends a QAIC_TRANS_DEACTIVATE_FROM_DEV<br /> transaction to the host over the QAIC_CONTROL MHI channel. QAIC handles<br /> this by calling decode_deactivate() to release the resources allocated for<br /> that DBC. Since that handling is done in the qaic_manage_ioctl() context,<br /> if the user goes away before receiving and handling the deactivation, the<br /> host will be out-of-sync with the DBCs available for use, and the DBC<br /> resources will not be freed unless the device is removed. If another user<br /> loads and requests to activate a network, then the device assigns the same<br /> DBC to that network, QAIC will "indefinitely" wait for dbc-&gt;in_use = false,<br /> leading the user process to hang.<br /> <br /> As a solution to this, handle QAIC_TRANS_DEACTIVATE_FROM_DEV transactions<br /> that are received after the user has gone away.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: qixis-fpga: Fix error handling for devm_regmap_init_mmio()<br /> <br /> devm_regmap_init_mmio() returns an ERR_PTR() on failure, not NULL.<br /> The original code checked for NULL which would never trigger on error,<br /> potentially leading to an invalid pointer dereference.<br /> Use IS_ERR() and PTR_ERR() to properly handle the error case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix incorrect pruning due to atomic fetch precision tracking<br /> <br /> When backtrack_insn encounters a BPF_STX instruction with BPF_ATOMIC<br /> and BPF_FETCH, the src register (or r0 for BPF_CMPXCHG) also acts as<br /> a destination, thus receiving the old value from the memory location.<br /> <br /> The current backtracking logic does not account for this. It treats<br /> atomic fetch operations the same as regular stores where the src<br /> register is only an input. This leads the backtrack_insn to fail to<br /> propagate precision to the stack location, which is then not marked<br /> as precise!<br /> <br /> Later, the verifier&amp;#39;s path pruning can incorrectly consider two states<br /> equivalent when they differ in terms of stack state. Meaning, two<br /> branches can be treated as equivalent and thus get pruned when they<br /> should not be seen as such.<br /> <br /> Fix it as follows: Extend the BPF_LDX handling in backtrack_insn to<br /> also cover atomic fetch operations via is_atomic_fetch_insn() helper.<br /> When the fetch dst register is being tracked for precision, clear it,<br /> and propagate precision over to the stack slot. For non-stack memory,<br /> the precision walk stops at the atomic instruction, same as regular<br /> BPF_LDX. This covers all fetch variants.<br /> <br /> Before:<br /> <br /> 0: (b7) r1 = 8 ; R1=8<br /> 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8<br /> 2: (b7) r2 = 0 ; R2=0<br /> 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm<br /> 4: (bf) r3 = r10 ; R3=fp0 R10=fp0<br /> 5: (0f) r3 += r2<br /> mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1<br /> mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10<br /> mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2)<br /> mark_precise: frame0: regs=r2 stack= before 2: (b7) r2 = 0<br /> 6: R2=8 R3=fp8<br /> 6: (b7) r0 = 0 ; R0=0<br /> 7: (95) exit<br /> <br /> After:<br /> <br /> 0: (b7) r1 = 8 ; R1=8<br /> 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8<br /> 2: (b7) r2 = 0 ; R2=0<br /> 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm<br /> 4: (bf) r3 = r10 ; R3=fp0 R10=fp0<br /> 5: (0f) r3 += r2<br /> mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1<br /> mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10<br /> mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2)<br /> mark_precise: frame0: regs= stack=-8 before 2: (b7) r2 = 0<br /> mark_precise: frame0: regs= stack=-8 before 1: (7b) *(u64 *)(r10 -8) = r1<br /> mark_precise: frame0: regs=r1 stack= before 0: (b7) r1 = 8<br /> 6: R2=8 R3=fp8<br /> 6: (b7) r0 = 0 ; R0=0<br /> 7: (95) exit

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Reject sleepable kprobe_multi programs at attach time<br /> <br /> kprobe.multi programs run in atomic/RCU context and cannot sleep.<br /> However, bpf_kprobe_multi_link_attach() did not validate whether the<br /> program being attached had the sleepable flag set, allowing sleepable<br /> helpers such as bpf_copy_from_user() to be invoked from a non-sleepable<br /> context.<br /> <br /> This causes a "sleeping function called from invalid context" splat:<br /> <br /> BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo<br /> preempt_count: 1, expected: 0<br /> RCU nest depth: 2, expected: 0<br /> <br /> Fix this by rejecting sleepable programs early in<br /> bpf_kprobe_multi_link_attach(), before any further processing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/x25: Fix potential double free of skb<br /> <br /> When alloc_skb fails in x25_queue_rx_frame it calls kfree_skb(skb) at<br /> line 48 and returns 1 (error).<br /> This error propagates back through the call chain:<br /> <br /> x25_queue_rx_frame returns 1<br /> |<br /> v<br /> x25_state3_machine receives the return value 1 and takes the else<br /> branch at line 278, setting queued=0 and returning 0<br /> |<br /> v<br /> x25_process_rx_frame returns queued=0<br /> |<br /> v<br /> x25_backlog_rcv at line 452 sees queued=0 and calls kfree_skb(skb)<br /> again<br /> <br /> This would free the same skb twice. Looking at x25_backlog_rcv:<br /> <br /> net/x25/x25_in.c:x25_backlog_rcv() {<br /> ...<br /> queued = x25_process_rx_frame(sk, skb);<br /> ...<br /> if (!queued)<br /> kfree_skb(skb);<br /> }

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: stm32-ospi: Fix resource leak in remove() callback<br /> <br /> The remove() callback returned early if pm_runtime_resume_and_get()<br /> failed, skipping the cleanup of spi controller and other resources.<br /> <br /> Remove the early return so cleanup completes regardless of PM resume<br /> result.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (tps53679) Fix array access with zero-length block read<br /> <br /> i2c_smbus_read_block_data() can return 0, indicating a zero-length<br /> read. When this happens, tps53679_identify_chip() accesses buf[ret - 1]<br /> which is buf[-1], reading one byte before the buffer on the stack.<br /> <br /> Fix by changing the check from "ret

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/rsrc: reject zero-length fixed buffer import<br /> <br /> validate_fixed_range() admits buf_addr at the exact end of the<br /> registered region when len is zero, because the check uses strict<br /> greater-than (buf_end &gt; imu-&gt;ubuf + imu-&gt;len). io_import_fixed()<br /> then computes offset == imu-&gt;len, which causes the bvec skip logic<br /> to advance past the last bio_vec entry and read bv_offset from<br /> out-of-bounds slab memory.<br /> <br /> Return early from io_import_fixed() when len is zero. A zero-length<br /> import has no data to transfer and should not walk the bvec array<br /> at all.<br /> <br /> BUG: KASAN: slab-out-of-bounds in io_import_reg_buf+0x697/0x7f0<br /> Read of size 4 at addr ffff888002bcc254 by task poc/103<br /> Call Trace:<br /> io_import_reg_buf+0x697/0x7f0<br /> io_write_fixed+0xd9/0x250<br /> __io_issue_sqe+0xad/0x710<br /> io_issue_sqe+0x7d/0x1100<br /> io_submit_sqes+0x86a/0x23c0<br /> __do_sys_io_uring_enter+0xa98/0x1590<br /> Allocated by task 103:<br /> The buggy address is located 12 bytes to the right of<br /> allocated 584-byte region [ffff888002bcc000, ffff888002bcc248)

Two heap-based out-of-bounds read vulnerabilities in the STL ASCII file parser in Open CASCADE Technology (OCCT) V8_0_0_rc5 exist in RWStl_Reader::ReadAscii because buffers returned by Standard_ReadLineBuffer::ReadLine() are not properly length-validated before strncasecmp or direct byte access. User-assisted attackers can trigger these issues by persuading a victim to open a crafted STL file with extremely short lines, resulting in a denial of service or possible information disclosure.

An issue was discovered in VrmlData_IndexedFaceSet::TShape in the VRML V2.0 parser in Open CASCADE Technology (OCCT) V8_0_0_rc5 allows attackers to cause a denial of service via a crafted VRML file. The issue occurs because malformed VRML input can trigger dereference of a corrupt or unvalidated pointer during shape construction in libTKDEVRML.so.

An out-of-bounds read vulnerability in VrmlData_IndexedLineSet::TShape in the VRML parser in Open CASCADE Technology (OCCT) V8_0_0_rc5 allows attackers to cause a denial of service via a crafted VRML file. The issue occurs because coordIndex values from parsed input are used as direct array indices without validation against the size of the coordinate array during geometry processing.