Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/ksm: fix flag-dropping behavior in ksm_madvise<br /> <br /> syzkaller discovered the following crash: (kernel BUG)<br /> <br /> [ 44.607039] ------------[ cut here ]------------<br /> [ 44.607422] kernel BUG at mm/userfaultfd.c:2067!<br /> [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI<br /> [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)<br /> [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> [ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460<br /> <br /> <br /> <br /> [ 44.617726] Call Trace:<br /> [ 44.617926] <br /> [ 44.619284] userfaultfd_release+0xef/0x1b0<br /> [ 44.620976] __fput+0x3f9/0xb60<br /> [ 44.621240] fput_close_sync+0x110/0x210<br /> [ 44.622222] __x64_sys_close+0x8f/0x120<br /> [ 44.622530] do_syscall_64+0x5b/0x2f0<br /> [ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 44.623244] RIP: 0033:0x7f365bb3f227<br /> <br /> Kernel panics because it detects UFFD inconsistency during<br /> userfaultfd_release_all(). Specifically, a VMA which has a valid pointer<br /> to vma-&gt;vm_userfaultfd_ctx, but no UFFD flags in vma-&gt;vm_flags.<br /> <br /> The inconsistency is caused in ksm_madvise(): when user calls madvise()<br /> with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,<br /> it accidentally clears all flags stored in the upper 32 bits of<br /> vma-&gt;vm_flags.<br /> <br /> Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and<br /> int are 32-bit wide. This setup causes the following mishap during the &amp;=<br /> ~VM_MERGEABLE assignment.<br /> <br /> VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000&amp;#39;0000. <br /> After ~ is applied, it becomes 0x7fff&amp;#39;ffff unsigned int, which is then<br /> promoted to unsigned long before the &amp; operation. This promotion fills<br /> upper 32 bits with leading 0s, as we&amp;#39;re doing unsigned conversion (and<br /> even for a signed conversion, this wouldn&amp;#39;t help as the leading bit is 0).<br /> &amp; operation thus ends up AND-ing vm_flags with 0x0000&amp;#39;0000&amp;#39;7fff&amp;#39;ffff<br /> instead of intended 0xffff&amp;#39;ffff&amp;#39;7fff&amp;#39;ffff and hence accidentally clears<br /> the upper 32-bits of its value.<br /> <br /> Fix it by changing `VM_MERGEABLE` constant to unsigned long, using the<br /> BIT() macro.<br /> <br /> Note: other VM_* flags are not affected: This only happens to the<br /> VM_MERGEABLE flag, as the other VM_* flags are all constants of type int<br /> and after ~ operation, they end up with leading 1 and are thus converted<br /> to unsigned long with leading 1s.<br /> <br /> Note 2:<br /> After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is<br /> no longer a kernel BUG, but a WARNING at the same place:<br /> <br /> [ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067<br /> <br /> but the root-cause (flag-drop) remains the same.<br /> <br /> [akpm@linux-foundation.org: rust bindgen wasn&amp;#39;t able to handle BIT(), from Miguel]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: fsl-mc: Check return value of platform_get_resource()<br /> <br /> platform_get_resource() returns NULL in case of failure, so check its<br /> return value and propagate the error in order to prevent NULL pointer<br /> dereference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: check the return value of pinmux_ops::get_function_name()<br /> <br /> While the API contract in docs doesn&amp;#39;t specify it explicitly, the<br /> generic implementation of the get_function_name() callback from struct<br /> pinmux_ops - pinmux_generic_get_function_name() - can fail and return<br /> NULL. This is already checked in pinmux_check_ops() so add a similar<br /> check in pinmux_func_name_to_selector() instead of passing the returned<br /> pointer right down to strcmp() where the NULL can get dereferenced. This<br /> is normal operation when adding new pinfunctions.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tee: fix register_shm_helper()<br /> <br /> In register_shm_helper(), fix incorrect error handling for a call to<br /> iov_iter_extract_pages(). A case is missing for when<br /> iov_iter_extract_pages() only got some pages and return a number larger<br /> than 0, but not the requested amount.<br /> <br /> This fixes a possible NULL pointer dereference following a bad input from<br /> ioctl(TEE_IOC_SHM_REGISTER) where parts of the buffer isn&amp;#39;t mapped.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Don&amp;#39;t (re)check L1 intercepts when completing userspace I/O<br /> <br /> When completing emulation of instruction that generated a userspace exit<br /> for I/O, don&amp;#39;t recheck L1 intercepts as KVM has already finished that<br /> phase of instruction execution, i.e. has already committed to allowing L2<br /> to perform I/O. If L1 (or host userspace) modifies the I/O permission<br /> bitmaps during the exit to userspace, KVM will treat the access as being<br /> intercepted despite already having emulated the I/O access.<br /> <br /> Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation.<br /> Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (the<br /> intended "recipient") can reach the code in question. gp_interception()&amp;#39;s<br /> use is mutually exclusive with is_guest_mode(), and<br /> complete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE with<br /> EMULTYPE_SKIP.<br /> <br /> The bad behavior was detected by a syzkaller program that toggles port I/O<br /> interception during the userspace I/O exit, ultimately resulting in a WARN<br /> on vcpu-&gt;arch.pio.count being non-zero due to KVM no completing emulation<br /> of the I/O instruction.<br /> <br /> WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm]<br /> Modules linked in: kvm_intel kvm irqbypass<br /> CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm]<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> kvm_fast_pio+0xd6/0x1d0 [kvm]<br /> vmx_handle_exit+0x149/0x610 [kvm_intel]<br /> kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm]<br /> kvm_vcpu_ioctl+0x244/0x8c0 [kvm]<br /> __x64_sys_ioctl+0x8a/0xd0<br /> do_syscall_64+0x5d/0xc60<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/9p: fix double req put in p9_fd_cancelled<br /> <br /> Syzkaller reports a KASAN issue as below:<br /> <br /> general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f]<br /> CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014<br /> RIP: 0010:__list_del include/linux/list.h:114 [inline]<br /> RIP: 0010:__list_del_entry include/linux/list.h:137 [inline]<br /> RIP: 0010:list_del include/linux/list.h:148 [inline]<br /> RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734<br /> <br /> Call Trace:<br /> <br /> p9_client_flush+0x351/0x440 net/9p/client.c:614<br /> p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734<br /> p9_client_version net/9p/client.c:920 [inline]<br /> p9_client_create+0xb51/0x1240 net/9p/client.c:1027<br /> v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408<br /> v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126<br /> legacy_get_tree+0x108/0x220 fs/fs_context.c:632<br /> vfs_get_tree+0x8e/0x300 fs/super.c:1573<br /> do_new_mount fs/namespace.c:3056 [inline]<br /> path_mount+0x6a6/0x1e90 fs/namespace.c:3386<br /> do_mount fs/namespace.c:3399 [inline]<br /> __do_sys_mount fs/namespace.c:3607 [inline]<br /> __se_sys_mount fs/namespace.c:3584 [inline]<br /> __x64_sys_mount+0x283/0x300 fs/namespace.c:3584<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> This happens because of a race condition between:<br /> <br /> - The 9p client sending an invalid flush request and later cleaning it up;<br /> - The 9p client in p9_read_work() canceled all pending requests.<br /> <br /> Thread 1 Thread 2<br /> ...<br /> p9_client_create()<br /> ...<br /> p9_fd_create()<br /> ...<br /> p9_conn_create()<br /> ...<br /> // start Thread 2<br /> INIT_WORK(&amp;m-&gt;rq, p9_read_work);<br /> p9_read_work()<br /> ...<br /> p9_client_rpc()<br /> ...<br /> ...<br /> p9_conn_cancel()<br /> ...<br /> spin_lock(&amp;m-&gt;req_lock);<br /> ...<br /> p9_fd_cancelled()<br /> ...<br /> ...<br /> spin_unlock(&amp;m-&gt;req_lock);<br /> // status rewrite<br /> p9_client_cb(m-&gt;client, req, REQ_STATUS_ERROR)<br /> // first remove<br /> list_del(&amp;req-&gt;req_list);<br /> ...<br /> <br /> spin_lock(&amp;m-&gt;req_lock)<br /> ...<br /> // second remove<br /> list_del(&amp;req-&gt;req_list);<br /> spin_unlock(&amp;m-&gt;req_lock)<br /> ...<br /> <br /> Commit 74d6a5d56629 ("9p/trans_fd: Fix concurrency del of req_list in<br /> p9_fd_cancelled/p9_read_work") fixes a concurrency issue in the 9p filesystem<br /> client where the req_list could be deleted simultaneously by both<br /> p9_read_work and p9_fd_cancelled functions, but for the case where req-&gt;status<br /> equals REQ_STATUS_RCVD.<br /> <br /> Update the check for req-&gt;status in p9_fd_cancelled to skip processing not<br /> just received requests, but anything that is not SENT, as whatever<br /> changed the state from SENT also removed the request from its list.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.<br /> <br /> [updated the check from status == RECV || status == ERROR to status != SENT]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: fix double-free in dbitmap<br /> <br /> A process might fail to allocate a new bitmap when trying to expand its<br /> proc-&gt;dmap. In that case, dbitmap_grow() fails and frees the old bitmap<br /> via dbitmap_free(). However, the driver calls dbitmap_free() again when<br /> the same process terminates, leading to a double-free error:<br /> <br /> ==================================================================<br /> BUG: KASAN: double-free in binder_proc_dec_tmpref+0x2e0/0x55c<br /> Free of addr ffff00000b7c1420 by task kworker/9:1/209<br /> <br /> CPU: 9 UID: 0 PID: 209 Comm: kworker/9:1 Not tainted 6.17.0-rc6-dirty #5 PREEMPT<br /> Hardware name: linux,dummy-virt (DT)<br /> Workqueue: events binder_deferred_func<br /> Call trace:<br /> kfree+0x164/0x31c<br /> binder_proc_dec_tmpref+0x2e0/0x55c<br /> binder_deferred_func+0xc24/0x1120<br /> process_one_work+0x520/0xba4<br /> [...]<br /> <br /> Allocated by task 448:<br /> __kmalloc_noprof+0x178/0x3c0<br /> bitmap_zalloc+0x24/0x30<br /> binder_open+0x14c/0xc10<br /> [...]<br /> <br /> Freed by task 449:<br /> kfree+0x184/0x31c<br /> binder_inc_ref_for_node+0xb44/0xe44<br /> binder_transaction+0x29b4/0x7fbc<br /> binder_thread_write+0x1708/0x442c<br /> binder_ioctl+0x1b50/0x2900<br /> [...]<br /> ==================================================================<br /> <br /> Fix this issue by marking proc-&gt;map NULL in dbitmap_free().

*** Pendiente de traducción *** microCLAUDIA in v3.2.0 and prior has an improper access control vulnerability.<br /> <br /> This flaw allows an authenticated user to perform unauthorized actions on other organizations&amp;#39; systems by sending direct API requests. To do so, the attacker can use organization identifiers obtained through a compromised endpoint or deduced manually.<br /> <br /> This vulnerability allows access between tenants, enabling an attacker to list and manage remote assets, uninstall agents, and even delete vaccines configurations.

*** Pendiente de traducción *** Multiple CSRF attack vectors in JDownloads component 1.0.0-4.0.47 for Joomla were discovered.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on node footer for non inode dnode<br /> <br /> As syzbot reported below:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/file.c:1243!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 5354 Comm: syz.0.0 Not tainted 6.17.0-rc1-syzkaller-00211-g90d970cade8e #0 PREEMPT(full)<br /> RIP: 0010:f2fs_truncate_hole+0x69e/0x6c0 fs/f2fs/file.c:1243<br /> Call Trace:<br /> <br /> f2fs_punch_hole+0x2db/0x330 fs/f2fs/file.c:1306<br /> f2fs_fallocate+0x546/0x990 fs/f2fs/file.c:2018<br /> vfs_fallocate+0x666/0x7e0 fs/open.c:342<br /> ksys_fallocate fs/open.c:366 [inline]<br /> __do_sys_fallocate fs/open.c:371 [inline]<br /> __se_sys_fallocate fs/open.c:369 [inline]<br /> __x64_sys_fallocate+0xc0/0x110 fs/open.c:369<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f1e65f8ebe9<br /> <br /> w/ a fuzzed image, f2fs may encounter panic due to it detects inconsistent<br /> truncation range in direct node in f2fs_truncate_hole().<br /> <br /> The root cause is: a non-inode dnode may has the same footer.ino and<br /> footer.nid, so the dnode will be parsed as an inode, then ADDRS_PER_PAGE()<br /> may return wrong blkaddr count which may be 923 typically, by chance,<br /> dn.ofs_in_node is equal to 923, then count can be calculated to 0 in below<br /> statement, later it will trigger panic w/ f2fs_bug_on(, count == 0 || ...).<br /> <br /> count = min(end_offset - dn.ofs_in_node, pg_end - pg_start);<br /> <br /> This patch introduces a new node_type NODE_TYPE_NON_INODE, then allowing<br /> passing the new_type to sanity_check_node_footer in f2fs_get_node_folio()<br /> to detect corruption that a non-inode dnode has the same footer.ino and<br /> footer.nid.<br /> <br /> Scripts to reproduce:<br /> mkfs.f2fs -f /dev/vdb<br /> mount /dev/vdb /mnt/f2fs<br /> touch /mnt/f2fs/foo<br /> touch /mnt/f2fs/bar<br /> dd if=/dev/zero of=/mnt/f2fs/foo bs=1M count=8<br /> umount /mnt/f2fs<br /> inject.f2fs --node --mb i_nid --nid 4 --idx 0 --val 5 /dev/vdb<br /> mount /dev/vdb /mnt/f2fs<br /> xfs_io /mnt/f2fs/foo -c "fpunch 6984k 4k"

*** Pendiente de traducción *** Webserver crash caused by scanning on TCP port 80 in Softing Industrial Automation GmbH gateways and switch.This issue affects<br /> <br /> smartLink HW-PN: from 1.02 through 1.03<br /> <br /> smartLink HW-DP: 1.31

*** Pendiente de traducción *** Improper locking vulnerability in Softing Industrial Automation GmbH gateways allows infected memory and/or resource leak exposure.This issue affects<br /> <br /> smartLink HW-PN: from 1.02 through 1.03<br /> <br /> smartLink HW-DP: 1.31