Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: m_can: m_can_{read_fifo,echo_tx_event}(): shift timestamp to full 32 bits<br /> <br /> In commit 1be37d3b0414 ("can: m_can: fix periph RX path: use<br /> rx-offload to ensure skbs are sent from softirq context") the RX path<br /> for peripheral devices was switched to RX-offload.<br /> <br /> Received CAN frames are pushed to RX-offload together with a<br /> timestamp. RX-offload is designed to handle overflows of the timestamp<br /> correctly, if 32 bit timestamps are provided.<br /> <br /> The timestamps of m_can core are only 16 bits wide. So this patch<br /> shifts them to full 32 bit before passing them to RX-offload.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> icmp: Fix data-races around sysctl.<br /> <br /> While reading icmp sysctl variables, they can be changed concurrently.<br /> So, we need to add READ_ONCE() to avoid data-races.