Vulnerabilities

An issue was discovered in UCI IDOL 2 (aka uciIDOL or IDOL2) through 2.12. Due to improper input validation, improper deserialization, and improper restriction of operations within the bounds of a memory buffer, IDOL2 is vulnerable to Denial-of-Service (DoS) attacks and possibly remote code execution. A certain XmlMessage document causes 100% CPU consumption.

An issue was discovered in UCI IDOL 2 (aka uciIDOL or IDOL2) through 2.12. Due to improper input validation, improper deserialization, and improper restriction of operations within the bounds of a memory buffer, IDOL2 is vulnerable to Denial-of-Service (DoS) attacks and possibly remote code execution. There is an access violation and EIP overwrite after five logins.

An issue was discovered in UCI IDOL 2 (aka uciIDOL or IDOL2) through 2.12. Data is sent between client and server with encryption. However, the key is derived from the string "(c)2007 UCI Software GmbH B.Boll" (without quotes). The key is both static and hardcoded. With access to messages, this results in message decryption and encryption by an attacker. Thus, it enables passive and active man-in-the-middle attacks.

The Mirai botnet through 2024-08-19 mishandles simultaneous TCP connections to the CNC (command and control) server. Unauthenticated sessions remain open, causing resource consumption. For example, an attacker can send a recognized username (such as root), or can send arbitrary data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86/mmu: make apf token non-zero to fix bug<br /> <br /> In current async pagefault logic, when a page is ready, KVM relies on<br /> kvm_arch_can_dequeue_async_page_present() to determine whether to deliver<br /> a READY event to the Guest. This function test token value of struct<br /> kvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when a<br /> READY event is finished by Guest. If value is zero meaning that a READY<br /> event is done, so the KVM can deliver another.<br /> But the kvm_arch_setup_async_pf() may produce a valid token with zero<br /> value, which is confused with previous mention and may lead the loss of<br /> this READY event.<br /> <br /> This bug may cause task blocked forever in Guest:<br /> INFO: task stress:7532 blocked for more than 1254 seconds.<br /> Not tainted 5.10.0 #16<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:stress state:D stack: 0 pid: 7532 ppid: 1409<br /> flags:0x00000080<br /> Call Trace:<br /> __schedule+0x1e7/0x650<br /> schedule+0x46/0xb0<br /> kvm_async_pf_task_wait_schedule+0xad/0xe0<br /> ? exit_to_user_mode_prepare+0x60/0x70<br /> __kvm_handle_async_pf+0x4f/0xb0<br /> ? asm_exc_page_fault+0x8/0x30<br /> exc_page_fault+0x6f/0x110<br /> ? asm_exc_page_fault+0x8/0x30<br /> asm_exc_page_fault+0x1e/0x30<br /> RIP: 0033:0x402d00<br /> RSP: 002b:00007ffd31912500 EFLAGS: 00010206<br /> RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0<br /> RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0<br /> RBP: 00000000021262b0 R08: 0000000000000003 R09: 0000000000000086<br /> R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000<br /> R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: Handle failure to register sensor with thermal zone correctly<br /> <br /> If an attempt is made to a sensor with a thermal zone and it fails,<br /> the call to devm_thermal_zone_of_sensor_register() may return -ENODEV.<br /> This may result in crashes similar to the following.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 00000000000003cd<br /> ...<br /> Internal error: Oops: 96000021 [#1] PREEMPT SMP<br /> ...<br /> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : mutex_lock+0x18/0x60<br /> lr : thermal_zone_device_update+0x40/0x2e0<br /> sp : ffff800014c4fc60<br /> x29: ffff800014c4fc60 x28: ffff365ee3f6e000 x27: ffffdde218426790<br /> x26: ffff365ee3f6e000 x25: 0000000000000000 x24: ffff365ee3f6e000<br /> x23: ffffdde218426870 x22: ffff365ee3f6e000 x21: 00000000000003cd<br /> x20: ffff365ee8bf3308 x19: ffffffffffffffed x18: 0000000000000000<br /> x17: ffffdde21842689c x16: ffffdde1cb7a0b7c x15: 0000000000000040<br /> x14: ffffdde21a4889a0 x13: 0000000000000228 x12: 0000000000000000<br /> x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000<br /> x8 : 0000000001120000 x7 : 0000000000000001 x6 : 0000000000000000<br /> x5 : 0068000878e20f07 x4 : 0000000000000000 x3 : 00000000000003cd<br /> x2 : ffff365ee3f6e000 x1 : 0000000000000000 x0 : 00000000000003cd<br /> Call trace:<br /> mutex_lock+0x18/0x60<br /> hwmon_notify_event+0xfc/0x110<br /> 0xffffdde1cb7a0a90<br /> 0xffffdde1cb7a0b7c<br /> irq_thread_fn+0x2c/0xa0<br /> irq_thread+0x134/0x240<br /> kthread+0x178/0x190<br /> ret_from_fork+0x10/0x20<br /> Code: d503201f d503201f d2800001 aa0103e4 (c8e47c02)<br /> <br /> Jon Hunter reports that the exact call sequence is:<br /> <br /> hwmon_notify_event()<br /> --&gt; hwmon_thermal_notify()<br /> --&gt; thermal_zone_device_update()<br /> --&gt; update_temperature()<br /> --&gt; mutex_lock()<br /> <br /> The hwmon core needs to handle all errors returned from calls<br /> to devm_thermal_zone_of_sensor_register(). If the call fails<br /> with -ENODEV, report that the sensor was not attached to a<br /> thermal zone but continue to register the hwmon device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: add a schedule point in io_add_buffers()<br /> <br /> Looping ~65535 times doing kmalloc() calls can trigger soft lockups,<br /> especially with DEBUG features (like KASAN).<br /> <br /> [ 253.536212] watchdog: BUG: soft lockup - CPU#64 stuck for 26s! [b219417889:12575]<br /> [ 253.544433] Modules linked in: vfat fat i2c_mux_pca954x i2c_mux spidev cdc_acm xhci_pci xhci_hcd sha3_generic gq(O)<br /> [ 253.544451] CPU: 64 PID: 12575 Comm: b219417889 Tainted: G S O 5.17.0-smp-DEV #801<br /> [ 253.544457] RIP: 0010:kernel_text_address (./include/asm-generic/sections.h:192 ./include/linux/kallsyms.h:29 kernel/extable.c:67 kernel/extable.c:98)<br /> [ 253.544464] Code: 0f 93 c0 48 c7 c1 e0 63 d7 a4 48 39 cb 0f 92 c1 20 c1 0f b6 c1 5b 5d c3 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 53 48 89 fb c7 c0 00 00 80 a0 41 be 01 00 00 00 48 39 c7 72 0c 48 c7 c0 40<br /> [ 253.544468] RSP: 0018:ffff8882d8baf4c0 EFLAGS: 00000246<br /> [ 253.544471] RAX: 1ffff1105b175e00 RBX: ffffffffa13ef09a RCX: 00000000a13ef001<br /> [ 253.544474] RDX: ffffffffa13ef09a RSI: ffff8882d8baf558 RDI: ffffffffa13ef09a<br /> [ 253.544476] RBP: ffff8882d8baf4d8 R08: ffff8882d8baf5e0 R09: 0000000000000004<br /> [ 253.544479] R10: ffff8882d8baf5e8 R11: ffffffffa0d59a50 R12: ffff8882eab20380<br /> [ 253.544481] R13: ffffffffa0d59a50 R14: dffffc0000000000 R15: 1ffff1105b175eb0<br /> [ 253.544483] FS: 00000000016d3380(0000) GS:ffff88af48c00000(0000) knlGS:0000000000000000<br /> [ 253.544486] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 253.544488] CR2: 00000000004af0f0 CR3: 00000002eabfa004 CR4: 00000000003706e0<br /> [ 253.544491] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 253.544492] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 253.544494] Call Trace:<br /> [ 253.544496] <br /> [ 253.544498] ? io_queue_sqe (fs/io_uring.c:7143)<br /> [ 253.544505] __kernel_text_address (kernel/extable.c:78)<br /> [ 253.544508] unwind_get_return_address (arch/x86/kernel/unwind_frame.c:19)<br /> [ 253.544514] arch_stack_walk (arch/x86/kernel/stacktrace.c:27)<br /> [ 253.544517] ? io_queue_sqe (fs/io_uring.c:7143)<br /> [ 253.544521] stack_trace_save (kernel/stacktrace.c:123)<br /> [ 253.544527] ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515)<br /> [ 253.544531] ? ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515)<br /> [ 253.544533] ? __kasan_kmalloc (mm/kasan/common.c:524)<br /> [ 253.544535] ? kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567)<br /> [ 253.544541] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)<br /> [ 253.544544] ? __io_queue_sqe (fs/io_uring.c:?)<br /> [ 253.544551] __kasan_kmalloc (mm/kasan/common.c:524)<br /> [ 253.544553] kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567)<br /> [ 253.544556] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)<br /> [ 253.544560] io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)<br /> [ 253.544564] ? __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)<br /> [ 253.544567] ? __kasan_slab_alloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)<br /> [ 253.544569] ? kmem_cache_alloc_bulk (mm/slab.h:732 mm/slab.c:3546)<br /> [ 253.544573] ? __io_alloc_req_refill (fs/io_uring.c:2078)<br /> [ 253.544578] ? io_submit_sqes (fs/io_uring.c:7441)<br /> [ 253.544581] ? __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uring.c:10096)<br /> [ 253.544584] ? __x64_sys_io_uring_enter (fs/io_uring.c:10096)<br /> [ 253.544587] ? do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)<br /> [ 253.544590] ? entry_SYSCALL_64_after_hwframe (??:?)<br /> [ 253.544596] __io_queue_sqe (fs/io_uring.c:?)<br /> [ 253.544600] io_queue_sqe (fs/io_uring.c:7143)<br /> [ 253.544603] io_submit_sqe (fs/io_uring.c:?)<br /> [ 253.544608] io_submit_sqes (fs/io_uring.c:?)<br /> [ 253.544612] __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uri<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> CDC-NCM: avoid overflow in sanity checking<br /> <br /> A broken device may give an extreme offset like 0xFFF0<br /> and a reasonable length for a fragment. In the sanity<br /> check as formulated now, this will create an integer<br /> overflow, defeating the sanity check. Both offset<br /> and offset + len need to be checked in such a manner<br /> that no overflow can occur.<br /> And those quantities should be unsigned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Add schedule points in batch ops<br /> <br /> syzbot reported various soft lockups caused by bpf batch operations.<br /> <br /> INFO: task kworker/1:1:27 blocked for more than 140 seconds.<br /> INFO: task hung in rcu_barrier<br /> <br /> Nothing prevents batch ops to process huge amount of data,<br /> we need to add schedule points in them.<br /> <br /> Note that maybe_wait_bpf_programs(map) calls from<br /> generic_map_delete_batch() can be factorized by moving<br /> the call after the loop.<br /> <br /> This will be done later in -next tree once we get this fix merged,<br /> unless there is strong opinion doing this optimization sooner.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix crash due to incorrect copy_map_value<br /> <br /> When both bpf_spin_lock and bpf_timer are present in a BPF map value,<br /> copy_map_value needs to skirt both objects when copying a value into and<br /> out of the map. However, the current code does not set both s_off and<br /> t_off in copy_map_value, which leads to a crash when e.g. bpf_spin_lock<br /> is placed in map value with bpf_timer, as bpf_map_update_elem call will<br /> be able to overwrite the other timer object.<br /> <br /> When the issue is not fixed, an overwriting can produce the following<br /> splat:<br /> <br /> [root@(none) bpf]# ./test_progs -t timer_crash<br /> [ 15.930339] bpf_testmod: loading out-of-tree module taints kernel.<br /> [ 16.037849] ==================================================================<br /> [ 16.038458] BUG: KASAN: user-memory-access in __pv_queued_spin_lock_slowpath+0x32b/0x520<br /> [ 16.038944] Write of size 8 at addr 0000000000043ec0 by task test_progs/325<br /> [ 16.039399]<br /> [ 16.039514] CPU: 0 PID: 325 Comm: test_progs Tainted: G OE 5.16.0+ #278<br /> [ 16.039983] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ArchLinux 1.15.0-1 04/01/2014<br /> [ 16.040485] Call Trace:<br /> [ 16.040645] <br /> [ 16.040805] dump_stack_lvl+0x59/0x73<br /> [ 16.041069] ? __pv_queued_spin_lock_slowpath+0x32b/0x520<br /> [ 16.041427] kasan_report.cold+0x116/0x11b<br /> [ 16.041673] ? __pv_queued_spin_lock_slowpath+0x32b/0x520<br /> [ 16.042040] __pv_queued_spin_lock_slowpath+0x32b/0x520<br /> [ 16.042328] ? memcpy+0x39/0x60<br /> [ 16.042552] ? pv_hash+0xd0/0xd0<br /> [ 16.042785] ? lockdep_hardirqs_off+0x95/0xd0<br /> [ 16.043079] __bpf_spin_lock_irqsave+0xdf/0xf0<br /> [ 16.043366] ? bpf_get_current_comm+0x50/0x50<br /> [ 16.043608] ? jhash+0x11a/0x270<br /> [ 16.043848] bpf_timer_cancel+0x34/0xe0<br /> [ 16.044119] bpf_prog_c4ea1c0f7449940d_sys_enter+0x7c/0x81<br /> [ 16.044500] bpf_trampoline_6442477838_0+0x36/0x1000<br /> [ 16.044836] __x64_sys_nanosleep+0x5/0x140<br /> [ 16.045119] do_syscall_64+0x59/0x80<br /> [ 16.045377] ? lock_is_held_type+0xe4/0x140<br /> [ 16.045670] ? irqentry_exit_to_user_mode+0xa/0x40<br /> [ 16.046001] ? mark_held_locks+0x24/0x90<br /> [ 16.046287] ? asm_exc_page_fault+0x1e/0x30<br /> [ 16.046569] ? asm_exc_page_fault+0x8/0x30<br /> [ 16.046851] ? lockdep_hardirqs_on+0x7e/0x100<br /> [ 16.047137] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 16.047405] RIP: 0033:0x7f9e4831718d<br /> [ 16.047602] Code: b4 0c 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d b3 6c 0c 00 f7 d8 64 89 01 48<br /> [ 16.048764] RSP: 002b:00007fff488086b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000023<br /> [ 16.049275] RAX: ffffffffffffffda RBX: 00007f9e48683740 RCX: 00007f9e4831718d<br /> [ 16.049747] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007fff488086d0<br /> [ 16.050225] RBP: 00007fff488086f0 R08: 00007fff488085d7 R09: 00007f9e4cb594a0<br /> [ 16.050648] R10: 0000000000000000 R11: 0000000000000206 R12: 00007f9e484cde30<br /> [ 16.051124] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> [ 16.051608] <br /> [ 16.051762] ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix concurrent reset and removal of VFs<br /> <br /> Commit c503e63200c6 ("ice: Stop processing VF messages during teardown")<br /> introduced a driver state flag, ICE_VF_DEINIT_IN_PROGRESS, which is<br /> intended to prevent some issues with concurrently handling messages from<br /> VFs while tearing down the VFs.<br /> <br /> This change was motivated by crashes caused while tearing down and<br /> bringing up VFs in rapid succession.<br /> <br /> It turns out that the fix actually introduces issues with the VF driver<br /> caused because the PF no longer responds to any messages sent by the VF<br /> during its .remove routine. This results in the VF potentially removing<br /> its DMA memory before the PF has shut down the device queues.<br /> <br /> Additionally, the fix doesn&amp;#39;t actually resolve concurrency issues within<br /> the ice driver. It is possible for a VF to initiate a reset just prior<br /> to the ice driver removing VFs. This can result in the remove task<br /> concurrently operating while the VF is being reset. This results in<br /> similar memory corruption and panics purportedly fixed by that commit.<br /> <br /> Fix this concurrency at its root by protecting both the reset and<br /> removal flows using the existing VF cfg_lock. This ensures that we<br /> cannot remove the VF while any outstanding critical tasks such as a<br /> virtchnl message or a reset are occurring.<br /> <br /> This locking change also fixes the root cause originally fixed by commit<br /> c503e63200c6 ("ice: Stop processing VF messages during teardown"), so we<br /> can simply revert it.<br /> <br /> Note that I kept these two changes together because simply reverting the<br /> original commit alone would leave the driver vulnerable to worse race<br /> conditions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> configfs: fix a race in configfs_{,un}register_subsystem()<br /> <br /> When configfs_register_subsystem() or configfs_unregister_subsystem()<br /> is executing link_group() or unlink_group(),<br /> it is possible that two processes add or delete list concurrently.<br /> Some unfortunate interleavings of them can cause kernel panic.<br /> <br /> One of cases is:<br /> A --&gt; B --&gt; C --&gt; D<br /> A next = next |<br /> | // prev == B<br /> | prev-&gt;next = next<br /> <br /> Fix this by adding mutex when calling link_group() or unlink_group(),<br /> but parent configfs_subsystem is NULL when config_item is root.<br /> So I create a mutex configfs_subsystem_mutex.