Vulnerabilities

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 /> net: appletalk: Fix use-after-free in AARP proxy probe<br /> <br /> The AARP proxy‐probe routine (aarp_proxy_probe_network) sends a probe,<br /> releases the aarp_lock, sleeps, then re-acquires the lock. During that<br /> window an expire timer thread (__aarp_expire_timer) can remove and<br /> kfree() the same entry, leading to a use-after-free.<br /> <br /> race condition:<br /> <br /> cpu 0 | cpu 1<br /> atalk_sendmsg() | atif_proxy_probe_device()<br /> aarp_send_ddp() | aarp_proxy_probe_network()<br /> mod_timer() | lock(aarp_lock) // LOCK!!<br /> timeout around 200ms | alloc(aarp_entry)<br /> and then call | proxies[hash] = aarp_entry<br /> aarp_expire_timeout() | aarp_send_probe()<br /> | unlock(aarp_lock) // UNLOCK!!<br /> lock(aarp_lock) // LOCK!! | msleep(100);<br /> __aarp_expire_timer(&amp;proxies[ct]) |<br /> free(aarp_entry) |<br /> unlock(aarp_lock) // UNLOCK!! |<br /> | lock(aarp_lock) // LOCK!!<br /> | UAF aarp_entry !!<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in aarp_proxy_probe_network+0x560/0x630 net/appletalk/aarp.c:493<br /> Read of size 4 at addr ffff8880123aa360 by task repro/13278<br /> <br /> CPU: 3 UID: 0 PID: 13278 Comm: repro Not tainted 6.15.2 #3 PREEMPT(full)<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:408 [inline]<br /> print_report+0xc1/0x630 mm/kasan/report.c:521<br /> kasan_report+0xca/0x100 mm/kasan/report.c:634<br /> aarp_proxy_probe_network+0x560/0x630 net/appletalk/aarp.c:493<br /> atif_proxy_probe_device net/appletalk/ddp.c:332 [inline]<br /> atif_ioctl+0xb58/0x16c0 net/appletalk/ddp.c:857<br /> atalk_ioctl+0x198/0x2f0 net/appletalk/ddp.c:1818<br /> sock_do_ioctl+0xdc/0x260 net/socket.c:1190<br /> sock_ioctl+0x239/0x6a0 net/socket.c:1311<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:906 [inline]<br /> __se_sys_ioctl fs/ioctl.c:892 [inline]<br /> __x64_sys_ioctl+0x194/0x200 fs/ioctl.c:892<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcb/0x250 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> Allocated:<br /> aarp_alloc net/appletalk/aarp.c:382 [inline]<br /> aarp_proxy_probe_network+0xd8/0x630 net/appletalk/aarp.c:468<br /> atif_proxy_probe_device net/appletalk/ddp.c:332 [inline]<br /> atif_ioctl+0xb58/0x16c0 net/appletalk/ddp.c:857<br /> atalk_ioctl+0x198/0x2f0 net/appletalk/ddp.c:1818<br /> <br /> Freed:<br /> kfree+0x148/0x4d0 mm/slub.c:4841<br /> __aarp_expire net/appletalk/aarp.c:90 [inline]<br /> __aarp_expire_timer net/appletalk/aarp.c:261 [inline]<br /> aarp_expire_timeout+0x480/0x6e0 net/appletalk/aarp.c:317<br /> <br /> The buggy address belongs to the object at ffff8880123aa300<br /> which belongs to the cache kmalloc-192 of size 192<br /> The buggy address is located 96 bytes inside of<br /> freed 192-byte region [ffff8880123aa300, ffff8880123aa3c0)<br /> <br /> Memory state around the buggy address:<br /> ffff8880123aa200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff8880123aa280: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc<br /> &gt;ffff8880123aa300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ^<br /> ffff8880123aa380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc<br /> ffff8880123aa400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ==================================================================

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: alienware-wmi-wmax: Fix `dmi_system_id` array<br /> <br /> Add missing empty member to `awcc_dmi_table`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: mt8365-dai-i2s: pass correct size to mt8365_dai_set_priv<br /> <br /> Given mt8365_dai_set_priv allocate priv_size space to copy priv_data which<br /> means we should pass mt8365_i2s_priv[i] or "struct mtk_afe_i2s_priv"<br /> instead of afe_priv which has the size of "struct mt8365_afe_private".<br /> <br /> Otherwise the KASAN complains about.<br /> <br /> [ 59.389765] BUG: KASAN: global-out-of-bounds in mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm]<br /> ...<br /> [ 59.394789] Call trace:<br /> [ 59.395167] dump_backtrace+0xa0/0x128<br /> [ 59.395733] show_stack+0x20/0x38<br /> [ 59.396238] dump_stack_lvl+0xe8/0x148<br /> [ 59.396806] print_report+0x37c/0x5e0<br /> [ 59.397358] kasan_report+0xac/0xf8<br /> [ 59.397885] kasan_check_range+0xe8/0x190<br /> [ 59.398485] asan_memcpy+0x3c/0x98<br /> [ 59.399022] mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm]<br /> [ 59.399928] mt8365_dai_i2s_register+0x1e8/0x2b0 [snd_soc_mt8365_pcm]<br /> [ 59.400893] mt8365_afe_pcm_dev_probe+0x4d0/0xdf0 [snd_soc_mt8365_pcm]<br /> [ 59.401873] platform_probe+0xcc/0x228<br /> [ 59.402442] really_probe+0x340/0x9e8<br /> [ 59.402992] driver_probe_device+0x16c/0x3f8<br /> [ 59.403638] driver_probe_device+0x64/0x1d8<br /> [ 59.404256] driver_attach+0x1dc/0x4c8<br /> [ 59.404840] bus_for_each_dev+0x100/0x190<br /> [ 59.405442] driver_attach+0x44/0x68<br /> [ 59.405980] bus_add_driver+0x23c/0x500<br /> [ 59.406550] driver_register+0xf8/0x3d0<br /> [ 59.407122] platform_driver_register+0x68/0x98<br /> [ 59.407810] mt8365_afe_pcm_driver_init+0x2c/0xff8 [snd_soc_mt8365_pcm]

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.