Vulnerabilities

NextChat contains a cross-site scripting (XSS) vulnerability in the HTMLPreview component of artifacts.tsx that allows attackers to execute arbitrary JavaScript code when HTML content is rendered in the AI chat interface. The vulnerability occurs because user-influenced HTML from AI responses is rendered in an iframe with 'allow-scripts' sandbox permission without proper sanitization. This can be exploited through specifically crafted prompts that cause the AI to generate malicious HTML/JavaScript code. When a user views the HTML preview, the injected JavaScript executes in the user's browser context, potentially allowing attackers to exfiltrate sensitive information (including API keys stored in localStorage), perform actions on behalf of the user, and steal session data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "drm/prime: Use dma_buf from GEM object instance"<br /> <br /> This reverts commit f83a9b8c7fd0557b0c50784bfdc1bbe9140c9bf8.<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 /> xfrm: state: initialize state_ptrs earlier in xfrm_state_find<br /> <br /> In case of preemption, xfrm_state_look_at will find a different<br /> pcpu_id and look up states for that other CPU. If we matched a state<br /> for CPU2 in the state_cache while the lookup started on CPU1, we will<br /> jump to "found", but the "best" state that we got will be ignored and<br /> we will enter the "acquire" block. This block uses state_ptrs, which<br /> isn&amp;#39;t initialized at this point.<br /> <br /> Let&amp;#39;s initialize state_ptrs just after taking rcu_read_lock. This will<br /> also prevent a possible misuse in the future, if someone adjusts this<br /> function.

User enumeration vulnerability in Liferay Portal 7.4.0 through 7.4.3.132, and Liferay DXP 2024.Q4.0 through 2024.Q4.7, 2024.Q3.0 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13, 2024.Q1.1 through 2024.Q1.14, 2023.Q4.0 through 2023.Q4.10, 2023.Q3.1 through 2023.Q3.10 and 7.4 GA through update 92 allows remote attackers to determine if an account exist in the application via the create account page.

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