Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_reject: don&amp;#39;t leak dst refcount for loopback packets<br /> <br /> recent patches to add a WARN() when replacing skb dst entry found an<br /> old bug:<br /> <br /> WARNING: include/linux/skbuff.h:1165 skb_dst_check_unset include/linux/skbuff.h:1164 [inline]<br /> WARNING: include/linux/skbuff.h:1165 skb_dst_set include/linux/skbuff.h:1210 [inline]<br /> WARNING: include/linux/skbuff.h:1165 nf_reject_fill_skb_dst+0x2a4/0x330 net/ipv4/netfilter/nf_reject_ipv4.c:234<br /> [..]<br /> Call Trace:<br /> nf_send_unreach+0x17b/0x6e0 net/ipv4/netfilter/nf_reject_ipv4.c:325<br /> nft_reject_inet_eval+0x4bc/0x690 net/netfilter/nft_reject_inet.c:27<br /> expr_call_ops_eval net/netfilter/nf_tables_core.c:237 [inline]<br /> ..<br /> <br /> This is because blamed commit forgot about loopback packets.<br /> Such packets already have a dst_entry attached, even at PRE_ROUTING stage.<br /> <br /> Instead of checking hook just check if the skb already has a route<br /> attached to it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix vm_bind_ioctl double free bug<br /> <br /> If the argument check during an array bind fails, the bind_ops are freed<br /> twice as seen below. Fix this by setting bind_ops to NULL after freeing.<br /> <br /> ==================================================================<br /> BUG: KASAN: double-free in xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> Free of addr ffff88813bb9b800 by task xe_vm/14198<br /> <br /> CPU: 5 UID: 0 PID: 14198 Comm: xe_vm Not tainted 6.16.0-xe-eudebug-cmanszew+ #520 PREEMPT(full)<br /> Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP, BIOS ADLPFWI1.R00.2411.A02.2110081023 10/08/2021<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x82/0xd0<br /> print_report+0xcb/0x610<br /> ? __virt_addr_valid+0x19a/0x300<br /> ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> kasan_report_invalid_free+0xc8/0xf0<br /> ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> check_slab_allocation+0x102/0x130<br /> kfree+0x10d/0x440<br /> ? should_fail_ex+0x57/0x2f0<br /> ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]<br /> ? __lock_acquire+0xab9/0x27f0<br /> ? lock_acquire+0x165/0x300<br /> ? drm_dev_enter+0x53/0xe0 [drm]<br /> ? find_held_lock+0x2b/0x80<br /> ? drm_dev_exit+0x30/0x50 [drm]<br /> ? drm_ioctl_kernel+0x128/0x1c0 [drm]<br /> drm_ioctl_kernel+0x128/0x1c0 [drm]<br /> ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]<br /> ? find_held_lock+0x2b/0x80<br /> ? __pfx_drm_ioctl_kernel+0x10/0x10 [drm]<br /> ? should_fail_ex+0x57/0x2f0<br /> ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]<br /> drm_ioctl+0x352/0x620 [drm]<br /> ? __pfx_drm_ioctl+0x10/0x10 [drm]<br /> ? __pfx_rpm_resume+0x10/0x10<br /> ? do_raw_spin_lock+0x11a/0x1b0<br /> ? find_held_lock+0x2b/0x80<br /> ? __pm_runtime_resume+0x61/0xc0<br /> ? rcu_is_watching+0x20/0x50<br /> ? trace_irq_enable.constprop.0+0xac/0xe0<br /> xe_drm_ioctl+0x91/0xc0 [xe]<br /> __x64_sys_ioctl+0xb2/0x100<br /> ? rcu_is_watching+0x20/0x50<br /> do_syscall_64+0x68/0x2e0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fa9acb24ded<br /> <br /> (cherry picked from commit a01b704527c28a2fd43a17a85f8996b75ec8492a)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/mm: Do not map lowcore with identity mapping<br /> <br /> Since the identity mapping is pinned to address zero the lowcore is always<br /> also mapped to address zero, this happens regardless of the relocate_lowcore<br /> command line option. If the option is specified the lowcore is mapped<br /> twice, instead of only once.<br /> <br /> This means that NULL pointer accesses will succeed instead of causing an<br /> exception (low address protection still applies, but covers only parts).<br /> To fix this never map the first two pages of physical memory with the<br /> identity mapping.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix UAF on smcsk after smc_listen_out()<br /> <br /> BPF CI testing report a UAF issue:<br /> <br /> [ 16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003 0<br /> [ 16.447134] #PF: supervisor read access in kernel mod e<br /> [ 16.447516] #PF: error_code(0x0000) - not-present pag e<br /> [ 16.447878] PGD 0 P4D 0<br /> [ 16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT I<br /> [ 16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G OE 6.13.0-rc3-g89e8a75fda73-dirty #4 2<br /> [ 16.449124] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODUL E<br /> [ 16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201 4<br /> [ 16.450201] Workqueue: smc_hs_wq smc_listen_wor k<br /> [ 16.450531] RIP: 0010:smc_listen_work+0xc02/0x159 0<br /> [ 16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024 6<br /> [ 16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030 0<br /> [ 16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000 0<br /> [ 16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000 5<br /> [ 16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640 0<br /> [ 16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092 0<br /> [ 16.454996] FS: 0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000 0<br /> [ 16.455557] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3<br /> [ 16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef 0<br /> [ 16.456459] PKRU: 5555555 4<br /> [ 16.456654] Call Trace :<br /> [ 16.456832] <br /> [ 16.456989] ? __die+0x23/0x7 0<br /> [ 16.457215] ? page_fault_oops+0x180/0x4c 0<br /> [ 16.457508] ? __lock_acquire+0x3e6/0x249 0<br /> [ 16.457801] ? exc_page_fault+0x68/0x20 0<br /> [ 16.458080] ? asm_exc_page_fault+0x26/0x3 0<br /> [ 16.458389] ? smc_listen_work+0xc02/0x159 0<br /> [ 16.458689] ? smc_listen_work+0xc02/0x159 0<br /> [ 16.458987] ? lock_is_held_type+0x8f/0x10 0<br /> [ 16.459284] process_one_work+0x1ea/0x6d 0<br /> [ 16.459570] worker_thread+0x1c3/0x38 0<br /> [ 16.459839] ? __pfx_worker_thread+0x10/0x1 0<br /> [ 16.460144] kthread+0xe0/0x11 0<br /> [ 16.460372] ? __pfx_kthread+0x10/0x1 0<br /> [ 16.460640] ret_from_fork+0x31/0x5 0<br /> [ 16.460896] ? __pfx_kthread+0x10/0x1 0<br /> [ 16.461166] ret_from_fork_asm+0x1a/0x3 0<br /> [ 16.461453] <br /> [ 16.461616] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE) ]<br /> [ 16.462134] CR2: 000000000000003 0<br /> [ 16.462380] ---[ end trace 0000000000000000 ]---<br /> [ 16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590<br /> <br /> The direct cause of this issue is that after smc_listen_out_connected(),<br /> newclcsock-&gt;sk may be NULL since it will releases the smcsk. Therefore,<br /> if the application closes the socket immediately after accept,<br /> newclcsock-&gt;sk can be NULL. A possible execution order could be as<br /> follows:<br /> <br /> smc_listen_work | userspace<br /> -----------------------------------------------------------------<br /> lock_sock(sk) |<br /> smc_listen_out_connected() |<br /> | \- smc_listen_out |<br /> | | \- release_sock |<br /> | |- sk-&gt;sk_data_ready() |<br /> | fd = accept();<br /> | close(fd);<br /> | \- socket-&gt;sk = NULL;<br /> /* newclcsock-&gt;sk is NULL now */<br /> SMC_STAT_SERV_SUCC_INC(sock_net(newclcsock-&gt;sk))<br /> <br /> Since smc_listen_out_connected() will not fail, simply swapping the order<br /> of the code can easily fix this issue.

PTZOptics and possibly other ValueHD-based pan-tilt-zoom cameras use hard-coded, default administrative credentials. The passwords can readily be cracked. Many cameras have SSH or telnet listening on all interfaces. The passwords cannot be changed by the user, nor can the SSH or telnet service be disabled by the user.

ECOVACS robot vacuums and base stations communicate via an insecure Wi-Fi network with a deterministic WPA2-PSK, which can be easily derived.

ECOVACS vacuum robot base stations do not validate firmware updates, so malicious over-the-air updates can be sent to base station via insecure connection between robot and base station.

ECOVACS robot vacuums and base stations communicate via an insecure Wi-Fi network with a deterministic AES encryption key, which can be easily derived.

A flaw has been found in elunez eladmin up to 2.7. This impacts the function updateUserEmail of the file /api/users/updateEmail/ of the component Email Address Handler. Executing manipulation of the argument id/email can lead to improper authorization. The attack may be performed from remote. Attacks of this nature are highly complex. The exploitability is said to be difficult. The exploit has been published and may be used. It is required to know the RSA-encrypted password of the attacked user account.

The sequence of packets received by a Networking server are not correctly checked.<br /> <br /> An attacker could exploit this vulnerability to send specially crafted messages to force the application to stop.

Some payload elements of the messages sent between two stations in a networking architecture are not properly checked on the receiving station allowing an attacker to execute unauthorized commands in the application.

Rejected reason: The unisharp/laravel-filemanager is a separate project, unrelated to laravel-filemanager.