Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix race on unaccepted mptcp sockets<br /> <br /> When the listener socket owning the relevant request is closed,<br /> it frees the unaccepted subflows and that causes later deletion<br /> of the paired MPTCP sockets.<br /> <br /> The mptcp socket&amp;#39;s worker can run in the time interval between such delete<br /> operations. When that happens, any access to msk-&gt;first will cause an UaF<br /> access, as the subflow cleanup did not cleared such field in the mptcp<br /> socket.<br /> <br /> Address the issue explicitly traversing the listener socket accept<br /> queue at close time and performing the needed cleanup on the pending<br /> msk.<br /> <br /> Note that the locking is a bit tricky, as we need to acquire the msk<br /> socket lock, while still owning the subflow socket one.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix lockdep splat in in6_dump_addrs()<br /> <br /> As reported by syzbot, we should not use rcu_dereference()<br /> when rcu_read_lock() is not held.<br /> <br /> WARNING: suspicious RCU usage<br /> 5.19.0-rc2-syzkaller #0 Not tainted<br /> <br /> net/ipv6/addrconf.c:5175 suspicious rcu_dereference_check() usage!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 1 lock held by syz-executor326/3617:<br /> #0: ffffffff8d5848e8 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xae/0xc20 net/netlink/af_netlink.c:2223<br /> <br /> stack backtrace:<br /> CPU: 0 PID: 3617 Comm: syz-executor326 Not tainted 5.19.0-rc2-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> in6_dump_addrs+0x12d1/0x1790 net/ipv6/addrconf.c:5175<br /> inet6_dump_addr+0x9c1/0xb50 net/ipv6/addrconf.c:5300<br /> netlink_dump+0x541/0xc20 net/netlink/af_netlink.c:2275<br /> __netlink_dump_start+0x647/0x900 net/netlink/af_netlink.c:2380<br /> netlink_dump_start include/linux/netlink.h:245 [inline]<br /> rtnetlink_rcv_msg+0x73e/0xc90 net/core/rtnetlink.c:6046<br /> netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]<br /> netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345<br /> netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg+0xcf/0x120 net/socket.c:734<br /> ____sys_sendmsg+0x6eb/0x810 net/socket.c:2492<br /> ___sys_sendmsg+0xf3/0x170 net/socket.c:2546<br /> __sys_sendmsg net/socket.c:2575 [inline]<br /> __do_sys_sendmsg net/socket.c:2584 [inline]<br /> __se_sys_sendmsg net/socket.c:2582 [inline]<br /> __x64_sys_sendmsg+0x132/0x220 net/socket.c:2582<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: move bc link creation back to tipc_node_create<br /> <br /> Shuang Li reported a NULL pointer dereference crash:<br /> <br /> [] BUG: kernel NULL pointer dereference, address: 0000000000000068<br /> [] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc]<br /> [] Call Trace:<br /> [] <br /> [] tipc_bcast_rcv+0xa2/0x190 [tipc]<br /> [] tipc_node_bc_rcv+0x8b/0x200 [tipc]<br /> [] tipc_rcv+0x3af/0x5b0 [tipc]<br /> [] tipc_udp_recv+0xc7/0x1e0 [tipc]<br /> <br /> It was caused by the &amp;#39;l&amp;#39; passed into tipc_bcast_rcv() is NULL. When it<br /> creates a node in tipc_node_check_dest(), after inserting the new node<br /> into hashtable in tipc_node_create(), it creates the bc link. However,<br /> there is a gap between this insert and bc link creation, a bc packet<br /> may come in and get the node from the hashtable then try to dereference<br /> its bc link, which is NULL.<br /> <br /> This patch is to fix it by moving the bc link creation before inserting<br /> into the hashtable.<br /> <br /> Note that for a preliminary node becoming "real", the bc link creation<br /> should also be called before it&amp;#39;s rehashed, as we don&amp;#39;t create it for<br /> preliminary nodes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> linux/dim: Fix divide by 0 in RDMA DIM<br /> <br /> Fix a divide 0 error in rdma_dim_stats_compare() when prev-&gt;cpe_ratio ==<br /> 0.<br /> <br /> CallTrace:<br /> Hardware name: H3C R4900 G3/RS33M2C9S, BIOS 2.00.37P21 03/12/2020<br /> task: ffff880194b78000 task.stack: ffffc90006714000<br /> RIP: 0010:backport_rdma_dim+0x10e/0x240 [mlx_compat]<br /> RSP: 0018:ffff880c10e83ec0 EFLAGS: 00010202<br /> RAX: 0000000000002710 RBX: ffff88096cd7f780 RCX: 0000000000000064<br /> RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000001<br /> RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 000000001d7c6c09<br /> R13: ffff88096cd7f780 R14: ffff880b174fe800 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff880c10e80000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000a0965b00 CR3: 000000000200a003 CR4: 00000000007606e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ib_poll_handler+0x43/0x80 [ib_core]<br /> irq_poll_softirq+0xae/0x110<br /> __do_softirq+0xd1/0x28c<br /> irq_exit+0xde/0xf0<br /> do_IRQ+0x54/0xe0<br /> common_interrupt+0x8f/0x8f<br /> <br /> ? cpuidle_enter_state+0xd9/0x2a0<br /> ? cpuidle_enter_state+0xc7/0x2a0<br /> ? do_idle+0x170/0x1d0<br /> ? cpu_startup_entry+0x6f/0x80<br /> ? start_secondary+0x1b9/0x210<br /> ? secondary_startup_64+0xa5/0xb0<br /> Code: 0f 87 e1 00 00 00 8b 4c 24 14 44 8b 43 14 89 c8 4d 63 c8 44 29 c0 99 31 d0 29 d0 31 d2 48 98 48 8d 04 80 48 8d 04 80 48 c1 e0 02 f7 f1 48 83 f8 0a 0f 86 c1 00 00 00 44 39 c1 7f 10 48 89 df<br /> RIP: backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: ffff880c10e83ec0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen/netback: avoid entering xenvif_rx_next_skb() with an empty rx queue<br /> <br /> xenvif_rx_next_skb() is expecting the rx queue not being empty, but<br /> in case the loop in xenvif_rx_action() is doing multiple iterations,<br /> the availability of another skb in the rx queue is not being checked.<br /> <br /> This can lead to crashes:<br /> <br /> [40072.537261] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080<br /> [40072.537407] IP: xenvif_rx_skb+0x23/0x590 [xen_netback]<br /> [40072.537534] PGD 0 P4D 0<br /> [40072.537644] Oops: 0000 [#1] SMP NOPTI<br /> [40072.537749] CPU: 0 PID: 12505 Comm: v1-c40247-q2-gu Not tainted 4.12.14-122.121-default #1 SLE12-SP5<br /> [40072.537867] Hardware name: HP ProLiant DL580 Gen9/ProLiant DL580 Gen9, BIOS U17 11/23/2021<br /> [40072.537999] task: ffff880433b38100 task.stack: ffffc90043d40000<br /> [40072.538112] RIP: e030:xenvif_rx_skb+0x23/0x590 [xen_netback]<br /> [40072.538217] RSP: e02b:ffffc90043d43de0 EFLAGS: 00010246<br /> [40072.538319] RAX: 0000000000000000 RBX: ffffc90043cd7cd0 RCX: 00000000000000f7<br /> [40072.538430] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffc90043d43df8<br /> [40072.538531] RBP: 000000000000003f R08: 000077ff80000000 R09: 0000000000000008<br /> [40072.538644] R10: 0000000000007ff0 R11: 00000000000008f6 R12: ffffc90043ce2708<br /> [40072.538745] R13: 0000000000000000 R14: ffffc90043d43ed0 R15: ffff88043ea748c0<br /> [40072.538861] FS: 0000000000000000(0000) GS:ffff880484600000(0000) knlGS:0000000000000000<br /> [40072.538988] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [40072.539088] CR2: 0000000000000080 CR3: 0000000407ac8000 CR4: 0000000000040660<br /> [40072.539211] Call Trace:<br /> [40072.539319] xenvif_rx_action+0x71/0x90 [xen_netback]<br /> [40072.539429] xenvif_kthread_guest_rx+0x14a/0x29c [xen_netback]<br /> <br /> Fix that by stopping the loop in case the rx queue becomes empty.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: qcom: bam_dma: fix runtime PM underflow<br /> <br /> Commit dbad41e7bb5f ("dmaengine: qcom: bam_dma: check if the runtime pm enabled")<br /> caused unbalanced pm_runtime_get/put() calls when the bam is<br /> controlled remotely. This commit reverts it and just enables pm_runtime<br /> in all cases, the clk_* functions already just nop when the clock is NULL.<br /> <br /> Also clean up a bit by removing unnecessary bamclk null checks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> srcu: Tighten cleanup_srcu_struct() GP checks<br /> <br /> Currently, cleanup_srcu_struct() checks for a grace period in progress,<br /> but it does not check for a grace period that has not yet started but<br /> which might start at any time. Such a situation could result in a<br /> use-after-free bug, so this commit adds a check for a grace period that<br /> is needed but not yet started to cleanup_srcu_struct().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not needed anymore.<br /> <br /> Add missing of_node_put() in to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: piix4: Fix a memory leak in the EFCH MMIO support<br /> <br /> The recently added support for EFCH MMIO regions introduced a memory<br /> leak in that code path. The leak is caused by the fact that<br /> release_resource() merely removes the resource from the tree but does<br /> not free its memory. We need to call release_mem_region() instead,<br /> which does free the memory. As a nice side effect, this brings back<br /> some symmetry between the legacy and MMIO paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: qca8k: reset cpu port on MTU change<br /> <br /> It was discovered that the Documentation lacks of a fundamental detail<br /> on how to correctly change the MAX_FRAME_SIZE of the switch.<br /> <br /> In fact if the MAX_FRAME_SIZE is changed while the cpu port is on, the<br /> switch panics and cease to send any packet. This cause the mgmt ethernet<br /> system to not receive any packet (the slow fallback still works) and<br /> makes the device not reachable. To recover from this a switch reset is<br /> required.<br /> <br /> To correctly handle this, turn off the cpu ports before changing the<br /> MAX_FRAME_SIZE and turn on again after the value is applied.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fscache: Fix invalidation/lookup race<br /> <br /> If an NFS file is opened for writing and closed, fscache_invalidate() will<br /> be asked to invalidate the file - however, if the cookie is in the<br /> LOOKING_UP state (or the CREATING state), then request to invalidate<br /> doesn&amp;#39;t get recorded for fscache_cookie_state_machine() to do something<br /> with.<br /> <br /> Fix this by making __fscache_invalidate() set a flag if it sees the cookie<br /> is in the LOOKING_UP state to indicate that we need to go to invalidation.<br /> Note that this requires a count on the n_accesses counter for the state<br /> machine, which that will release when it&amp;#39;s done.<br /> <br /> fscache_cookie_state_machine() then shifts to the INVALIDATING state if it<br /> sees the flag.<br /> <br /> Without this, an nfs file can get corrupted if it gets modified locally and<br /> then read locally as the cache contents may not get updated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: meson: Fix refcount leak in meson_smp_prepare_cpus<br /> <br /> of_find_compatible_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> Add missing of_node_put() to avoid refcount leak.