Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/radeon: Fix PCI device refcount leak in radeon_atrm_get_bios()<br /> <br /> As comment of pci_get_class() says, it returns a pci_device with its<br /> refcount increased and decreased the refcount for the input parameter<br /> @from if it is not NULL.<br /> <br /> If we break the loop in radeon_atrm_get_bios() with &amp;#39;pdev&amp;#39; not NULL, we<br /> need to call pci_dev_put() to decrease the refcount. Add the missing<br /> pci_dev_put() to avoid refcount leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: replace WARN_ONs by nilfs_error for checkpoint acquisition failure<br /> <br /> If creation or finalization of a checkpoint fails due to anomalies in the<br /> checkpoint metadata on disk, a kernel warning is generated.<br /> <br /> This patch replaces the WARN_ONs by nilfs_error, so that a kernel, booted<br /> with panic_on_warn, does not panic. A nilfs_error is appropriate here to<br /> handle the abnormal filesystem condition.<br /> <br /> This also replaces the detected error codes with an I/O error so that<br /> neither of the internal error codes is returned to callers.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: Fix locking in pdc_iodc_print() firmware call<br /> <br /> Utilize pdc_lock spinlock to protect parallel modifications of the<br /> iodc_dbuf[] buffer, check length to prevent buffer overflow of<br /> iodc_dbuf[], drop the iodc_retbuf[] buffer and fix some wrong<br /> indentings.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: mxm-wmi: fix memleak in mxm_wmi_call_mx[ds|mx]()<br /> <br /> The ACPI buffer memory (out.pointer) returned by wmi_evaluate_method()<br /> is not freed after the call, so it leads to memory leak.<br /> <br /> The method results in ACPI buffer is not used, so just pass NULL to<br /> wmi_evaluate_method() which fixes the memory leak.

*** Pendiente de traducción *** 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 />

*** Pendiente de traducción *** 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")

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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`).