Vulnerabilities

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.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sysctl: Fix data races in proc_douintvec_minmax().<br /> <br /> A sysctl variable is accessed concurrently, and there is always a chance<br /> of data-race. So, all readers and writers need some basic protection to<br /> avoid load/store-tearing.<br /> <br /> This patch changes proc_douintvec_minmax() to use READ_ONCE() and<br /> WRITE_ONCE() internally to fix data-races on the sysctl side. For now,<br /> proc_douintvec_minmax() itself is tolerant to a data-race, but we still<br /> need to add annotations on the other subsystem&amp;#39;s side.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sysctl: Fix data races in proc_douintvec().<br /> <br /> A sysctl variable is accessed concurrently, and there is always a chance<br /> of data-race. So, all readers and writers need some basic protection to<br /> avoid load/store-tearing.<br /> <br /> This patch changes proc_douintvec() to use READ_ONCE() and WRITE_ONCE()<br /> internally to fix data-races on the sysctl side. For now, proc_douintvec()<br /> itself is tolerant to a data-race, but we still need to add annotations on<br /> the other subsystem&amp;#39;s side.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: dwc-qos: Disable split header for Tegra194<br /> <br /> There is a long-standing issue with the Synopsys DWC Ethernet driver<br /> for Tegra194 where random system crashes have been observed [0]. The<br /> problem occurs when the split header feature is enabled in the stmmac<br /> driver. In the bad case, a larger than expected buffer length is<br /> received and causes the calculation of the total buffer length to<br /> overflow. This results in a very large buffer length that causes the<br /> kernel to crash. Why this larger buffer length is received is not clear,<br /> however, the feedback from the NVIDIA design team is that the split<br /> header feature is not supported for Tegra194. Therefore, disable split<br /> header support for Tegra194 to prevent these random crashes from<br /> occurring.<br /> <br /> [0] https://lore.kernel.org/linux-tegra/b0b17697-f23e-8fa5-3757-604a86f3a095@nvidia.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima: Fix a potential integer overflow in ima_appraise_measurement<br /> <br /> When the ima-modsig is enabled, the rc passed to evm_verifyxattr() may be<br /> negative, which may cause the integer overflow problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: fix a possible refcount leak in intel_dp_add_mst_connector()<br /> <br /> If drm_connector_init fails, intel_connector_free will be called to take<br /> care of proper free. So it is necessary to drop the refcount of port<br /> before intel_connector_free.<br /> <br /> (cherry picked from commit cea9ed611e85d36a05db52b6457bf584b7d969e2)