Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: fix kernel crash problem in concurrent scenario<br /> <br /> When link status change, the nic driver need to notify the roce<br /> driver to handle this event, but at this time, the roce driver<br /> may uninit, then cause kernel crash.<br /> <br /> To fix the problem, when link status change, need to check<br /> whether the roce registered, and when uninit, need to wait link<br /> update finish.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: core: remove unnecessary WARN_ON() in implement()<br /> <br /> Syzkaller hit a warning [1] in a call to implement() when trying<br /> to write a value into a field of smaller size in an output report.<br /> <br /> Since implement() already has a warn message printed out with the<br /> help of hid_warn() and value in question gets trimmed with:<br /> ...<br /> value &amp;= m;<br /> ...<br /> WARN_ON may be considered superfluous. Remove it to suppress future<br /> syzkaller triggers.<br /> <br /> [1]<br /> WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]<br /> WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863<br /> Modules linked in:<br /> CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024<br /> RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]<br /> RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863<br /> ...<br /> Call Trace:<br /> <br /> __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]<br /> usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636<br /> hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:904 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: fix slab-use-after-free in cachefiles_ondemand_daemon_read()<br /> <br /> We got the following issue in a fuzz test of randomly issuing the restore<br /> command:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in cachefiles_ondemand_daemon_read+0xb41/0xb60<br /> Read of size 8 at addr ffff888122e84088 by task ondemand-04-dae/963<br /> <br /> CPU: 13 PID: 963 Comm: ondemand-04-dae Not tainted 6.8.0-dirty #564<br /> Call Trace:<br /> kasan_report+0x93/0xc0<br /> cachefiles_ondemand_daemon_read+0xb41/0xb60<br /> vfs_read+0x169/0xb50<br /> ksys_read+0xf5/0x1e0<br /> <br /> Allocated by task 116:<br /> kmem_cache_alloc+0x140/0x3a0<br /> cachefiles_lookup_cookie+0x140/0xcd0<br /> fscache_cookie_state_machine+0x43c/0x1230<br /> [...]<br /> <br /> Freed by task 792:<br /> kmem_cache_free+0xfe/0x390<br /> cachefiles_put_object+0x241/0x480<br /> fscache_cookie_state_machine+0x5c8/0x1230<br /> [...]<br /> ==================================================================<br /> <br /> Following is the process that triggers the issue:<br /> <br /> mount | daemon_thread1 | daemon_thread2<br /> ------------------------------------------------------------<br /> cachefiles_withdraw_cookie<br /> cachefiles_ondemand_clean_object(object)<br /> cachefiles_ondemand_send_req<br /> REQ_A = kzalloc(sizeof(*req) + data_len)<br /> wait_for_completion(&amp;REQ_A-&gt;done)<br /> <br /> cachefiles_daemon_read<br /> cachefiles_ondemand_daemon_read<br /> REQ_A = cachefiles_ondemand_select_req<br /> msg-&gt;object_id = req-&gt;object-&gt;ondemand-&gt;ondemand_id<br /> ------ restore ------<br /> cachefiles_ondemand_restore<br /> xas_for_each(&amp;xas, req, ULONG_MAX)<br /> xas_set_mark(&amp;xas, CACHEFILES_REQ_NEW)<br /> <br /> cachefiles_daemon_read<br /> cachefiles_ondemand_daemon_read<br /> REQ_A = cachefiles_ondemand_select_req<br /> copy_to_user(_buffer, msg, n)<br /> xa_erase(&amp;cache-&gt;reqs, id)<br /> complete(&amp;REQ_A-&gt;done)<br /> ------ close(fd) ------<br /> cachefiles_ondemand_fd_release<br /> cachefiles_put_object<br /> cachefiles_put_object<br /> kmem_cache_free(cachefiles_object_jar, object)<br /> REQ_A-&gt;object-&gt;ondemand-&gt;ondemand_id<br /> // object UAF !!!<br /> <br /> When we see the request within xa_lock, req-&gt;object must not have been<br /> freed yet, so grab the reference count of object before xa_unlock to<br /> avoid the above issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: fix slab-use-after-free in cachefiles_ondemand_get_fd()<br /> <br /> We got the following issue in a fuzz test of randomly issuing the restore<br /> command:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in cachefiles_ondemand_daemon_read+0x609/0xab0<br /> Write of size 4 at addr ffff888109164a80 by task ondemand-04-dae/4962<br /> <br /> CPU: 11 PID: 4962 Comm: ondemand-04-dae Not tainted 6.8.0-rc7-dirty #542<br /> Call Trace:<br /> kasan_report+0x94/0xc0<br /> cachefiles_ondemand_daemon_read+0x609/0xab0<br /> vfs_read+0x169/0xb50<br /> ksys_read+0xf5/0x1e0<br /> <br /> Allocated by task 626:<br /> __kmalloc+0x1df/0x4b0<br /> cachefiles_ondemand_send_req+0x24d/0x690<br /> cachefiles_create_tmpfile+0x249/0xb30<br /> cachefiles_create_file+0x6f/0x140<br /> cachefiles_look_up_object+0x29c/0xa60<br /> cachefiles_lookup_cookie+0x37d/0xca0<br /> fscache_cookie_state_machine+0x43c/0x1230<br /> [...]<br /> <br /> Freed by task 626:<br /> kfree+0xf1/0x2c0<br /> cachefiles_ondemand_send_req+0x568/0x690<br /> cachefiles_create_tmpfile+0x249/0xb30<br /> cachefiles_create_file+0x6f/0x140<br /> cachefiles_look_up_object+0x29c/0xa60<br /> cachefiles_lookup_cookie+0x37d/0xca0<br /> fscache_cookie_state_machine+0x43c/0x1230<br /> [...]<br /> ==================================================================<br /> <br /> Following is the process that triggers the issue:<br /> <br /> mount | daemon_thread1 | daemon_thread2<br /> ------------------------------------------------------------<br /> cachefiles_ondemand_init_object<br /> cachefiles_ondemand_send_req<br /> REQ_A = kzalloc(sizeof(*req) + data_len)<br /> wait_for_completion(&amp;REQ_A-&gt;done)<br /> <br /> cachefiles_daemon_read<br /> cachefiles_ondemand_daemon_read<br /> REQ_A = cachefiles_ondemand_select_req<br /> cachefiles_ondemand_get_fd<br /> copy_to_user(_buffer, msg, n)<br /> process_open_req(REQ_A)<br /> ------ restore ------<br /> cachefiles_ondemand_restore<br /> xas_for_each(&amp;xas, req, ULONG_MAX)<br /> xas_set_mark(&amp;xas, CACHEFILES_REQ_NEW);<br /> <br /> cachefiles_daemon_read<br /> cachefiles_ondemand_daemon_read<br /> REQ_A = cachefiles_ondemand_select_req<br /> <br /> write(devfd, ("copen %u,%llu", msg-&gt;msg_id, size));<br /> cachefiles_ondemand_copen<br /> xa_erase(&amp;cache-&gt;reqs, id)<br /> complete(&amp;REQ_A-&gt;done)<br /> kfree(REQ_A)<br /> cachefiles_ondemand_get_fd(REQ_A)<br /> fd = get_unused_fd_flags<br /> file = anon_inode_getfile<br /> fd_install(fd, file)<br /> load = (void *)REQ_A-&gt;msg.data;<br /> load-&gt;fd = fd;<br /> // load UAF !!!<br /> <br /> This issue is caused by issuing a restore command when the daemon is still<br /> alive, which results in a request being processed multiple times thus<br /> triggering a UAF. So to avoid this problem, add an additional reference<br /> count to cachefiles_req, which is held while waiting and reading, and then<br /> released when the waiting and reading is over.<br /> <br /> Note that since there is only one reference count for waiting, we need to<br /> avoid the same request being completed multiple times, so we can only<br /> complete the request if it is successfully removed from the xarray.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: remove requests from xarray during flushing requests<br /> <br /> Even with CACHEFILES_DEAD set, we can still read the requests, so in the<br /> following concurrency the request may be used after it has been freed:<br /> <br /> mount | daemon_thread1 | daemon_thread2<br /> ------------------------------------------------------------<br /> cachefiles_ondemand_init_object<br /> cachefiles_ondemand_send_req<br /> REQ_A = kzalloc(sizeof(*req) + data_len)<br /> wait_for_completion(&amp;REQ_A-&gt;done)<br /> cachefiles_daemon_read<br /> cachefiles_ondemand_daemon_read<br /> // close dev fd<br /> cachefiles_flush_reqs<br /> complete(&amp;REQ_A-&gt;done)<br /> kfree(REQ_A)<br /> xa_lock(&amp;cache-&gt;reqs);<br /> cachefiles_ondemand_select_req<br /> req-&gt;msg.opcode != CACHEFILES_OP_READ<br /> // req use-after-free !!!<br /> xa_unlock(&amp;cache-&gt;reqs);<br /> xa_destroy(&amp;cache-&gt;reqs)<br /> <br /> Hence remove requests from cache-&gt;reqs when flushing them to avoid<br /> accessing freed requests.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory<br /> <br /> There is a potential out-of-bounds access when using test_bit() on a single<br /> word. The test_bit() and set_bit() functions operate on long values, and<br /> when testing or setting a single word, they can exceed the word<br /> boundary. KASAN detects this issue and produces a dump:<br /> <br /> BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas<br /> <br /> Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965<br /> <br /> For full log, please look at [1].<br /> <br /> Make the allocation at least the size of sizeof(unsigned long) so that<br /> set_bit() and test_bit() have sufficient room for read/write operations<br /> without overwriting unallocated memory.<br /> <br /> [1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: xattr: fix buffer overflow for invalid xattr<br /> <br /> When an xattr size is not what is expected, it is printed out to the<br /> kernel log in hex format as a form of debugging. But when that xattr<br /> size is bigger than the expected size, printing it out can cause an<br /> access off the end of the buffer.<br /> <br /> Fix this all up by properly restricting the size of the debug hex dump<br /> in the kernel log.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tcpm: fix use-after-free case in tcpm_register_source_caps<br /> <br /> There could be a potential use-after-free case in<br /> tcpm_register_source_caps(). This could happen when:<br /> * new (say invalid) source caps are advertised<br /> * the existing source caps are unregistered<br /> * tcpm_register_source_caps() returns with an error as<br /> usb_power_delivery_register_capabilities() fails<br /> <br /> This causes port-&gt;partner_source_caps to hold on to the now freed source<br /> caps.<br /> <br /> Reset port-&gt;partner_source_caps value to NULL after unregistering<br /> existing source caps.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages<br /> <br /> The syzbot fuzzer found that the interrupt-URB completion callback in<br /> the cdc-wdm driver was taking too long, and the driver&amp;#39;s immediate<br /> resubmission of interrupt URBs with -EPROTO status combined with the<br /> dummy-hcd emulation to cause a CPU lockup:<br /> <br /> cdc_wdm 1-1:1.0: nonzero urb status received: -71<br /> cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes<br /> watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]<br /> CPU#0 Utilization every 4s during lockup:<br /> #1: 98% system, 0% softirq, 3% hardirq, 0% idle<br /> #2: 98% system, 0% softirq, 3% hardirq, 0% idle<br /> #3: 98% system, 0% softirq, 3% hardirq, 0% idle<br /> #4: 98% system, 0% softirq, 3% hardirq, 0% idle<br /> #5: 98% system, 1% softirq, 3% hardirq, 0% idle<br /> Modules linked in:<br /> irq event stamp: 73096<br /> hardirqs last enabled at (73095): [] console_emit_next_record kernel/printk/printk.c:2935 [inline]<br /> hardirqs last enabled at (73095): [] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994<br /> hardirqs last disabled at (73096): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]<br /> hardirqs last disabled at (73096): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551<br /> softirqs last enabled at (73048): [] softirq_handle_end kernel/softirq.c:400 [inline]<br /> softirqs last enabled at (73048): [] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582<br /> softirqs last disabled at (73043): [] __do_softirq+0x14/0x20 kernel/softirq.c:588<br /> CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024<br /> <br /> Testing showed that the problem did not occur if the two error<br /> messages -- the first two lines above -- were removed; apparently adding<br /> material to the kernel log takes a surprisingly large amount of time.<br /> <br /> In any case, the best approach for preventing these lockups and to<br /> avoid spamming the log with thousands of error messages per second is<br /> to ratelimit the two dev_err() calls. Therefore we replace them with<br /> dev_err_ratelimited().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix possible race in __fib6_drop_pcpu_from()<br /> <br /> syzbot found a race in __fib6_drop_pcpu_from() [1]<br /> <br /> If compiler reads more than once (*ppcpu_rt),<br /> second read could read NULL, if another cpu clears<br /> the value in rt6_get_pcpu_route().<br /> <br /> Add a READ_ONCE() to prevent this race.<br /> <br /> Also add rcu_read_lock()/rcu_read_unlock() because<br /> we rely on RCU protection while dereferencing pcpu_rt.<br /> <br /> [1]<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]<br /> CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024<br /> Workqueue: netns cleanup_net<br /> RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984<br /> Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48<br /> RSP: 0018:ffffc900040df070 EFLAGS: 00010206<br /> RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16<br /> RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091<br /> RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007<br /> R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8<br /> R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001<br /> FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline]<br /> fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline]<br /> fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038<br /> fib6_del_route net/ipv6/ip6_fib.c:1998 [inline]<br /> fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043<br /> fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205<br /> fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127<br /> fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175<br /> fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255<br /> __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271<br /> rt6_sync_down_dev net/ipv6/route.c:4906 [inline]<br /> rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911<br /> addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855<br /> addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778<br /> notifier_call_chain+0xb9/0x410 kernel/notifier.c:93<br /> call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992<br /> call_netdevice_notifiers_extack net/core/dev.c:2030 [inline]<br /> call_netdevice_notifiers net/core/dev.c:2044 [inline]<br /> dev_close_many+0x333/0x6a0 net/core/dev.c:1585<br /> unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193<br /> unregister_netdevice_many net/core/dev.c:11276 [inline]<br /> default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759<br /> ops_exit_list+0x128/0x180 net/core/net_namespace.c:178<br /> cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640<br /> process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231<br /> process_scheduled_works kernel/workqueue.c:3312 [inline]<br /> worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393<br /> kthread+0x2c1/0x3a0 kernel/kthread.c:389<br /> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Always stop health timer during driver removal<br /> <br /> Currently, if teardown_hca fails to execute during driver removal, mlx5<br /> does not stop the health timer. Afterwards, mlx5 continue with driver<br /> teardown. This may lead to a UAF bug, which results in page fault<br /> Oops[1], since the health timer invokes after resources were freed.<br /> <br /> Hence, stop the health monitor even if teardown_hca fails.<br /> <br /> [1]<br /> mlx5_core 0000:18:00.0: E-Switch: Unload vfs: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)<br /> mlx5_core 0000:18:00.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)<br /> mlx5_core 0000:18:00.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)<br /> mlx5_core 0000:18:00.0: E-Switch: cleanup<br /> mlx5_core 0000:18:00.0: wait_func:1155:(pid 1967079): TEARDOWN_HCA(0x103) timeout. Will cause a leak of a command resource<br /> mlx5_core 0000:18:00.0: mlx5_function_close:1288:(pid 1967079): tear_down_hca failed, skip cleanup<br /> BUG: unable to handle page fault for address: ffffa26487064230<br /> PGD 100c00067 P4D 100c00067 PUD 100e5a067 PMD 105ed7067 PTE 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE ------- --- 6.7.0-68.fc38.x86_64 #1<br /> Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020<br /> RIP: 0010:ioread32be+0x34/0x60<br /> RSP: 0018:ffffa26480003e58 EFLAGS: 00010292<br /> RAX: ffffa26487064200 RBX: ffff9042d08161a0 RCX: ffff904c108222c0<br /> RDX: 000000010bbf1b80 RSI: ffffffffc055ddb0 RDI: ffffa26487064230<br /> RBP: ffff9042d08161a0 R08: 0000000000000022 R09: ffff904c108222e8<br /> R10: 0000000000000004 R11: 0000000000000441 R12: ffffffffc055ddb0<br /> R13: ffffa26487064200 R14: ffffa26480003f00 R15: ffff904c108222c0<br /> FS: 0000000000000000(0000) GS:ffff904c10800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffa26487064230 CR3: 00000002c4420006 CR4: 00000000007706f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die+0x23/0x70<br /> ? page_fault_oops+0x171/0x4e0<br /> ? exc_page_fault+0x175/0x180<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? __pfx_poll_health+0x10/0x10 [mlx5_core]<br /> ? __pfx_poll_health+0x10/0x10 [mlx5_core]<br /> ? ioread32be+0x34/0x60<br /> mlx5_health_check_fatal_sensors+0x20/0x100 [mlx5_core]<br /> ? __pfx_poll_health+0x10/0x10 [mlx5_core]<br /> poll_health+0x42/0x230 [mlx5_core]<br /> ? __next_timer_interrupt+0xbc/0x110<br /> ? __pfx_poll_health+0x10/0x10 [mlx5_core]<br /> call_timer_fn+0x21/0x130<br /> ? __pfx_poll_health+0x10/0x10 [mlx5_core]<br /> __run_timers+0x222/0x2c0<br /> run_timer_softirq+0x1d/0x40<br /> __do_softirq+0xc9/0x2c8<br /> __irq_exit_rcu+0xa6/0xc0<br /> sysvec_apic_timer_interrupt+0x72/0x90<br /> <br /> <br /> asm_sysvec_apic_timer_interrupt+0x1a/0x20<br /> RIP: 0010:cpuidle_enter_state+0xcc/0x440<br /> ? cpuidle_enter_state+0xbd/0x440<br /> cpuidle_enter+0x2d/0x40<br /> do_idle+0x20d/0x270<br /> cpu_startup_entry+0x2a/0x30<br /> rest_init+0xd0/0xd0<br /> arch_call_rest_init+0xe/0x30<br /> start_kernel+0x709/0xa90<br /> x86_64_start_reservations+0x18/0x30<br /> x86_64_start_kernel+0x96/0xa0<br /> secondary_startup_64_no_verify+0x18f/0x19b<br /> ---[ end trace 0000000000000000 ]---

The authentication system of Securepoint UTM mishandles OTP keys. This allows the bypassing of second-factor verification (when OTP is enabled) in both the administration web interface and the user portal. Affected versions include UTM 11.5 through 12.6.4 and Reseller Preview 12.7.0. The issue has been fixed in UTM 12.6.5 and 12.7.1.