Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier<br /> <br /> If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and<br /> txbuf_len are uninitialized. This commit stops to print uninitialized<br /> value and misleading/false data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: Break an object reference loop<br /> <br /> When remaining resources are being cleaned up on driver close,<br /> outstanding VM mappings may result in resources being leaked, due<br /> to an object reference loop, as shown below, with each object (or<br /> set of objects) referencing the object below it:<br /> <br /> PVR GEM Object<br /> GPU scheduler "finished" fence<br /> GPU scheduler “scheduled” fence<br /> PVR driver “done” fence<br /> PVR Context<br /> PVR VM Context<br /> PVR VM Mappings<br /> PVR GEM Object<br /> <br /> The reference that the PVR VM Context has on the VM mappings is a<br /> soft one, in the sense that the freeing of outstanding VM mappings<br /> is done as part of VM context destruction; no reference counts are<br /> involved, as is the case for all the other references in the loop.<br /> <br /> To break the reference loop during cleanup, free the outstanding<br /> VM mappings before destroying the PVR Context associated with the<br /> VM context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm: Lock TPM chip in tpm_pm_suspend() first<br /> <br /> Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy<br /> according, as this leaves window for tpm_hwrng_read() to be called while<br /> the operation is in progress. The recent bug report gives also evidence of<br /> this behaviour.<br /> <br /> Aadress this by locking the TPM chip before checking any chip-&gt;flags both<br /> in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED<br /> check inside tpm_get_random() so that it will be always checked only when<br /> the lock is reserved.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL<br /> <br /> Upon failure all locks need to be dropped before returning to the user.<br /> <br /> (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix possible exec queue leak in exec IOCTL<br /> <br /> In a couple of places after an exec queue is looked up the exec IOCTL<br /> returns on input errors without dropping the exec queue ref. Fix this<br /> ensuring the exec queue ref is dropped on input error.<br /> <br /> (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: don&amp;#39;t leak a link on AP removal<br /> <br /> Release the link mapping resource in AP removal. This impacted devices<br /> that do not support the MLD API (9260 and down).<br /> On those devices, we couldn&amp;#39;t start the AP again after the AP has been<br /> already started and stopped.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ar0521: don&amp;#39;t overflow when checking PLL values<br /> <br /> The PLL checks are comparing 64 bit integers with 32 bit<br /> ones, as reported by Coverity. Depending on the values of<br /> the variables, this may underflow.<br /> <br /> Fix it ensuring that both sides of the expression are u64.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_net: Add hash_key_length check<br /> <br /> Add hash_key_length check in virtnet_probe() to avoid possible out of<br /> bound errors when setting/reading the hash key.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: fix race condition by adding filter&amp;#39;s intermediate sync state<br /> <br /> Fix a race condition in the i40e driver that leads to MAC/VLAN filters<br /> becoming corrupted and leaking. Address the issue that occurs under<br /> heavy load when multiple threads are concurrently modifying MAC/VLAN<br /> filters by setting mac and port VLAN.<br /> <br /> 1. Thread T0 allocates a filter in i40e_add_filter() within<br /> i40e_ndo_set_vf_port_vlan().<br /> 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within<br /> i40e_ndo_set_vf_mac().<br /> 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which<br /> refers to the already freed filter memory, causing corruption.<br /> <br /> Reproduction steps:<br /> 1. Spawn multiple VFs.<br /> 2. Apply a concurrent heavy load by running parallel operations to change<br /> MAC addresses on the VFs and change port VLANs on the host.<br /> 3. Observe errors in dmesg:<br /> "Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX,<br /> please set promiscuous on manually for VF XX".<br /> <br /> Exact code for stable reproduction Intel can&amp;#39;t open-source now.<br /> <br /> The fix involves implementing a new intermediate filter state,<br /> I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list.<br /> These filters cannot be deleted from the hash list directly but<br /> must be removed using the full process.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mgb4: protect driver against spectre<br /> <br /> Frequency range is set from sysfs via frequency_range_store(),<br /> being vulnerable to spectre, as reported by smatch:<br /> <br /> drivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue &amp;#39;cmt_vals_in&amp;#39; [r]<br /> drivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. &amp;#39;reg_set&amp;#39;<br /> <br /> Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix idpf_vc_core_init error path<br /> <br /> In an event where the platform running the device control plane<br /> is rebooted, reset is detected on the driver. It releases<br /> all the resources and waits for the reset to complete. Once the<br /> reset is done, it tries to build the resources back. At this<br /> time if the device control plane is not yet started, then<br /> the driver timeouts on the virtchnl message and retries to<br /> establish the mailbox again.<br /> <br /> In the retry flow, mailbox is deinitialized but the mailbox<br /> workqueue is still alive and polling for the mailbox message.<br /> This results in accessing the released control queue leading to<br /> null-ptr-deref. Fix it by unrolling the work queue cancellation<br /> and mailbox deinitialization in the reverse order which they got<br /> initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create<br /> <br /> Commit b035f5a6d852 ("mm: slab: reduce the kmalloc() minimum alignment<br /> if DMA bouncing possible") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64.<br /> However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16.<br /> This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16],<br /> resulting in kmem_buckets_create() attempting to create a kmem_cache for<br /> size 16 twice. This duplication triggers warnings on boot:<br /> <br /> [ 2.325108] ------------[ cut here ]------------<br /> [ 2.325135] kmem_cache of name &amp;#39;memdup_user-16&amp;#39; already exists<br /> [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0<br /> [ 2.327957] Modules linked in:<br /> [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12<br /> [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024<br /> [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0<br /> [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0<br /> [ 2.328942] sp : ffff800083d6fc50<br /> [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598<br /> [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000<br /> [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388<br /> [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030<br /> [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120<br /> [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000<br /> [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000<br /> [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 2.329291] Call trace:<br /> [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0<br /> [ 2.329499] kmem_buckets_create+0xfc/0x320<br /> [ 2.329526] init_user_buckets+0x34/0x78<br /> [ 2.329540] do_one_initcall+0x64/0x3c8<br /> [ 2.329550] kernel_init_freeable+0x26c/0x578<br /> [ 2.329562] kernel_init+0x3c/0x258<br /> [ 2.329574] ret_from_fork+0x10/0x20<br /> [ 2.329698] ---[ end trace 0000000000000000 ]---<br /> <br /> [ 2.403704] ------------[ cut here ]------------<br /> [ 2.404716] kmem_cache of name &amp;#39;msg_msg-16&amp;#39; already exists<br /> [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0<br /> [ 2.404842] Modules linked in:<br /> [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12<br /> [ 2.405026] Tainted: [W]=WARN<br /> [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024<br /> [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0<br /> [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0<br /> [ 2.405111] sp : ffff800083d6fc50<br /> [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598<br /> [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000<br /> [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388<br /> [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030<br /> [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120<br /> [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000<br /> [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000<br /> [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 2.405287] Call trace:<br /> [ 2<br /> ---truncated---