Vulnerabilities

A denial of service vulnerability exists in the NetX Component HTTP server functionality of STMicroelectronics X-CUBE-AZRTOS-WL 2.0.0. A specially crafted network packet can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability.This vulnerability affects X-CUBE-AZRTOS-F7 NetX Duo Web Component HTTP server v 1.1.0. This HTTP server implementation is contained in this file - x-cube-azrtos-f7\Middlewares\ST\netxduo\addons\web\nx_web_http_server.c

A denial of service vulnerability exists in the NetX Component HTTP server functionality of STMicroelectronics X-CUBE-AZRTOS-WL 2.0.0. A specially crafted network packet can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability.This vulnerability affects X-CUBE-AZRTOS-F7 NetX Duo Component HTTP Server HTTP server v 1.1.0. This HTTP server implementation is contained in this file - x-cube-azrtos-f7\Middlewares\ST\netxduo\addons\http\nxd_http_server.c

An integer underflow vulnerability exists in the HTTP server PUT request functionality of STMicroelectronics X-CUBE-AZRTOS-WL 2.0.0. A specially crafted series of network requests can lead to denial of service. An attacker can send a sequence of malicious packets to trigger this vulnerability.This vulnerability affects the NetX Duo Web Component HTTP Server implementation which can be found in x-cube-azrtos-f7\Middlewares\ST\netxduo\addons\web\nx_web_http_server.c

An integer underflow vulnerability exists in the HTTP server PUT request functionality of STMicroelectronics X-CUBE-AZRTOS-WL 2.0.0. A specially crafted series of network requests can lead to denial of service. An attacker can send a sequence of malicious packets to trigger this vulnerability.This vulnerability affects the NetX Duo Component HTTP Server implementation which can be found in x-cube-azrtos-f7\Middlewares\ST\netxduo\addons\http\nxd_http_server.c

An issue was discovered in Django 5.1 before 5.1.8 and 5.0 before 5.0.14. The NFKC normalization is slow on Windows. As a consequence, django.contrib.auth.views.LoginView, django.contrib.auth.views.LogoutView, and django.views.i18n.set_language are subject to a potential denial-of-service attack via certain inputs with a very large number of Unicode characters.

mime.php in SquirrelMail through 1.4.23-svn-20250401 and 1.5.x through 1.5.2-svn-20250401 allows XSS via e-mail headers, because JavaScript payloads are mishandled after $encoded has been set to true.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: init return value in amdgpu_ttm_clear_buffer<br /> <br /> Otherwise an uninitialized value can be returned if<br /> amdgpu_res_cleared returns true for all regions.<br /> <br /> Possibly closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3812<br /> <br /> (cherry picked from commit 7c62aacc3b452f73a1284198c81551035fac6d71)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: fix missing .is_two_pixels_per_container<br /> <br /> Starting from 6.11, AMDGPU driver, while being loaded with amdgpu.dc=1,<br /> due to lack of .is_two_pixels_per_container function in dce60_tg_funcs,<br /> causes a NULL pointer dereference on PCs with old GPUs, such as R9 280X.<br /> <br /> So this fix adds missing .is_two_pixels_per_container to dce60_tg_funcs.<br /> <br /> (cherry picked from commit bd4b125eb949785c6f8a53b0494e32795421209d)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: NULL-check BO&amp;#39;s backing store when determining GFX12 PTE flags<br /> <br /> PRT BOs may not have any backing store, so bo-&gt;tbo.resource will be<br /> NULL. Check for that before dereferencing.<br /> <br /> (cherry picked from commit 3e3fcd29b505cebed659311337ea03b7698767fc)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/netfs/read_collect: add to next-&gt;prev_donated<br /> <br /> If multiple subrequests donate data to the same "next" request<br /> (depending on the subrequest completion order), each of them would<br /> overwrite the `prev_donated` field, causing data corruption and a<br /> BUG() crash ("Can&amp;#39;t donate prior to front").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: ignore non-functional sensor in HP 5MP Camera<br /> <br /> The HP 5MP Camera (USB ID 0408:5473) reports a HID sensor interface that<br /> is not actually implemented. Attempting to access this non-functional<br /> sensor via iio_info causes system hangs as runtime PM tries to wake up<br /> an unresponsive sensor.<br /> <br /> [453] hid-sensor-hub 0003:0408:5473.0003: Report latency attributes: ffffffff:ffffffff<br /> [453] hid-sensor-hub 0003:0408:5473.0003: common attributes: 5:1, 2:1, 3:1 ffffffff:ffffffff<br /> <br /> Add this device to the HID ignore list since the sensor interface is<br /> non-functional by design and should not be exposed to userspace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodes<br /> <br /> Currently, load_microcode_amd() iterates over all NUMA nodes, retrieves their<br /> CPU masks and unconditionally accesses per-CPU data for the first CPU of each<br /> mask.<br /> <br /> According to Documentation/admin-guide/mm/numaperf.rst:<br /> <br /> "Some memory may share the same node as a CPU, and others are provided as<br /> memory only nodes."<br /> <br /> Therefore, some node CPU masks may be empty and wouldn&amp;#39;t have a "first CPU".<br /> <br /> On a machine with far memory (and therefore CPU-less NUMA nodes):<br /> - cpumask_of_node(nid) is 0<br /> - cpumask_first(0) is CONFIG_NR_CPUS<br /> - cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an<br /> index that is 1 out of bounds<br /> <br /> This does not have any security implications since flashing microcode is<br /> a privileged operation but I believe this has reliability implications by<br /> potentially corrupting memory while flashing a microcode update.<br /> <br /> When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashes<br /> a microcode update. I get the following splat:<br /> <br /> UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y<br /> index 512 is out of range for type &amp;#39;unsigned long[512]&amp;#39;<br /> [...]<br /> Call Trace:<br /> dump_stack<br /> __ubsan_handle_out_of_bounds<br /> load_microcode_amd<br /> request_microcode_amd<br /> reload_store<br /> kernfs_fop_write_iter<br /> vfs_write<br /> ksys_write<br /> do_syscall_64<br /> entry_SYSCALL_64_after_hwframe<br /> <br /> Change the loop to go over only NUMA nodes which have CPUs before determining<br /> whether the first CPU on the respective node needs microcode update.<br /> <br /> [ bp: Massage commit message, fix typo. ]