Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: don&amp;#39;t leak snap_rwsem in handle_cap_grant<br /> <br /> When handle_cap_grant is called on an IMPORT op, then the snap_rwsem is<br /> held and the function is expected to release it before returning. It<br /> currently fails to do that in all cases which could lead to a deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: Fix mcam entry resource leak<br /> <br /> The teardown sequence in FLR handler returns if no NIX LF<br /> is attached to PF/VF because it indicates that graceful<br /> shutdown of resources already happened. But there is a<br /> chance of all allocated MCAM entries not being freed by<br /> PF/VF. Hence free mcam entries even in case of detached LF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: nomadik: Fix refcount leak in nmk_pinctrl_dt_subnode_to_map<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak."

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bgmac: Fix a BUG triggered by wrong bytes_compl<br /> <br /> On one of our machines we got:<br /> <br /> kernel BUG at lib/dynamic_queue_limits.c:27!<br /> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM<br /> CPU: 0 PID: 1166 Comm: irq/41-bgmac Tainted: G W O 4.14.275-rt132 #1<br /> Hardware name: BRCM XGS iProc<br /> task: ee3415c0 task.stack: ee32a000<br /> PC is at dql_completed+0x168/0x178<br /> LR is at bgmac_poll+0x18c/0x6d8<br /> pc : [] lr : [] psr: 800a0313<br /> sp : ee32be14 ip : 000005ea fp : 00000bd4<br /> r10: ee558500 r9 : c0116298 r8 : 00000002<br /> r7 : 00000000 r6 : ef128810 r5 : 01993267 r4 : 01993851<br /> r3 : ee558000 r2 : 000070e1 r1 : 00000bd4 r0 : ee52c180<br /> Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none<br /> Control: 12c5387d Table: 8e88c04a DAC: 00000051<br /> Process irq/41-bgmac (pid: 1166, stack limit = 0xee32a210)<br /> Stack: (0xee32be14 to 0xee32c000)<br /> be00: ee558520 ee52c100 ef128810<br /> be20: 00000000 00000002 c0116298 c04b5a18 00000000 c0a0c8c4 c0951780 00000040<br /> be40: c0701780 ee558500 ee55d520 ef05b340 ef6f9780 ee558520 00000001 00000040<br /> be60: ffffe000 c0a56878 ef6fa040 c0952040 0000012c c0528744 ef6f97b0 fffcfb6a<br /> be80: c0a04104 2eda8000 c0a0c4ec c0a0d368 ee32bf44 c0153534 ee32be98 ee32be98<br /> bea0: ee32bea0 ee32bea0 ee32bea8 ee32bea8 00000000 c01462e4 ffffe000 ef6f22a8<br /> bec0: ffffe000 00000008 ee32bee4 c0147430 ffffe000 c094a2a8 00000003 ffffe000<br /> bee0: c0a54528 00208040 0000000c c0a0c8c4 c0a65980 c0124d3c 00000008 ee558520<br /> bf00: c094a23c c0a02080 00000000 c07a9910 ef136970 ef136970 ee30a440 ef136900<br /> bf20: ee30a440 00000001 ef136900 ee30a440 c016d990 00000000 c0108db0 c012500c<br /> bf40: ef136900 c016da14 ee30a464 ffffe000 00000001 c016dd14 00000000 c016db28<br /> bf60: ffffe000 ee21a080 ee30a400 00000000 ee32a000 ee30a440 c016dbfc ee25fd70<br /> bf80: ee21a09c c013edcc ee32a000 ee30a400 c013ec7c 00000000 00000000 00000000<br /> bfa0: 00000000 00000000 00000000 c0108470 00000000 00000000 00000000 00000000<br /> bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br /> bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000<br /> [] (dql_completed) from [] (bgmac_poll+0x18c/0x6d8)<br /> [] (bgmac_poll) from [] (net_rx_action+0x1c4/0x494)<br /> [] (net_rx_action) from [] (do_current_softirqs+0x1ec/0x43c)<br /> [] (do_current_softirqs) from [] (__local_bh_enable+0x80/0x98)<br /> [] (__local_bh_enable) from [] (irq_forced_thread_fn+0x84/0x98)<br /> [] (irq_forced_thread_fn) from [] (irq_thread+0x118/0x1c0)<br /> [] (irq_thread) from [] (kthread+0x150/0x158)<br /> [] (kthread) from [] (ret_from_fork+0x14/0x24)<br /> Code: a83f15e0 0200001a 0630a0e1 c3ffffea (f201f0e7)<br /> <br /> The issue seems similar to commit 90b3b339364c ("net: hisilicon: Fix a BUG<br /> trigered by wrong bytes_compl") and potentially introduced by commit<br /> b38c83dd0866 ("bgmac: simplify tx ring index handling").<br /> <br /> If there is an RX interrupt between setting ring-&gt;end<br /> and netdev_sent_queue() we can hit the BUG_ON as bgmac_dma_tx_free()<br /> can miscalculate the queue size while called from bgmac_poll().<br /> <br /> The machine which triggered the BUG runs a v4.14 RT kernel - but the issue<br /> seems present in mainline too.

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.