Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: prevent ethtool ops after shutdown<br /> <br /> A crash can occur if an ethtool operation is invoked<br /> after shutdown() is called.<br /> <br /> shutdown() is invoked during system shutdown to stop DMA operations<br /> without performing expensive deallocations. It is discouraged to<br /> unregister the netdev in this path, so the device may still be visible<br /> to userspace and kernel helpers.<br /> <br /> In gve, shutdown() tears down most internal data structures. If an<br /> ethtool operation is dispatched after shutdown(), it will dereference<br /> freed or NULL pointers, leading to a kernel panic. While graceful<br /> shutdown normally quiesces userspace before invoking the reboot<br /> syscall, forced shutdowns (as observed on GCP VMs) can still trigger<br /> this path.<br /> <br /> Fix by calling netif_device_detach() in shutdown().<br /> This marks the device as detached so the ethtool ioctl handler<br /> will skip dispatching operations to the driver.

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.

Improper Control of Filename for Include/Require Statement in PHP Program (&amp;#39;PHP Remote File Inclusion&amp;#39;) vulnerability in gavias Indutri allows PHP Local File Inclusion. This issue affects Indutri: from n/a through n/a.