Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_hid: fix refcount leak on error path<br /> <br /> When failing to allocate report_desc, opts-&gt;refcnt has already been<br /> incremented so it needs to be decremented to avoid leaving the options<br /> structure permanently locked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix a potential memory leak in rtw_init_cmd_priv()<br /> <br /> In rtw_init_cmd_priv(), if `pcmdpriv-&gt;rsp_allocated_buf` is allocated<br /> in failure, then `pcmdpriv-&gt;cmd_allocated_buf` will be not properly<br /> released. Besides, considering there are only two error paths and the<br /> first one can directly return, so we do not need implicitly jump to the<br /> `exit` tag to execute the error handler.<br /> <br /> So this patch added `kfree(pcmdpriv-&gt;cmd_allocated_buf);` on the error<br /> path to release the resource and simplified the return logic of<br /> rtw_init_cmd_priv(). As there is no proper device to test with, no runtime<br /> testing was performed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix potential memory leak in ext4_fc_record_regions()<br /> <br /> As krealloc may return NULL, in this case &amp;#39;state-&gt;fc_regions&amp;#39; may not be<br /> freed by krealloc, but &amp;#39;state-&gt;fc_regions&amp;#39; already set NULL. Then will<br /> lead to &amp;#39;state-&gt;fc_regions&amp;#39; memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/fonts: fix undefined behavior in bit shift for get_default_font<br /> <br /> Shifting signed 32-bit value by 31 bits is undefined, so changing<br /> significant bit to unsigned. The UBSAN warning calltrace like below:<br /> <br /> UBSAN: shift-out-of-bounds in lib/fonts/fonts.c:139:20<br /> left shift of 1 by 31 places cannot be represented in type &amp;#39;int&amp;#39;<br /> <br /> dump_stack_lvl+0x7d/0xa5<br /> dump_stack+0x15/0x1b<br /> ubsan_epilogue+0xe/0x4e<br /> __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c<br /> get_default_font+0x1c7/0x1f0<br /> fbcon_startup+0x347/0x3a0<br /> do_take_over_console+0xce/0x270<br /> do_fbcon_takeover+0xa1/0x170<br /> do_fb_registered+0x2a8/0x340<br /> fbcon_fb_registered+0x47/0xe0<br /> register_framebuffer+0x294/0x4a0<br /> __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper]<br /> drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper]<br /> drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper]<br /> drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper]<br /> bochs_pci_probe+0x6ca/0x772 [bochs]<br /> local_pci_probe+0x4d/0xb0<br /> pci_device_probe+0x119/0x320<br /> really_probe+0x181/0x550<br /> __driver_probe_device+0xc6/0x220<br /> driver_probe_device+0x32/0x100<br /> __driver_attach+0x195/0x200<br /> bus_for_each_dev+0xbb/0x120<br /> driver_attach+0x27/0x30<br /> bus_add_driver+0x22e/0x2f0<br /> driver_register+0xa9/0x190<br /> __pci_register_driver+0x90/0xa0<br /> bochs_pci_driver_init+0x52/0x1000 [bochs]<br /> do_one_initcall+0x76/0x430<br /> do_init_module+0x61/0x28a<br /> load_module+0x1f82/0x2e50<br /> __do_sys_finit_module+0xf8/0x190<br /> __x64_sys_finit_module+0x23/0x30<br /> do_syscall_64+0x58/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/smmuv3: Fix hotplug callback leak in arm_smmu_pmu_init()<br /> <br /> arm_smmu_pmu_init() won&amp;#39;t remove the callback added by<br /> cpuhp_setup_state_multi() when platform_driver_register() failed. Remove<br /> the callback by cpuhp_remove_multi_state() in fail path.<br /> <br /> Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus:<br /> arm-ccn: Prevent hotplug callback leak")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: coda: Add check for kmalloc<br /> <br /> As the kmalloc may return NULL pointer,<br /> it should be better to check the return value<br /> in order to avoid NULL poineter dereference,<br /> same as the others.

Rack is a modular Ruby web server interface. In versions prior to 2.2.19, 3.1.17, and 3.2.2, ``Rack::Multipart::Parser` stores non-file form fields (parts without a `filename`) entirely in memory as Ruby `String` objects. A single large text field in a multipart/form-data request (hundreds of megabytes or more) can consume equivalent process memory, potentially leading to out-of-memory (OOM) conditions and denial of service (DoS). Attackers can send large non-file fields to trigger excessive memory usage. Impact scales with request size and concurrency, potentially leading to worker crashes or severe garbage-collection overhead. All Rack applications processing multipart form submissions are affected. Versions 2.2.19, 3.1.17, and 3.2.2 enforce a reasonable size cap for non-file fields (e.g., 2 MiB). Workarounds include restricting maximum request body size at the web-server or proxy layer (e.g., Nginx `client_max_body_size`) and validating and rejecting unusually large form fields at the application level.

Rack is a modular Ruby web server interface. In versions prior to 2.2.19, 3.1.17, and 3.2.2, `Rack::Multipart::Parser` can accumulate unbounded data when a multipart part’s header block never terminates with the required blank line (`CRLFCRLF`). The parser keeps appending incoming bytes to memory without a size cap, allowing a remote attacker to exhaust memory and cause a denial of service (DoS). Attackers can send incomplete multipart headers to trigger high memory use, leading to process termination (OOM) or severe slowdown. The effect scales with request size limits and concurrency. All applications handling multipart uploads may be affected. Versions 2.2.19, 3.1.17, and 3.2.2 cap per-part header size (e.g., 64 KiB). As a workaround, restrict maximum request sizes at the proxy or web server layer (e.g., Nginx `client_max_body_size`).

Rack is a modular Ruby web server interface. In versions prior to 2.2.19, 3.1.17, and 3.2.2, `Rack::Multipart::Parser` buffers the entire multipart preamble (bytes before the first boundary) in memory without any size limit. A client can send a large preamble followed by a valid boundary, causing significant memory use and potential process termination due to out-of-memory (OOM) conditions. Remote attackers can trigger large transient memory spikes by including a long preamble in multipart/form-data requests. The impact scales with allowed request sizes and concurrency, potentially causing worker crashes or severe slowdown due to garbage collection. Versions 2.2.19, 3.1.17, and 3.2.2 enforce a preamble size limit (e.g., 16 KiB) or discard preamble data entirely. Workarounds include limiting total request body size at the proxy or web server level and monitoring memory and set per-process limits to prevent OOM conditions.

A weakness has been identified in SourceCodester Hotel and Lodge Management System 1.0. The impacted element is an unknown function of the file /profile.php of the component Profile Page. Executing manipulation of the argument image can lead to unrestricted upload. The attack may be launched remotely. The exploit has been made available to the public and could be exploited.

A potential security vulnerability has been identified in HP Sure Start’s protection of the Intel Flash Descriptor in certain HP PC products, which might allow security bypass, arbitrary code execution, loss of integrity or confidentiality, or denial of service. HP is releasing BIOS updates to mitigate the potential vulnerability.

CubeAPM nightly-2025-08-01-1 allow unauthenticated attackers to inject arbitrary log entries into production systems via the /api/logs/insert/elasticsearch/_bulk endpoint. This endpoint accepts bulk log data without requiring authentication or input validation, allowing remote attackers to perform unauthorized log injection. Exploitation may lead to false log entries, log poisoning, alert obfuscation, and potential performance degradation of the observability pipeline. The issue is present in the core CubeAPM platform and is not limited to specific deployment configurations.