Vulnerabilidades

*** Pendiente de traducción *** lwjson 1.8.1 contains an improper input validation vulnerability in the streaming JSON parser (lwjson_stream.c). The end-of-string detection logic incorrectly identifies escaped quote characters by only checking the immediately preceding character rather than counting consecutive backslashes, causing valid JSON strings ending with an escaped backslash (like "\\") to never terminate parsing. A remote attacker can send well-formed JSON to cause applications using lwjson_stream_parse() to hang indefinitely, resulting in denial of service.

*** Pendiente de traducción *** nanoMODBUS through v1.22.0 has a stack-based buffer overflow in recv_read_registers_res() in nanomodbus.c. When a client calls nmbs_read_holding_registers() or nmbs_read_input_registers(), the library writes register data from the server response to the caller-provided buffer based on the response's byte_count field before validating that byte_count matches the requested quantity. A malicious Modbus TCP server can send a response with byte_count=250 (125 registers) regardless of the requested quantity, causing up to 248 bytes of attacker-controlled data to overflow the buffer, potentially allowing remote code execution.

*** Pendiente de traducción *** ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.4.0, prior to zebra-chain version 7.0.0, and prior to zebra-network version 6.0.0, several inbound deserialization paths in Zebra allocated buffers sized against generic transport or block-size ceilings before the tighter protocol or consensus limits were enforced. An unauthenticated or post-handshake peer could therefore force the node to preallocate and parse for orders of magnitude more data than the protocol intended, across headers messages, equihash solutions in block headers, Sapling spend vectors in V5/V4 transactions, and coinbase script bytes in blocks. This issue has been patched in zebrad version 4.4.0, zebra-chain version 7.0.0, and zebra-network version 6.0.0.

*** Pendiente de traducción *** ZEBRA is a Zcash node written entirely in Rust. Prior to version 4.4.0, Zebra's block validator undercounts transparent signature operations against the 20000-sigop block limit (MAX_BLOCK_SIGOPS), allowing it to accept blocks that zcashd rejects with bad-blk-sigops. A miner who produces such a block can split the network: Zebra nodes follow the offending chain while zcashd nodes do not. This issue has been patched in version 4.4.0.

*** Pendiente de traducción *** ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.4.0 and prior to zebra-script version 6.0.0, the fix for CVE-2026-41583 introduced a separate issue due to insufficient error handling of the case where the sighash type is invalid, during sighash computation. Instead of returning an error, the normal flow would resume, and the input sighash buffer would be left untouched. In scenarios where a previous signature validation could leave a valid sighash in the buffer, an invalid hash-type could be incorrectly accepted, which would create a consensus split between Zebra and zcashd nodes. This issue has been patched in zebrad version 4.4.0 and zebra-script version 6.0.0.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs: return EISDIR on nfs3_proc_create if d_alias is a dir<br /> <br /> If we found an alias through nfs3_do_create/nfs_add_or_obtain<br /> /d_splice_alias which happens to be a dir dentry, we don&amp;#39;t return<br /> any error, and simply forget about this alias, but the original<br /> dentry we were adding and passed as parameter remains negative.<br /> <br /> This later causes an oops on nfs_atomic_open_v23/finish_open since we<br /> supply a negative dentry to do_dentry_open.<br /> <br /> This has been observed running lustre-racer, where dirs and files are<br /> created/removed concurrently with the same name and O_EXCL is not<br /> used to open files (frequent file redirection).<br /> <br /> While d_splice_alias typically returns a directory alias or NULL, we<br /> explicitly check d_is_dir() to ensure that we don&amp;#39;t attempt to perform<br /> file operations (like finish_open) on a directory inode, which triggers<br /> the observed oops.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Fix possible NULL pointer dereference in ufshcd_add_command_trace()<br /> <br /> The kernel log indicates a crash in ufshcd_add_command_trace, due to a NULL<br /> pointer dereference when accessing hwq-&gt;id. This can happen if<br /> ufshcd_mcq_req_to_hwq() returns NULL.<br /> <br /> This patch adds a NULL check for hwq before accessing its id field to<br /> prevent a kernel crash.<br /> <br /> Kernel log excerpt:<br /> [] notify_die+0x4c/0x8c<br /> [] __die+0x60/0xb0<br /> [] die+0x4c/0xe0<br /> [] die_kernel_fault+0x74/0x88<br /> [] __do_kernel_fault+0x314/0x318<br /> [] do_page_fault+0xa4/0x5f8<br /> [] do_translation_fault+0x34/0x54<br /> [] do_mem_abort+0x50/0xa8<br /> [] el1_abort+0x3c/0x64<br /> [] el1h_64_sync_handler+0x44/0xcc<br /> [] el1h_64_sync+0x80/0x88<br /> [] ufshcd_add_command_trace+0x23c/0x320<br /> [] ufshcd_compl_one_cqe+0xa4/0x404<br /> [] ufshcd_mcq_poll_cqe_lock+0xac/0x104<br /> [] ufs_mtk_mcq_intr+0x54/0x74 [ufs_mediatek_mod]<br /> [] __handle_irq_event_percpu+0xc8/0x348<br /> [] handle_irq_event+0x3c/0xa8<br /> [] handle_fasteoi_irq+0xf8/0x294<br /> [] generic_handle_domain_irq+0x54/0x80<br /> [] gic_handle_irq+0x1d4/0x330<br /> [] call_on_irq_stack+0x44/0x68<br /> [] do_interrupt_handler+0x78/0xd8<br /> [] el1_interrupt+0x48/0xa8<br /> [] el1h_64_irq_handler+0x14/0x24<br /> [] el1h_64_irq+0x80/0x88<br /> [] arch_local_irq_enable+0x4/0x1c<br /> [] cpuidle_enter+0x34/0x54<br /> [] do_idle+0x1dc/0x2f8<br /> [] cpu_startup_entry+0x30/0x3c<br /> [] secondary_start_kernel+0x134/0x1ac<br /> [] __secondary_switched+0xc4/0xcc

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> unshare: fix unshare_fs() handling<br /> <br /> There&amp;#39;s an unpleasant corner case in unshare(2), when we have a<br /> CLONE_NEWNS in flags and current-&gt;fs hadn&amp;#39;t been shared at all; in that<br /> case copy_mnt_ns() gets passed current-&gt;fs instead of a private copy,<br /> which causes interesting warts in proof of correctness]<br /> <br /> &gt; I guess if private means fs-&gt;users == 1, the condition could still be true.<br /> <br /> Unfortunately, it&amp;#39;s worse than just a convoluted proof of correctness.<br /> Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS<br /> (and current-&gt;fs-&gt;users == 1).<br /> <br /> We pass current-&gt;fs to copy_mnt_ns(), all right. Suppose it succeeds and<br /> flips current-&gt;fs-&gt;{pwd,root} to corresponding locations in the new namespace.<br /> Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM).<br /> We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it&amp;#39;s<br /> destroyed and its mount tree is dissolved, but... current-&gt;fs-&gt;root and<br /> current-&gt;fs-&gt;pwd are both left pointing to now detached mounts.<br /> <br /> They are pinning those, so it&amp;#39;s not a UAF, but it leaves the calling<br /> process with unshare(2) failing with -ENOMEM _and_ leaving it with<br /> pwd and root on detached isolated mounts. The last part is clearly a bug.<br /> <br /> There is other fun related to that mess (races with pivot_root(), including<br /> the one between pivot_root() and fork(), of all things), but this one<br /> is easy to isolate and fix - treat CLONE_NEWNS as "allocate a new<br /> fs_struct even if it hadn&amp;#39;t been shared in the first place". Sure, we could<br /> go for something like "if both CLONE_NEWNS *and* one of the things that might<br /> end up failing after copy_mnt_ns() call in create_new_namespaces() are set,<br /> force allocation of new fs_struct", but let&amp;#39;s keep it simple - the cost<br /> of copy_fs_struct() is trivial.<br /> <br /> Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets<br /> a freshly allocated fs_struct, yet to be attached to anything. That<br /> seriously simplifies the analysis...<br /> <br /> FWIW, that bug had been there since the introduction of unshare(2) ;-/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Add NULL checks when resetting request and reply queues<br /> <br /> The driver encountered a crash during resource cleanup when the reply and<br /> request queues were NULL due to freed memory. This issue occurred when the<br /> creation of reply or request queues failed, and the driver freed the memory<br /> first, but attempted to mem set the content of the freed memory, leading to<br /> a system crash.<br /> <br /> Add NULL pointer checks for reply and request queues before accessing the<br /> reply/request memory during cleanup

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: init flags_valid before calling vfs_fileattr_get<br /> <br /> syzbot reported a uninit-value bug in [1].<br /> <br /> Similar to the "*get" context where the kernel&amp;#39;s internal file_kattr<br /> structure is initialized before calling vfs_fileattr_get(), we should<br /> use the same mechanism when using fa.<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in fuse_fileattr_get+0xeb4/0x1450 fs/fuse/ioctl.c:517<br /> fuse_fileattr_get+0xeb4/0x1450 fs/fuse/ioctl.c:517<br /> vfs_fileattr_get fs/file_attr.c:94 [inline]<br /> __do_sys_file_getattr fs/file_attr.c:416 [inline]<br /> <br /> Local variable fa.i created at:<br /> __do_sys_file_getattr fs/file_attr.c:380 [inline]<br /> __se_sys_file_getattr+0x8c/0xbd0 fs/file_attr.c:372

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT<br /> <br /> This resolves the follow splat and lock-up when running with PREEMPT_RT<br /> enabled on Hyper-V:<br /> <br /> [ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002<br /> [ 415.140822] INFO: lockdep is turned off.<br /> [ 415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common<br /> [ 415.140846] Preemption disabled at:<br /> [ 415.140847] [] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]<br /> [ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)}<br /> [ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024<br /> [ 415.140857] Call Trace:<br /> [ 415.140861] <br /> [ 415.140861] ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]<br /> [ 415.140863] dump_stack_lvl+0x91/0xb0<br /> [ 415.140870] __schedule_bug+0x9c/0xc0<br /> [ 415.140875] __schedule+0xdf6/0x1300<br /> [ 415.140877] ? rtlock_slowlock_locked+0x56c/0x1980<br /> [ 415.140879] ? rcu_is_watching+0x12/0x60<br /> [ 415.140883] schedule_rtlock+0x21/0x40<br /> [ 415.140885] rtlock_slowlock_locked+0x502/0x1980<br /> [ 415.140891] rt_spin_lock+0x89/0x1e0<br /> [ 415.140893] hv_ringbuffer_write+0x87/0x2a0<br /> [ 415.140899] vmbus_sendpacket_mpb_desc+0xb6/0xe0<br /> [ 415.140900] ? rcu_is_watching+0x12/0x60<br /> [ 415.140902] storvsc_queuecommand+0x669/0xbe0 [hv_storvsc]<br /> [ 415.140904] ? HARDIRQ_verbose+0x10/0x10<br /> [ 415.140908] ? __rq_qos_issue+0x28/0x40<br /> [ 415.140911] scsi_queue_rq+0x760/0xd80 [scsi_mod]<br /> [ 415.140926] __blk_mq_issue_directly+0x4a/0xc0<br /> [ 415.140928] blk_mq_issue_direct+0x87/0x2b0<br /> [ 415.140931] blk_mq_dispatch_queue_requests+0x120/0x440<br /> [ 415.140933] blk_mq_flush_plug_list+0x7a/0x1a0<br /> [ 415.140935] __blk_flush_plug+0xf4/0x150<br /> [ 415.140940] __submit_bio+0x2b2/0x5c0<br /> [ 415.140944] ? submit_bio_noacct_nocheck+0x272/0x360<br /> [ 415.140946] submit_bio_noacct_nocheck+0x272/0x360<br /> [ 415.140951] ext4_read_bh_lock+0x3e/0x60 [ext4]<br /> [ 415.140995] ext4_block_write_begin+0x396/0x650 [ext4]<br /> [ 415.141018] ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4]<br /> [ 415.141038] ext4_da_write_begin+0x1c4/0x350 [ext4]<br /> [ 415.141060] generic_perform_write+0x14e/0x2c0<br /> [ 415.141065] ext4_buffered_write_iter+0x6b/0x120 [ext4]<br /> [ 415.141083] vfs_write+0x2ca/0x570<br /> [ 415.141087] ksys_write+0x76/0xf0<br /> [ 415.141089] do_syscall_64+0x99/0x1490<br /> [ 415.141093] ? rcu_is_watching+0x12/0x60<br /> [ 415.141095] ? finish_task_switch.isra.0+0xdf/0x3d0<br /> [ 415.141097] ? rcu_is_watching+0x12/0x60<br /> [ 415.141098] ? lock_release+0x1f0/0x2a0<br /> [ 415.141100] ? rcu_is_watching+0x12/0x60<br /> [ 415.141101] ? finish_task_switch.isra.0+0xe4/0x3d0<br /> [ 415.141103] ? rcu_is_watching+0x12/0x60<br /> [ 415.141104] ? __schedule+0xb34/0x1300<br /> [ 415.141106] ? hrtimer_try_to_cancel+0x1d/0x170<br /> [ 415.141109] ? do_nanosleep+0x8b/0x160<br /> [ 415.141111] ? hrtimer_nanosleep+0x89/0x100<br /> [ 415.141114] ? __pfx_hrtimer_wakeup+0x10/0x10<br /> [ 415.141116] ? xfd_validate_state+0x26/0x90<br /> [ 415.141118] ? rcu_is_watching+0x12/0x60<br /> [ 415.141120] ? do_syscall_64+0x1e0/0x1490<br /> [ 415.141121] ? do_syscall_64+0x1e0/0x1490<br /> [ 415.141123] ? rcu_is_watching+0x12/0x60<br /> [ 415.141124] ? do_syscall_64+0x1e0/0x1490<br /> [ 415.141125] ? do_syscall_64+0x1e0/0x1490<br /> [ 415.141127] ? irqentry_exit+0x140/0<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: spacemit: Fix error handling in emac_tx_mem_map()<br /> <br /> The DMA mappings were leaked on mapping error. Free them with the<br /> existing emac_free_tx_buf() function.