Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pci: Fix get_phb_number() locking<br /> <br /> The recent change to get_phb_number() causes a DEBUG_ATOMIC_SLEEP<br /> warning on some systems:<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper<br /> preempt_count: 1, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> 1 lock held by swapper/1:<br /> #0: c157efb0 (hose_spinlock){+.+.}-{2:2}, at: pcibios_alloc_controller+0x64/0x220<br /> Preemption disabled at:<br /> [] 0x0<br /> CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0-yocto-standard+ #1<br /> Call Trace:<br /> [d101dc90] [c073b264] dump_stack_lvl+0x50/0x8c (unreliable)<br /> [d101dcb0] [c0093b70] __might_resched+0x258/0x2a8<br /> [d101dcd0] [c0d3e634] __mutex_lock+0x6c/0x6ec<br /> [d101dd50] [c0a84174] of_alias_get_id+0x50/0xf4<br /> [d101dd80] [c002ec78] pcibios_alloc_controller+0x1b8/0x220<br /> [d101ddd0] [c140c9dc] pmac_pci_init+0x198/0x784<br /> [d101de50] [c140852c] discover_phbs+0x30/0x4c<br /> [d101de60] [c0007fd4] do_one_initcall+0x94/0x344<br /> [d101ded0] [c1403b40] kernel_init_freeable+0x1a8/0x22c<br /> [d101df10] [c00086e0] kernel_init+0x34/0x160<br /> [d101df30] [c001b334] ret_from_kernel_thread+0x5c/0x64<br /> <br /> This is because pcibios_alloc_controller() holds hose_spinlock but<br /> of_alias_get_id() takes of_mutex which can sleep.<br /> <br /> The hose_spinlock protects the phb_bitmap, and also the hose_list, but<br /> it doesn&amp;#39;t need to be held while get_phb_number() calls the OF routines,<br /> because those are only looking up information in the device tree.<br /> <br /> So fix it by having get_phb_number() take the hose_spinlock itself, only<br /> where required, and then dropping the lock before returning.<br /> pcibios_alloc_controller() then needs to take the lock again before the<br /> list_add() but that&amp;#39;s safe, the order of the list is not important.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sunrpc: fix potential memory leaks in rpc_sysfs_xprt_state_change()<br /> <br /> The issue happens on some error handling paths. When the function<br /> fails to grab the object `xprt`, it simply returns 0, forgetting to<br /> decrease the reference count of another object `xps`, which is<br /> increased by rpc_sysfs_xprt_kobj_get_xprt_switch(), causing refcount<br /> leaks. Also, the function forgets to check whether `xps` is valid<br /> before using it, which may result in NULL-dereferencing issues.<br /> <br /> Fix it by adding proper error handling code when either `xprt` or<br /> `xps` is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: mv88e6060: prevent crash on an unused port<br /> <br /> If the port isn&amp;#39;t a CPU port nor a user port, &amp;#39;cpu_dp&amp;#39;<br /> is a null pointer and a crash happened on dereferencing<br /> it in mv88e6060_setup_port():<br /> <br /> [ 9.575872] Unable to handle kernel NULL pointer dereference at virtual address 00000014<br /> ...<br /> [ 9.942216] mv88e6060_setup from dsa_register_switch+0x814/0xe84<br /> [ 9.948616] dsa_register_switch from mdio_probe+0x2c/0x54<br /> [ 9.954433] mdio_probe from really_probe.part.0+0x98/0x2a0<br /> [ 9.960375] really_probe.part.0 from driver_probe_device+0x30/0x10c<br /> [ 9.967029] driver_probe_device from __device_attach_driver+0xb8/0x13c<br /> [ 9.973946] __device_attach_driver from bus_for_each_drv+0x90/0xe0<br /> [ 9.980509] bus_for_each_drv from __device_attach+0x110/0x184<br /> [ 9.986632] __device_attach from bus_probe_device+0x8c/0x94<br /> [ 9.992577] bus_probe_device from deferred_probe_work_func+0x78/0xa8<br /> [ 9.999311] deferred_probe_work_func from process_one_work+0x290/0x73c<br /> [ 10.006292] process_one_work from worker_thread+0x30/0x4b8<br /> [ 10.012155] worker_thread from kthread+0xd4/0x10c<br /> [ 10.017238] kthread from ret_from_fork+0x14/0x3c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: possible module reference underflow in error path<br /> <br /> dst-&gt;ops is set on when nft_expr_clone() fails, but module refcount has<br /> not been bumped yet, therefore nft_expr_destroy() leads to module<br /> reference underflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: DPCM: Don&amp;#39;t pick up BE without substream<br /> <br /> When DPCM tries to add valid BE connections at dpcm_add_paths(), it<br /> doesn&amp;#39;t check whether the picked BE actually supports for the given<br /> stream direction. Due to that, when an asymmetric BE stream is<br /> present, it picks up wrongly and this may result in a NULL dereference<br /> at a later point where the code assumes the existence of a<br /> corresponding BE substream.<br /> <br /> This patch adds the check for the presence of the substream for the<br /> target BE for avoiding the problem above.<br /> <br /> Note that we have already some fix for non-existing BE substream at<br /> commit 6246f283d5e0 ("ASoC: dpcm: skip missing substream while<br /> applying symmetry"). But the code path we&amp;#39;ve hit recently is rather<br /> happening before the previous fix. So this patch tries to fix at<br /> picking up a BE instead of parsing BE lists.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: Intel: hda: Fix potential buffer overflow by snprintf()<br /> <br /> snprintf() returns the would-be-filled size when the string overflows<br /> the given buffer size, hence using this value may result in the buffer<br /> overflow (although it&amp;#39;s unrealistic).<br /> <br /> This patch replaces with a safer version, scnprintf() for papering<br /> over such a potential issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: debug: Fix potential buffer overflow by snprintf()<br /> <br /> snprintf() returns the would-be-filled size when the string overflows<br /> the given buffer size, hence using this value may result in the buffer<br /> overflow (although it&amp;#39;s unrealistic).<br /> <br /> This patch replaces with a safer version, scnprintf() for papering<br /> over such a potential issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: avs: Fix potential buffer overflow by snprintf()<br /> <br /> snprintf() returns the would-be-filled size when the string overflows<br /> the given buffer size, hence using this value may result in a buffer<br /> overflow (although it&amp;#39;s unrealistic).<br /> <br /> This patch replaces it with a safer version, scnprintf() for papering<br /> over such a potential issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix potential refcount leak in ndisc_router_discovery()<br /> <br /> The issue happens on specific paths in the function. After both the<br /> object `rt` and `neigh` are grabbed successfully, when `lifetime` is<br /> nonzero but the metric needs change, the function just deletes the<br /> route and set `rt` to NULL. Then, it may try grabbing `rt` and `neigh`<br /> again if above conditions hold. The function simply overwrite `neigh`<br /> if succeeds or returns if fails, without decreasing the reference<br /> count of previous `neigh`. This may result in memory leaks.<br /> <br /> Fix it by decrementing the reference count of `neigh` in place.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: start MHI channel after endpoit creation<br /> <br /> MHI channel may generates event/interrupt right after enabling.<br /> It may leads to 2 race conditions issues.<br /> <br /> 1)<br /> Such event may be dropped by qcom_mhi_qrtr_dl_callback() at check:<br /> <br /> if (!qdev || mhi_res-&gt;transaction_status)<br /> return;<br /> <br /> Because dev_set_drvdata(&amp;mhi_dev-&gt;dev, qdev) may be not performed at<br /> this moment. In this situation qrtr-ns will be unable to enumerate<br /> services in device.<br /> ---------------------------------------------------------------<br /> <br /> 2)<br /> Such event may come at the moment after dev_set_drvdata() and<br /> before qrtr_endpoint_register(). In this case kernel will panic with<br /> accessing wrong pointer at qcom_mhi_qrtr_dl_callback():<br /> <br /> rc = qrtr_endpoint_post(&amp;qdev-&gt;ep, mhi_res-&gt;buf_addr,<br /> mhi_res-&gt;bytes_xferd);<br /> <br /> Because endpoint is not created yet.<br /> --------------------------------------------------------------<br /> So move mhi_prepare_for_transfer_autoqueue after endpoint creation<br /> to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sun4i: dsi: Prevent underflow when computing packet sizes<br /> <br /> Currently, the packet overhead is subtracted using unsigned arithmetic.<br /> With a short sync pulse, this could underflow and wrap around to near<br /> the maximal u16 value. Fix this by using signed subtraction. The call to<br /> max() will correctly handle any negative numbers that are produced.<br /> <br /> Apply the same fix to the other timings, even though those subtractions<br /> are less likely to underflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/ttm: don&amp;#39;t leak the ccs state<br /> <br /> The kernel only manages the ccs state with lmem-only objects, however<br /> the kernel should still take care not to leak the CCS state from the<br /> previous user.<br /> <br /> (cherry picked from commit 353819d85f87be46aeb9c1dd929d445a006fc6ec)