Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: dlm: fix invalid derefence of sb_lvbptr<br /> <br /> I experience issues when putting a lkbsb on the stack and have sb_lvbptr<br /> field to a dangled pointer while not using DLM_LKF_VALBLK. It will crash<br /> with the following kernel message, the dangled pointer is here<br /> 0xdeadbeef as example:<br /> <br /> [ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef<br /> [ 102.749320] #PF: supervisor read access in kernel mode<br /> [ 102.749323] #PF: error_code(0x0000) - not-present page<br /> [ 102.749325] PGD 0 P4D 0<br /> [ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI<br /> [ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565<br /> [ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014<br /> [ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10<br /> [ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe<br /> [ 102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202<br /> [ 102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040<br /> [ 102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070<br /> [ 102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001<br /> [ 102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70<br /> [ 102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001<br /> [ 102.749368] FS: 0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000<br /> [ 102.749372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0<br /> [ 102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 102.749379] PKRU: 55555554<br /> [ 102.749381] Call Trace:<br /> [ 102.749382] <br /> [ 102.749383] ? send_args+0xb2/0xd0<br /> [ 102.749389] send_common+0xb7/0xd0<br /> [ 102.749395] _unlock_lock+0x2c/0x90<br /> [ 102.749400] unlock_lock.isra.56+0x62/0xa0<br /> [ 102.749405] dlm_unlock+0x21e/0x330<br /> [ 102.749411] ? lock_torture_stats+0x80/0x80 [dlm_locktorture]<br /> [ 102.749416] torture_unlock+0x5a/0x90 [dlm_locktorture]<br /> [ 102.749419] ? preempt_count_sub+0xba/0x100<br /> [ 102.749427] lock_torture_writer+0xbd/0x150 [dlm_locktorture]<br /> [ 102.786186] kthread+0x10a/0x130<br /> [ 102.786581] ? kthread_complete_and_exit+0x20/0x20<br /> [ 102.787156] ret_from_fork+0x22/0x30<br /> [ 102.787588] <br /> [ 102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw<br /> [ 102.792536] CR2: 00000000deadbeef<br /> [ 102.792930] ---[ end trace 0000000000000000 ]---<br /> <br /> This patch fixes the issue by checking also on DLM_LKF_VALBLK on exflags<br /> is set when copying the lvbptr array instead of if it&amp;#39;s just null which<br /> fixes for me the issue.<br /> <br /> I think this patch can fix other dlm users as well, depending how they<br /> handle the init, freeing memory handling of sb_lvbptr and don&amp;#39;t set<br /> DLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be a<br /> hidden issue all the time. However with checking on DLM_LKF_VALBLK the<br /> user always need to provide a sb_lvbptr non-null value. There might be<br /> more intelligent handling between per ls lvblen, DLM_LKF_VALBLK and<br /> non-null to report the user the way how DLM API is used is wrong but can<br /> be added for later, this will only fix the current behaviour.

*** 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 /> 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 /> 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 /> 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`).

*** 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` 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.

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

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