Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exec: Fix ToCToU between perm check and set-uid/gid usage<br /> <br /> When opening a file for exec via do_filp_open(), permission checking is<br /> done against the file&amp;#39;s metadata at that moment, and on success, a file<br /> pointer is passed back. Much later in the execve() code path, the file<br /> metadata (specifically mode, uid, and gid) is used to determine if/how<br /> to set the uid and gid. However, those values may have changed since the<br /> permissions check, meaning the execution may gain unintended privileges.<br /> <br /> For example, if a file could change permissions from executable and not<br /> set-id:<br /> <br /> ---------x 1 root root 16048 Aug 7 13:16 target<br /> <br /> to set-id and non-executable:<br /> <br /> ---S------ 1 root root 16048 Aug 7 13:16 target<br /> <br /> it is possible to gain root privileges when execution should have been<br /> disallowed.<br /> <br /> While this race condition is rare in real-world scenarios, it has been<br /> observed (and proven exploitable) when package managers are updating<br /> the setuid bits of installed programs. Such files start with being<br /> world-executable but then are adjusted to be group-exec with a set-uid<br /> bit. For example, "chmod o-x,u+s target" makes "target" executable only<br /> by uid "root" and gid "cdrom", while also becoming setuid-root:<br /> <br /> -rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target<br /> <br /> becomes:<br /> <br /> -rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target<br /> <br /> But racing the chmod means users without group "cdrom" membership can<br /> get the permission to execute "target" just before the chmod, and when<br /> the chmod finishes, the exec reaches brpm_fill_uid(), and performs the<br /> setuid to root, violating the expressed authorization of "only cdrom<br /> group members can setuid to root".<br /> <br /> Re-check that we still have execute permissions in case the metadata<br /> has changed. It would be better to keep a copy from the perm-check time,<br /> but until we can do that refactoring, the least-bad option is to do a<br /> full inode_permission() call (under inode lock). It is understood that<br /> this is safe against dead-locks, but hardly optimal.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: Fix soft lockup under heavy CEQE load<br /> <br /> CEQEs are handled in interrupt handler currently. This may cause the<br /> CPU core staying in interrupt context too long and lead to soft lockup<br /> under heavy load.<br /> <br /> Handle CEQEs in BH workqueue and set an upper limit for the number of<br /> CEQE handled by a single call of work handler.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - Fix null pointer dereference in __sev_snp_shutdown_locked<br /> <br /> Fix a null pointer dereference induced by DEBUG_TEST_DRIVER_REMOVE.<br /> Return from __sev_snp_shutdown_locked() if the psp_device or the<br /> sev_device structs are not initialized. Without the fix, the driver will<br /> produce the following splat:<br /> <br /> ccp 0000:55:00.5: enabling device (0000 -&gt; 0002)<br /> ccp 0000:55:00.5: sev enabled<br /> ccp 0000:55:00.5: psp enabled<br /> BUG: kernel NULL pointer dereference, address: 00000000000000f0<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI<br /> CPU: 262 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc1+ #29<br /> RIP: 0010:__sev_snp_shutdown_locked+0x2e/0x150<br /> Code: 00 55 48 89 e5 41 57 41 56 41 54 53 48 83 ec 10 41 89 f7 49 89 fe 65 48 8b 04 25 28 00 00 00 48 89 45 d8 48 8b 05 6a 5a 7f 06 8b a0 f0 00 00 00 41 0f b6 9c 24 a2 00 00 00 48 83 fb 02 0f 83<br /> RSP: 0018:ffffb2ea4014b7b8 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: ffff9e4acd2e0a28 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2ea4014b808<br /> RBP: ffffb2ea4014b7e8 R08: 0000000000000106 R09: 000000000003d9c0<br /> R10: 0000000000000001 R11: ffffffffa39ff070 R12: ffff9e49d40590c8<br /> R13: 0000000000000000 R14: ffffb2ea4014b808 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff9e58b1e00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000000000f0 CR3: 0000000418a3e001 CR4: 0000000000770ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die_body+0x6f/0xb0<br /> ? __die+0xcc/0xf0<br /> ? page_fault_oops+0x330/0x3a0<br /> ? save_trace+0x2a5/0x360<br /> ? do_user_addr_fault+0x583/0x630<br /> ? exc_page_fault+0x81/0x120<br /> ? asm_exc_page_fault+0x2b/0x30<br /> ? __sev_snp_shutdown_locked+0x2e/0x150<br /> __sev_firmware_shutdown+0x349/0x5b0<br /> ? pm_runtime_barrier+0x66/0xe0<br /> sev_dev_destroy+0x34/0xb0<br /> psp_dev_destroy+0x27/0x60<br /> sp_destroy+0x39/0x90<br /> sp_pci_remove+0x22/0x60<br /> pci_device_remove+0x4e/0x110<br /> really_probe+0x271/0x4e0<br /> __driver_probe_device+0x8f/0x160<br /> driver_probe_device+0x24/0x120<br /> __driver_attach+0xc7/0x280<br /> ? driver_attach+0x30/0x30<br /> bus_for_each_dev+0x10d/0x130<br /> driver_attach+0x22/0x30<br /> bus_add_driver+0x171/0x2b0<br /> ? unaccepted_memory_init_kdump+0x20/0x20<br /> driver_register+0x67/0x100<br /> __pci_register_driver+0x83/0x90<br /> sp_pci_init+0x22/0x30<br /> sp_mod_init+0x13/0x30<br /> do_one_initcall+0xb8/0x290<br /> ? sched_clock_noinstr+0xd/0x10<br /> ? local_clock_noinstr+0x3e/0x100<br /> ? stack_depot_save_flags+0x21e/0x6a0<br /> ? local_clock+0x1c/0x60<br /> ? stack_depot_save_flags+0x21e/0x6a0<br /> ? sched_clock_noinstr+0xd/0x10<br /> ? local_clock_noinstr+0x3e/0x100<br /> ? __lock_acquire+0xd90/0xe30<br /> ? sched_clock_noinstr+0xd/0x10<br /> ? local_clock_noinstr+0x3e/0x100<br /> ? __create_object+0x66/0x100<br /> ? local_clock+0x1c/0x60<br /> ? __create_object+0x66/0x100<br /> ? parameq+0x1b/0x90<br /> ? parse_one+0x6d/0x1d0<br /> ? parse_args+0xd7/0x1f0<br /> ? do_initcall_level+0x180/0x180<br /> do_initcall_level+0xb0/0x180<br /> do_initcalls+0x60/0xa0<br /> ? kernel_init+0x1f/0x1d0<br /> do_basic_setup+0x41/0x50<br /> kernel_init_freeable+0x1ac/0x230<br /> ? rest_init+0x1f0/0x1f0<br /> kernel_init+0x1f/0x1d0<br /> ? rest_init+0x1f0/0x1f0<br /> ret_from_fork+0x3d/0x50<br /> ? rest_init+0x1f0/0x1f0<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> Modules linked in:<br /> CR2: 00000000000000f0<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:__sev_snp_shutdown_locked+0x2e/0x150<br /> Code: 00 55 48 89 e5 41 57 41 56 41 54 53 48 83 ec 10 41 89 f7 49 89 fe 65 48 8b 04 25 28 00 00 00 48 89 45 d8 48 8b 05 6a 5a 7f 06 8b a0 f0 00 00 00 41 0f b6 9c 24 a2 00 00 00 48 83 fb 02 0f 83<br /> RSP: 0018:ffffb2ea4014b7b8 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: ffff9e4acd2e0a28 RCX: 0000000000000000<br /> RDX: 0000000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Fix event leak upon exec and file release<br /> <br /> The perf pending task work is never waited upon the matching event<br /> release. In the case of a child event, released via free_event()<br /> directly, this can potentially result in a leaked event, such as in the<br /> following scenario that doesn&amp;#39;t even require a weak IRQ work<br /> implementation to trigger:<br /> <br /> schedule()<br /> prepare_task_switch()<br /> =======&gt; <br /> perf_event_overflow()<br /> event-&gt;pending_sigtrap = ...<br /> irq_work_queue(&amp;event-&gt;pending_irq)<br /> pending_sigtrap = 0;<br /> atomic_long_inc_not_zero(&amp;event-&gt;refcount)<br /> task_work_add(&amp;event-&gt;pending_task)<br /> finish_lock_switch()<br /> =======&gt; <br /> perf_pending_irq()<br /> //do nothing, rely on pending task work<br /> refcount, 1, 0) != 1)<br /> // event is leaked<br /> <br /> Similar scenarios can also happen with perf_event_remove_on_exec() or<br /> simply against concurrent perf_event_release().<br /> <br /> Fix this with synchonizing against the possibly remaining pending task<br /> work while freeing the event, just like is done with remaining pending<br /> IRQ work. This means that the pending task callback neither need nor<br /> should hold a reference to the event, preventing it from ever beeing<br /> freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Fix event leak upon exit<br /> <br /> When a task is scheduled out, pending sigtrap deliveries are deferred<br /> to the target task upon resume to userspace via task_work.<br /> <br /> However failures while adding an event&amp;#39;s callback to the task_work<br /> engine are ignored. And since the last call for events exit happen<br /> after task work is eventually closed, there is a small window during<br /> which pending sigtrap can be queued though ignored, leaking the event<br /> refcount addition such as in the following scenario:<br /> <br /> TASK A<br /> -----<br /> <br /> do_exit()<br /> exit_task_work(tsk);<br /> <br /> <br /> perf_event_overflow()<br /> event-&gt;pending_sigtrap = pending_id;<br /> irq_work_queue(&amp;event-&gt;pending_irq);<br /> <br /> =========&gt; PREEMPTION: TASK A -&gt; TASK B<br /> event_sched_out()<br /> event-&gt;pending_sigtrap = 0;<br /> atomic_long_inc_not_zero(&amp;event-&gt;refcount)<br /> // FAILS: task work has exited<br /> task_work_add(&amp;event-&gt;pending_task)<br /> [...]<br /> <br /> perf_pending_irq()<br /> // early return: event-&gt;oncpu = -1<br /> <br /> [...]<br /> =========&gt; TASK B -&gt; TASK A<br /> perf_event_exit_task(tsk)<br /> perf_event_exit_event()<br /> free_event()<br /> WARN(atomic_long_cmpxchg(&amp;event-&gt;refcount, 1, 0) != 1)<br /> // leak event due to unexpected refcount == 2<br /> <br /> As a result the event is never released while the task exits.<br /> <br /> Fix this with appropriate task_work_add()&amp;#39;s error handling.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> devres: Fix memory leakage caused by driver API devm_free_percpu()<br /> <br /> It will cause memory leakage when use driver API devm_free_percpu()<br /> to free memory allocated by devm_alloc_percpu(), fixed by using<br /> devres_release() instead of devres_destroy() within devm_free_percpu().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost/vsock: always initialize seqpacket_allow<br /> <br /> There are two issues around seqpacket_allow:<br /> 1. seqpacket_allow is not initialized when socket is<br /> created. Thus if features are never set, it will be<br /> read uninitialized.<br /> 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared,<br /> then seqpacket_allow will not be cleared appropriately<br /> (existing apps I know about don&amp;#39;t usually do this but<br /> it&amp;#39;s legal and there&amp;#39;s no way to be sure no one relies<br /> on this).<br /> <br /> To fix:<br /> - initialize seqpacket_allow after allocation<br /> - set it unconditionally in set_features

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: Clean up error handling in vpci_scan_bus()<br /> <br /> Smatch complains about inconsistent NULL checking in vpci_scan_bus():<br /> <br /> drivers/pci/endpoint/functions/pci-epf-vntb.c:1024 vpci_scan_bus() error: we previously assumed &amp;#39;vpci_bus&amp;#39; could be null (see line 1021)<br /> <br /> Instead of printing an error message and then crashing we should return<br /> an error code and clean up.<br /> <br /> Also the NULL check is reversed so it prints an error for success<br /> instead of failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: rcar: Demote WARN() to dev_warn_ratelimited() in rcar_pcie_wakeup()<br /> <br /> Avoid large backtrace, it is sufficient to warn the user that there has<br /> been a link problem. Either the link has failed and the system is in need<br /> of maintenance, or the link continues to work and user has been informed.<br /> The message from the warning can be looked up in the sources.<br /> <br /> This makes an actual link issue less verbose.<br /> <br /> First of all, this controller has a limitation in that the controller<br /> driver has to assist the hardware with transition to L1 link state by<br /> writing L1IATN to PMCTRL register, the L1 and L0 link state switching<br /> is not fully automatic on this controller.<br /> <br /> In case of an ASMedia ASM1062 PCIe SATA controller which does not support<br /> ASPM, on entry to suspend or during platform pm_test, the SATA controller<br /> enters D3hot state and the link enters L1 state. If the SATA controller<br /> wakes up before rcar_pcie_wakeup() was called and returns to D0, the link<br /> returns to L0 before the controller driver even started its transition to<br /> L1 link state. At this point, the SATA controller did send an PM_ENTER_L1<br /> DLLP to the PCIe controller and the PCIe controller received it, and the<br /> PCIe controller did set PMSR PMEL1RX bit.<br /> <br /> Once rcar_pcie_wakeup() is called, if the link is already back in L0 state<br /> and PMEL1RX bit is set, the controller driver has no way to determine if<br /> it should perform the link transition to L1 state, or treat the link as if<br /> it is in L0 state. Currently the driver attempts to perform the transition<br /> to L1 link state unconditionally, which in this specific case fails with a<br /> PMSR L1FAEG poll timeout, however the link still works as it is already<br /> back in L0 state.<br /> <br /> Reduce this warning verbosity. In case the link is really broken, the<br /> rcar_pcie_config_access() would fail, otherwise it will succeed and any<br /> system with this controller and ASM1062 can suspend without generating<br /> a backtrace.

A vulnerability was found in Genexis Tilgin Home Gateway 322_AS0500-03_05_13_05. It has been rated as problematic. This issue affects some unknown processing of the file /vood/cgi-bin/vood_view.cgi?lang=EN&amp;act=user/spec_conf&amp;sessionId=86213915328111654515&amp;user=A&amp;message2user=Account%20updated. The manipulation of the argument Phone Number leads to cross site scripting. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability classified as critical has been found in chillzhuang SpringBlade 4.1.0. Affected is an unknown function of the file /api/blade-system/menu/list?updatexml. The manipulation leads to sql injection. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Always drain health in shutdown callback<br /> <br /> There is no point in recovery during device shutdown. if health<br /> work started need to wait for it to avoid races and NULL pointer<br /> access.<br /> <br /> Hence, drain health WQ on shutdown callback.