Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: qup: jump out of the loop in case of timeout<br /> <br /> Original logic only sets the return value but doesn&amp;#39;t jump out of the<br /> loop if the bus is kept active by a client. This is not expected. A<br /> malicious or buggy i2c client can hang the kernel in this case and<br /> should be avoided. This is observed during a long time test with a<br /> PCA953x GPIO extender.<br /> <br /> Fix it by changing the logic to not only sets the return value, but also<br /> jumps out of the loop and return to the caller with -ETIMEDOUT.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: core: fix NULL dereference on unbind due to stale coupling data<br /> <br /> Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can<br /> lead to NULL pointer dereference when regulators are accessed post-unbind.<br /> <br /> This can happen during runtime PM or other regulator operations that rely<br /> on coupling metadata.<br /> <br /> For example, on ridesx4, unbinding the &amp;#39;reg-dummy&amp;#39; platform device triggers<br /> a panic in regulator_lock_recursive() due to stale coupling state.<br /> <br /> Ensure n_coupled is set to 0 to prevent access to invalid pointers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: fix potential out-of-bound write<br /> <br /> The buffer is set to 20 characters. If a caller write more characters,<br /> count is truncated to the max available space in "simple_write_to_buffer".<br /> To protect from OoB access, check that the input size fit into buffer and<br /> add a zero terminator after copy to the end of the copied data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "drm/gem-shmem: Use dma_buf from GEM object instance"<br /> <br /> This reverts commit 1a148af06000e545e714fe3210af3d77ff903c11.<br /> <br /> The dma_buf field in struct drm_gem_object is not stable over the<br /> object instance&amp;#39;s lifetime. The field becomes NULL when user space<br /> releases the final GEM handle on the buffer object. This resulted<br /> in a NULL-pointer deref.<br /> <br /> Workarounds in commit 5307dce878d4 ("drm/gem: Acquire references on<br /> GEM handles for framebuffers") and commit f6bfc9afc751 ("drm/framebuffer:<br /> Acquire internal references on GEM handles") only solved the problem<br /> partially. They especially don&amp;#39;t work for buffer objects without a DRM<br /> framebuffer associated.<br /> <br /> Hence, this revert to going back to using .import_attach-&gt;dmabuf.<br /> <br /> v3:<br /> - cc stable

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "drm/gem-dma: Use dma_buf from GEM object instance"<br /> <br /> This reverts commit e8afa1557f4f963c9a511bd2c6074a941c308685.<br /> <br /> The dma_buf field in struct drm_gem_object is not stable over the<br /> object instance&amp;#39;s lifetime. The field becomes NULL when user space<br /> releases the final GEM handle on the buffer object. This resulted<br /> in a NULL-pointer deref.<br /> <br /> Workarounds in commit 5307dce878d4 ("drm/gem: Acquire references on<br /> GEM handles for framebuffers") and commit f6bfc9afc751 ("drm/framebuffer:<br /> Acquire internal references on GEM handles") only solved the problem<br /> partially. They especially don&amp;#39;t work for buffer objects without a DRM<br /> framebuffer associated.<br /> <br /> Hence, this revert to going back to using .import_attach-&gt;dmabuf.<br /> <br /> v3:<br /> - cc stable

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "drm/gem-framebuffer: Use dma_buf from GEM object instance"<br /> <br /> This reverts commit cce16fcd7446dcff7480cd9d2b6417075ed81065.<br /> <br /> The dma_buf field in struct drm_gem_object is not stable over the<br /> object instance&amp;#39;s lifetime. The field becomes NULL when user space<br /> releases the final GEM handle on the buffer object. This resulted<br /> in a NULL-pointer deref.<br /> <br /> Workarounds in commit 5307dce878d4 ("drm/gem: Acquire references on<br /> GEM handles for framebuffers") and commit f6bfc9afc751 ("drm/framebuffer:<br /> Acquire internal references on GEM handles") only solved the problem<br /> partially. They especially don&amp;#39;t work for buffer objects without a DRM<br /> framebuffer associated.<br /> <br /> Hence, this revert to going back to using .import_attach-&gt;dmabuf.<br /> <br /> v3:<br /> - cc stable

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()<br /> <br /> `cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to change<br /> to different stacks along with the Shadow Call Stack if it is enabled.<br /> Those two stack changes cannot be done atomically and both functions<br /> can be interrupted by SErrors or Debug Exceptions which, though unlikely,<br /> is very much broken : if interrupted, we can end up with mismatched stacks<br /> and Shadow Call Stack leading to clobbered stacks.<br /> <br /> In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task,<br /> but x18 stills points to the old task&amp;#39;s SCS. When the interrupt handler<br /> tries to save the task&amp;#39;s SCS pointer, it will save the old task<br /> SCS pointer (x18) into the new task struct (pointed to by SP_EL0),<br /> clobbering it.<br /> <br /> In `call_on_irq_stack()`, it can happen when switching from the task stack<br /> to the IRQ stack and when switching back. In both cases, we can be<br /> interrupted when the SCS pointer points to the IRQ SCS, but SP points to<br /> the task stack. The nested interrupt handler pushes its return addresses<br /> on the IRQ SCS. It then detects that SP points to the task stack,<br /> calls `call_on_irq_stack()` and clobbers the task SCS pointer with<br /> the IRQ SCS pointer, which it will also use !<br /> <br /> This leads to tasks returning to addresses on the wrong SCS,<br /> or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACK<br /> or FPAC if enabled.<br /> <br /> This is possible on a default config, but unlikely.<br /> However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked and<br /> instead the GIC is responsible for filtering what interrupts the CPU<br /> should receive based on priority.<br /> Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPU<br /> even in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very*<br /> frequently depending on the system configuration and workload, leading<br /> to unpredictable kernel panics.<br /> <br /> Completely mask DAIF in `cpu_switch_to()` and restore it when returning.<br /> Do the same in `call_on_irq_stack()`, but restore and mask around<br /> the branch.<br /> Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistency<br /> of behaviour between all configurations.<br /> <br /> Introduce and use an assembly macro for saving and masking DAIF,<br /> as the existing one saves but only masks IF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode<br /> <br /> Andrei Lalaev reported a NULL pointer deref when a CAN device is<br /> restarted from Bus Off and the driver does not implement the struct<br /> can_priv::do_set_mode callback.<br /> <br /> There are 2 code path that call struct can_priv::do_set_mode:<br /> - directly by a manual restart from the user space, via<br /> can_changelink()<br /> - delayed automatic restart after bus off (deactivated by default)<br /> <br /> To prevent the NULL pointer deference, refuse a manual restart or<br /> configure the automatic restart delay in can_changelink() and report<br /> the error via extack to user space.<br /> <br /> As an additional safety measure let can_restart() return an error if<br /> can_priv::do_set_mode is not set instead of dereferencing it<br /> unchecked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix a null pointer dereference in ice_copy_and_init_pkg()<br /> <br /> Add check for the return value of devm_kmemdup()<br /> to prevent potential null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: reject invalid file types when reading inodes<br /> <br /> To prevent inodes with invalid file types from tripping through the vfs<br /> and causing malfunctions or assertion failures, add a missing sanity check<br /> when reading an inode from a block device. If the file type is not valid,<br /> treat it as a filesystem error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: No more self recovery<br /> <br /> When a node withdraws and it turns out that it is the only node that has<br /> the filesystem mounted, gfs2 currently tries to replay the local journal<br /> to bring the filesystem back into a consistent state. Not only is that<br /> a very bad idea, it has also never worked because gfs2_recover_func()<br /> will refuse to do anything during a withdraw.<br /> <br /> However, before even getting to this point, gfs2_recover_func()<br /> dereferences sdp-&gt;sd_jdesc-&gt;jd_inode. This was a use-after-free before<br /> commit 04133b607a78 ("gfs2: Prevent double iput for journal on error")<br /> and is a NULL pointer dereference since then.<br /> <br /> Simply get rid of self recovery to fix that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> [ceph] parse_longname(): strrchr() expects NUL-terminated string<br /> <br /> ... and parse_longname() is not guaranteed that. That&amp;#39;s the reason<br /> why it uses kmemdup_nul() to build the argument for kstrtou64();<br /> the problem is, kstrtou64() is not the only thing that need it.<br /> <br /> Just get a NUL-terminated copy of the entire thing and be done<br /> with that...