Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet: fix memory leak in error case<br /> <br /> usbnet_write_cmd_async() mixed up which buffers<br /> need to be freed in which error case.<br /> <br /> v2: add Fixes tag<br /> v3: fix uninitialized buf pointer

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix insufficient bounds propagation from adjust_scalar_min_max_vals<br /> <br /> Kuee reported a corner case where the tnum becomes constant after the call<br /> to __reg_bound_offset(), but the register&amp;#39;s bounds are not, that is, its<br /> min bounds are still not equal to the register&amp;#39;s max bounds.<br /> <br /> This in turn allows to leak pointers through turning a pointer register as<br /> is into an unknown scalar via adjust_ptr_min_max_vals().<br /> <br /> Before:<br /> <br /> func#0 @0<br /> 0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))<br /> 0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0))<br /> 1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0))<br /> 2: (87) r3 = -r3 ; R3_w=scalar()<br /> 3: (87) r3 = -r3 ; R3_w=scalar()<br /> 4: (47) r3 |= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881)<br /> 5: (75) if r3 s&gt;= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767)<br /> 6: (95) exit<br /> <br /> from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0))<br /> 7: (d5) if r3 s