Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bonding: fix use-after-free after 802.3ad slave unbind<br /> <br /> commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection"),<br /> resolve case, when there is several aggregation groups in the same bond.<br /> bond_3ad_unbind_slave will invalidate (clear) aggregator when<br /> __agg_active_ports return zero. So, ad_clear_agg can be executed even, when<br /> num_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for,<br /> previously cleared aggregator. NOTE: at this time bond_3ad_unbind_slave<br /> will not update slave ports list, because lag_ports==NULL. So, here we<br /> got slave ports, pointing to freed aggregator memory.<br /> <br /> Fix with checking actual number of ports in group (as was before<br /> commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection") ),<br /> before ad_clear_agg().<br /> <br /> The KASAN logs are as follows:<br /> <br /> [ 767.617392] ==================================================================<br /> [ 767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470<br /> [ 767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767<br /> [ 767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G O 5.15.11 #15<br /> [ 767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT)<br /> [ 767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler<br /> [ 767.666468] Call trace:<br /> [ 767.668930] dump_backtrace+0x0/0x2d0<br /> [ 767.672625] show_stack+0x24/0x30<br /> [ 767.675965] dump_stack_lvl+0x68/0x84<br /> [ 767.679659] print_address_description.constprop.0+0x74/0x2b8<br /> [ 767.685451] kasan_report+0x1f0/0x260<br /> [ 767.689148] __asan_load2+0x94/0xd0<br /> [ 767.692667] bond_3ad_state_machine_handler+0x13dc/0x1470

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM / devfreq: exynos-ppmu: Fix refcount leak in of_get_devfreq_events<br /> <br /> of_get_child_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> This function only calls of_node_put() in normal path,<br /> missing it in error paths.<br /> Add missing of_node_put() to avoid refcount leak.

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 /> 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.