Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: Validate length in packet header before skb_put()<br /> <br /> When receiving a vsock packet in the guest, only the virtqueue buffer<br /> size is validated prior to virtio_vsock_skb_rx_put(). Unfortunately,<br /> virtio_vsock_skb_rx_put() uses the length from the packet header as the<br /> length argument to skb_put(), potentially resulting in SKB overflow if<br /> the host has gone wonky.<br /> <br /> Validate the length as advertised by the packet header before calling<br /> virtio_vsock_skb_rx_put().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: imu: bno055: fix OOB access of hw_xlate array<br /> <br /> Fix a potential out-of-bounds array access of the hw_xlate array in<br /> bno055.c.<br /> <br /> In bno055_get_regmask(), hw_xlate was iterated over the length of the<br /> vals array instead of the length of the hw_xlate array. In the case of<br /> bno055_gyr_scale, the vals array is larger than the hw_xlate array,<br /> so this could result in an out-of-bounds access. In practice, this<br /> shouldn&amp;#39;t happen though because a match should always be found which<br /> breaks out of the for loop before it iterates beyond the end of the<br /> hw_xlate array.<br /> <br /> By adding a new hw_xlate_len field to the bno055_sysfs_attr, we can be<br /> sure we are iterating over the correct length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: caam - Prevent crash on suspend with iMX8QM / iMX8ULP<br /> <br /> Since the CAAM on these SoCs is managed by another ARM core, called the<br /> SECO (Security Controller) on iMX8QM and Secure Enclave on iMX8ULP, which<br /> also reserves access to register page 0 suspend operations cannot touch<br /> this page.<br /> <br /> This is similar to when running OPTEE, where OPTEE will reserve page 0.<br /> <br /> Track this situation using a new state variable no_page0, reflecting if<br /> page 0 is reserved elsewhere, either by other management cores in SoC or<br /> by OPTEE.<br /> <br /> Replace the optee_en check in suspend/resume with the new check.<br /> <br /> optee_en cannot go away as it&amp;#39;s needed elsewhere to gate OPTEE specific<br /> situations.<br /> <br /> Fixes the following splat at suspend:<br /> <br /> Internal error: synchronous external abort: 0000000096000010 [#1] SMP<br /> Hardware name: Freescale i.MX8QXP ACU6C (DT)<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : readl+0x0/0x18<br /> lr : rd_reg32+0x18/0x3c<br /> sp : ffffffc08192ba20<br /> x29: ffffffc08192ba20 x28: ffffff8025190000 x27: 0000000000000000<br /> x26: ffffffc0808ae808 x25: ffffffc080922338 x24: ffffff8020e89090<br /> x23: 0000000000000000 x22: ffffffc080922000 x21: ffffff8020e89010<br /> x20: ffffffc080387ef8 x19: ffffff8020e89010 x18: 000000005d8000d5<br /> x17: 0000000030f35963 x16: 000000008f785f3f x15: 000000003b8ef57c<br /> x14: 00000000c418aef8 x13: 00000000f5fea526 x12: 0000000000000001<br /> x11: 0000000000000002 x10: 0000000000000001 x9 : 0000000000000000<br /> x8 : ffffff8025190870 x7 : ffffff8021726880 x6 : 0000000000000002<br /> x5 : ffffff80217268f0 x4 : ffffff8021726880 x3 : ffffffc081200000<br /> x2 : 0000000000000001 x1 : ffffff8020e89010 x0 : ffffffc081200004<br /> Call trace:<br /> readl+0x0/0x18<br /> caam_ctrl_suspend+0x30/0xdc<br /> dpm_run_callback.constprop.0+0x24/0x5c<br /> device_suspend+0x170/0x2e8<br /> dpm_suspend+0xa0/0x104<br /> dpm_suspend_start+0x48/0x50<br /> suspend_devices_and_enter+0x7c/0x45c<br /> pm_suspend+0x148/0x160<br /> state_store+0xb4/0xf8<br /> kobj_attr_store+0x14/0x24<br /> sysfs_kf_write+0x38/0x48<br /> kernfs_fop_write_iter+0xb4/0x178<br /> vfs_write+0x118/0x178<br /> ksys_write+0x6c/0xd0<br /> __arm64_sys_write+0x14/0x1c<br /> invoke_syscall.constprop.0+0x64/0xb0<br /> do_el0_svc+0x90/0xb0<br /> el0_svc+0x18/0x44<br /> el0t_64_sync_handler+0x88/0x124<br /> el0t_64_sync+0x150/0x154<br /> Code: 88dffc21 88dffc21 5ac00800 d65f03c0 (b9400000)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - flush misc workqueue during device shutdown<br /> <br /> Repeated loading and unloading of a device specific QAT driver, for<br /> example qat_4xxx, in a tight loop can lead to a crash due to a<br /> use-after-free scenario. This occurs when a power management (PM)<br /> interrupt triggers just before the device-specific driver (e.g.,<br /> qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains<br /> loaded.<br /> <br /> Since the driver uses a shared workqueue (`qat_misc_wq`) across all<br /> devices and owned by intel_qat.ko, a deferred routine from the<br /> device-specific driver may still be pending in the queue. If this<br /> routine executes after the driver is unloaded, it can dereference freed<br /> memory, resulting in a page fault and kernel crash like the following:<br /> <br /> BUG: unable to handle page fault for address: ffa000002e50a01c<br /> #PF: supervisor read access in kernel mode<br /> RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat]<br /> Call Trace:<br /> pm_bh_handler+0x1d2/0x250 [intel_qat]<br /> process_one_work+0x171/0x340<br /> worker_thread+0x277/0x3a0<br /> kthread+0xf0/0x120<br /> ret_from_fork+0x2d/0x50<br /> <br /> To prevent this, flush the misc workqueue during device shutdown to<br /> ensure that all pending work items are completed before the driver is<br /> unloaded.<br /> <br /> Note: This approach may slightly increase shutdown latency if the<br /> workqueue contains jobs from other devices, but it ensures correctness<br /> and stability.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix refcount leak causing resource not released<br /> <br /> When ksmbd_conn_releasing(opinfo-&gt;conn) returns true,the refcount was not<br /> decremented properly, causing a refcount leak that prevents the count from<br /> reaching zero and the memory from being released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> open_tree_attr: do not allow id-mapping changes without OPEN_TREE_CLONE<br /> <br /> As described in commit 7a54947e727b (&amp;#39;Merge patch series "fs: allow<br /> changing idmappings"&amp;#39;), open_tree_attr(2) was necessary in order to<br /> allow for a detached mount to be created and have its idmappings changed<br /> without the risk of any racing threads operating on it. For this reason,<br /> mount_setattr(2) still does not allow for id-mappings to be changed.<br /> <br /> However, there was a bug in commit 2462651ffa76 ("fs: allow changing<br /> idmappings") which allowed users to bypass this restriction by calling<br /> open_tree_attr(2) *without* OPEN_TREE_CLONE.<br /> <br /> can_idmap_mount() prevented this bug from allowing an attached<br /> mountpoint&amp;#39;s id-mapping from being modified (thanks to an is_anon_ns()<br /> check), but this still allows for detached (but visible) mounts to have<br /> their be id-mapping changed. This risks the same UAF and locking issues<br /> as described in the merge commit, and was likely unintentional.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: venus: protect against spurious interrupts during probe<br /> <br /> Make sure the interrupt handler is initialized before the interrupt is<br /> registered.<br /> <br /> If the IRQ is registered before hfi_create(), it&amp;#39;s possible that an<br /> interrupt fires before the handler setup is complete, leading to a NULL<br /> dereference.<br /> <br /> This error condition has been observed during system boot on Rb3Gen2.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: venus: Add a check for packet size after reading from shared memory<br /> <br /> Add a check to ensure that the packet size does not exceed the number of<br /> available words after reading the packet header from shared memory. This<br /> ensures that the size provided by the firmware is safe to process and<br /> prevent potential out-of-bounds memory access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()<br /> <br /> In the interrupt handler rain_interrupt(), the buffer full check on<br /> rain-&gt;buf_len is performed before acquiring rain-&gt;buf_lock. This<br /> creates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as<br /> rain-&gt;buf_len is concurrently accessed and modified in the work<br /> handler rain_irq_work_handler() under the same lock.<br /> <br /> Multiple interrupt invocations can race, with each reading buf_len<br /> before it becomes full and then proceeding. This can lead to both<br /> interrupts attempting to write to the buffer, incrementing buf_len<br /> beyond its capacity (DATA_SIZE) and causing a buffer overflow.<br /> <br /> Fix this bug by moving the spin_lock() to before the buffer full<br /> check. This ensures that the check and the subsequent buffer modification<br /> are performed atomically, preventing the race condition. An corresponding<br /> spin_unlock() is added to the overflow path to correctly release the<br /> lock.<br /> <br /> This possible bug was found by an experimental static analysis tool<br /> developed by our team.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: usbtv: Lock resolution while streaming<br /> <br /> When an program is streaming (ffplay) and another program (qv4l2)<br /> changes the TV standard from NTSC to PAL, the kernel crashes due to trying<br /> to copy to unmapped memory.<br /> <br /> Changing from NTSC to PAL increases the resolution in the usbtv struct,<br /> but the video plane buffer isn&amp;#39;t adjusted, so it overflows.<br /> <br /> [hverkuil: call vb2_is_busy instead of vb2_is_streaming]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: Revise gateway LWS calls to probe user read access<br /> <br /> We use load and stbys,e instructions to trigger memory reference<br /> interruptions without writing to memory. Because of the way read<br /> access support is implemented, read access interruptions are only<br /> triggered at privilege levels 2 and 3. The kernel and gateway<br /> page execute at privilege level 0, so this code never triggers<br /> a read access interruption. Thus, it is currently possible for<br /> user code to execute a LWS compare and swap operation at an<br /> address that is read protected at privilege level 3 (PRIV_USER).<br /> <br /> Fix this by probing read access rights at privilege level 3 and<br /> branching to lws_fault if access isn&amp;#39;t allowed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mt9m114: Fix deadlock in get_frame_interval/set_frame_interval<br /> <br /> Getting / Setting the frame interval using the V4L2 subdev pad ops<br /> get_frame_interval/set_frame_interval causes a deadlock, as the<br /> subdev state is locked in the [1] but also in the driver itself.<br /> <br /> In [2] it&amp;#39;s described that the caller is responsible to acquire and<br /> release the lock in this case. Therefore, acquiring the lock in the<br /> driver is wrong.<br /> <br /> Remove the lock acquisitions/releases from mt9m114_ifp_get_frame_interval()<br /> and mt9m114_ifp_set_frame_interval().<br /> <br /> [1] drivers/media/v4l2-core/v4l2-subdev.c - line 1129<br /> [2] Documentation/driver-api/media/v4l2-subdev.rst