Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD<br /> <br /> [Changes from V1:<br /> - Use a default branch in the switch statement to initialize `val&amp;#39;.]<br /> <br /> GCC warns that `val&amp;#39; may be used uninitialized in the<br /> BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as:<br /> <br /> [...]<br /> unsigned long long val; \<br /> [...] \<br /> switch (__CORE_RELO(s, field, BYTE_SIZE)) { \<br /> case 1: val = *(const unsigned char *)p; break; \<br /> case 2: val = *(const unsigned short *)p; break; \<br /> case 4: val = *(const unsigned int *)p; break; \<br /> case 8: val = *(const unsigned long long *)p; break; \<br /> } \<br /> [...]<br /> val; \<br /> } \<br /> <br /> This patch adds a default entry in the switch statement that sets<br /> `val&amp;#39; to zero in order to avoid the warning, and random values to be<br /> used in case __builtin_preserve_field_info returns unexpected values<br /> for BPF_FIELD_BYTE_SIZE.<br /> <br /> Tested in bpf-next master.<br /> No regressions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-frontends: tda10048: Fix integer overflow<br /> <br /> state-&gt;xtal_hz can be up to 16M, so it can overflow a 32 bit integer<br /> when multiplied by pll_mfactor.<br /> <br /> Create a new 64 bit variable to hold the calculations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: mv88e6xxx: Correct check for empty list<br /> <br /> Since commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO<br /> busses") mv88e6xxx_default_mdio_bus() has checked that the<br /> return value of list_first_entry() is non-NULL.<br /> <br /> This appears to be intended to guard against the list chip-&gt;mdios being<br /> empty. However, it is not the correct check as the implementation of<br /> list_first_entry is not designed to return NULL for empty lists.<br /> <br /> Instead, use list_first_entry_or_null() which does return NULL if the<br /> list is empty.<br /> <br /> Flagged by Smatch.<br /> Compile tested only.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: replace skb_put with skb_put_zero<br /> <br /> Avoid potentially reusing uninitialized data

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc<br /> <br /> Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.<br /> V2: To really improve the handling we would actually<br /> need to have a separate value of 0xffffffff.(Christian)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal/drivers/mediatek/lvts_thermal: Check NULL ptr on lvts_data<br /> <br /> Verify that lvts_data is not NULL before using it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Add outer runtime_pm protection to xe_live_ktest@xe_dma_buf<br /> <br /> Any kunit doing any memory access should get their own runtime_pm<br /> outer references since they don&amp;#39;t use the standard driver API<br /> entries. In special this dma_buf from the same driver.<br /> <br /> Found by pre-merge CI on adding WARN calls for unprotected<br /> inner callers:<br /> <br /> [318.639739] # xe_dma_buf_kunit: running xe_test_dmabuf_import_same_driver<br /> [318.639957] ------------[ cut here ]------------<br /> [318.639967] xe 0000:4d:00.0: Missing outer runtime PM protection<br /> [318.640049] WARNING: CPU: 117 PID: 3832 at drivers/gpu/drm/xe/xe_pm.c:533 xe_pm_runtime_get_noresume+0x48/0x60 [xe]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: don&amp;#39;t misleadingly warn during thaw operations<br /> <br /> The block device may have been frozen before it was claimed by a<br /> filesystem. Concurrently another process might try to mount that<br /> frozen block device and has temporarily claimed the block device for<br /> that purpose causing a concurrent fs_bdev_thaw() to end up here. The<br /> mounter is already about to abort mounting because they still saw an<br /> elevanted bdev-&gt;bd_fsfreeze_count so get_bdev_super() will return<br /> NULL in that case.<br /> <br /> For example, P1 calls dm_suspend() which calls into bdev_freeze() before<br /> the block device has been claimed by the filesystem. This brings<br /> bdev-&gt;bd_fsfreeze_count to 1 and no call into fs_bdev_freeze() is<br /> required.<br /> <br /> Now P2 tries to mount that frozen block device. It claims it and checks<br /> bdev-&gt;bd_fsfreeze_count. As it&amp;#39;s elevated it aborts mounting.<br /> <br /> In the meantime P3 called dm_resume(). P3 sees that the block device is<br /> already claimed by a filesystem and calls into fs_bdev_thaw().<br /> <br /> P3 takes a passive reference and realizes that the filesystem isn&amp;#39;t<br /> ready yet. P3 puts itself to sleep to wait for the filesystem to become<br /> ready.<br /> <br /> P2 now puts the last active reference to the filesystem and marks it as<br /> dying. P3 gets woken, sees that the filesystem is dying and<br /> get_bdev_super() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: txgbe: remove separate irq request for MSI and INTx<br /> <br /> When using MSI or INTx interrupts, request_irq() for pdev-&gt;irq will<br /> conflict with request_threaded_irq() for txgbe-&gt;misc.irq, to cause<br /> system crash. So remove txgbe_request_irq() for MSI/INTx case, and<br /> rename txgbe_request_msix_irqs() since it only request for queue irqs.<br /> <br /> Add wx-&gt;misc_irq_domain to determine whether the driver creates an IRQ<br /> domain and threaded request the IRQs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: mark bpf_dummy_struct_ops.test_1 parameter as nullable<br /> <br /> Test case dummy_st_ops/dummy_init_ret_value passes NULL as the first<br /> parameter of the test_1() function. Mark this parameter as nullable to<br /> make verifier aware of such possibility.<br /> Otherwise, NULL check in the test_1() code:<br /> <br /> SEC("struct_ops/test_1")<br /> int BPF_PROG(test_1, struct bpf_dummy_ops_state *state)<br /> {<br /> if (!state)<br /> return ...;<br /> <br /> ... access state ...<br /> }<br /> <br /> Might be removed by verifier, thus triggering NULL pointer dereference<br /> under certain conditions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/core: Implement a limit on UMAD receive List<br /> <br /> The existing behavior of ib_umad, which maintains received MAD<br /> packets in an unbounded list, poses a risk of uncontrolled growth.<br /> As user-space applications extract packets from this list, the rate<br /> of extraction may not match the rate of incoming packets, leading<br /> to potential list overflow.<br /> <br /> To address this, we introduce a limit to the size of the list. After<br /> considering typical scenarios, such as OpenSM processing, which can<br /> handle approximately 100k packets per second, and the 1-second retry<br /> timeout for most packets, we set the list size limit to 200k. Packets<br /> received beyond this limit are dropped, assuming they are likely timed<br /> out by the time they are handled by user-space.<br /> <br /> Notably, packets queued on the receive list due to reasons like<br /> timed-out sends are preserved even when the list is full.