Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbcon: always restore the old font data in fbcon_do_set_font()<br /> <br /> Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when<br /> vc_resize() failed) started restoring old font data upon failure (of<br /> vc_resize()). But it performs so only for user fonts. It means that the<br /> "system"/internal fonts are not restored at all. So in result, the very<br /> first call to fbcon_do_set_font() performs no restore at all upon<br /> failing vc_resize().<br /> <br /> This can be reproduced by Syzkaller to crash the system on the next<br /> invocation of font_get(). It&amp;#39;s rather hard to hit the allocation failure<br /> in vc_resize() on the first font_set(), but not impossible. Esp. if<br /> fault injection is used to aid the execution/failure. It was<br /> demonstrated by Sirius:<br /> BUG: unable to handle page fault for address: fffffffffffffff8<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0<br /> Oops: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286<br /> Call Trace:<br /> <br /> con_font_get drivers/tty/vt/vt.c:4558 [inline]<br /> con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673<br /> vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline]<br /> vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752<br /> tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> ...<br /> <br /> So restore the font data in any case, not only for user fonts. Note the<br /> later &amp;#39;if&amp;#39; is now protected by &amp;#39;old_userfont&amp;#39; and not &amp;#39;old_data&amp;#39; as the<br /> latter is always set now. (And it is supposed to be non-NULL. Otherwise<br /> we would see the bug above again.)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmscan: fix a bug calling wakeup_kswapd() with a wrong zone index<br /> <br /> With numa balancing on, when a numa system is running where a numa node<br /> doesn&amp;#39;t have its local memory so it has no managed zones, the following<br /> oops has been observed. It&amp;#39;s because wakeup_kswapd() is called with a<br /> wrong zone index, -1. Fixed it by checking the index before calling<br /> wakeup_kswapd().<br /> <br /> &gt; BUG: unable to handle page fault for address: 00000000000033f3<br /> &gt; #PF: supervisor read access in kernel mode<br /> &gt; #PF: error_code(0x0000) - not-present page<br /> &gt; PGD 0 P4D 0<br /> &gt; Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> &gt; CPU: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255<br /> &gt; Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> &gt; rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> &gt; RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812)<br /> &gt; Code: (omitted)<br /> &gt; RSP: 0000:ffffc90004257d58 EFLAGS: 00010286<br /> &gt; RAX: ffffffffffffffff RBX: ffff88883fff0480 RCX: 0000000000000003<br /> &gt; RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88883fff0480<br /> &gt; RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff<br /> &gt; R10: ffff888106c95540 R11: 0000000055555554 R12: 0000000000000003<br /> &gt; R13: 0000000000000000 R14: 0000000000000000 R15: ffff88883fff0940<br /> &gt; FS: 00007fc4b8124740(0000) GS:ffff888827c00000(0000) knlGS:0000000000000000<br /> &gt; CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> &gt; CR2: 00000000000033f3 CR3: 000000026cc08004 CR4: 0000000000770ee0<br /> &gt; DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> &gt; DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> &gt; PKRU: 55555554<br /> &gt; Call Trace:<br /> &gt; <br /> &gt; ? __die<br /> &gt; ? page_fault_oops<br /> &gt; ? __pte_offset_map_lock<br /> &gt; ? exc_page_fault<br /> &gt; ? asm_exc_page_fault<br /> &gt; ? wakeup_kswapd<br /> &gt; migrate_misplaced_page<br /> &gt; __handle_mm_fault<br /> &gt; handle_mm_fault<br /> &gt; do_user_addr_fault<br /> &gt; exc_page_fault<br /> &gt; asm_exc_page_fault<br /> &gt; RIP: 0033:0x55b897ba0808<br /> &gt; Code: (omitted)<br /> &gt; RSP: 002b:00007ffeefa821a0 EFLAGS: 00010287<br /> &gt; RAX: 000055b89983acd0 RBX: 00007ffeefa823f8 RCX: 000055b89983acd0<br /> &gt; RDX: 00007fc2f8122010 RSI: 0000000000020000 RDI: 000055b89983acd0<br /> &gt; RBP: 00007ffeefa821a0 R08: 0000000000000037 R09: 0000000000000075<br /> &gt; R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000<br /> &gt; R13: 00007ffeefa82410 R14: 000055b897ba5dd8 R15: 00007fc4b8340000<br /> &gt;

Incorrect Access Control in ITB-GmbH TradePro v9.5, allows remote attackers to receive all order confirmations from the online shop via the printmail plugin.

SQL injection vulnerability in ITB-GmbH TradePro v9.5, allows remote attackers to run SQL queries via oordershow component in customer function.

Adobe Experience Manager versions 6.5.19 and earlier are affected by a DOM-based Cross-Site Scripting (XSS) vulnerability that could be abused by a low-privileged attacker to inject malicious scripts into vulnerable web pages. Malicious JavaScript may be executed in a victim’s browser when they browse to the page containing the vulnerable script. This could result in arbitrary code execution within the context of the victim&amp;#39;s browser.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV<br /> <br /> When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due<br /> to NULL pointer exception:<br /> <br /> Kernel attempted to read user page (0) - exploit attempt? (uid: 0)<br /> BUG: Kernel NULL pointer dereference on read at 0x00000000<br /> Faulting instruction address: 0xc000000020847ad4<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries<br /> Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop<br /> CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12<br /> Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries<br /> NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c<br /> REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+)<br /> MSR: 800000000280b033 CR: 48288244 XER: 00000008<br /> CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1<br /> ...<br /> NIP _find_next_zero_bit+0x24/0x110<br /> LR bitmap_find_next_zero_area_off+0x5c/0xe0<br /> Call Trace:<br /> dev_printk_emit+0x38/0x48 (unreliable)<br /> iommu_area_alloc+0xc4/0x180<br /> iommu_range_alloc+0x1e8/0x580<br /> iommu_alloc+0x60/0x130<br /> iommu_alloc_coherent+0x158/0x2b0<br /> dma_iommu_alloc_coherent+0x3c/0x50<br /> dma_alloc_attrs+0x170/0x1f0<br /> mlx5_cmd_init+0xc0/0x760 [mlx5_core]<br /> mlx5_function_setup+0xf0/0x510 [mlx5_core]<br /> mlx5_init_one+0x84/0x210 [mlx5_core]<br /> probe_one+0x118/0x2c0 [mlx5_core]<br /> local_pci_probe+0x68/0x110<br /> pci_call_probe+0x68/0x200<br /> pci_device_probe+0xbc/0x1a0<br /> really_probe+0x104/0x540<br /> __driver_probe_device+0xb4/0x230<br /> driver_probe_device+0x54/0x130<br /> __driver_attach+0x158/0x2b0<br /> bus_for_each_dev+0xa8/0x130<br /> driver_attach+0x34/0x50<br /> bus_add_driver+0x16c/0x300<br /> driver_register+0xa4/0x1b0<br /> __pci_register_driver+0x68/0x80<br /> mlx5_init+0xb8/0x100 [mlx5_core]<br /> do_one_initcall+0x60/0x300<br /> do_init_module+0x7c/0x2b0<br /> <br /> At the time of LPAR dump, before kexec hands over control to kdump<br /> kernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT.<br /> For the SR-IOV case, default DMA window "ibm,dma-window" is removed from<br /> the FDT and DDW added, for the device.<br /> <br /> Now, kexec hands over control to the kdump kernel.<br /> <br /> When the kdump kernel initializes, PCI busses are scanned and IOMMU<br /> group/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV<br /> case, there is no "ibm,dma-window". The original commit: b1fc44eaa9ba,<br /> fixes the path where memory is pre-mapped (direct mapped) to the DDW.<br /> When TCEs are direct mapped, there is no need to initialize IOMMU<br /> tables.<br /> <br /> iommu_table_setparms_lpar() only considers "ibm,dma-window" property<br /> when initiallizing IOMMU table. In the scenario where TCEs are<br /> dynamically allocated for SR-IOV, newly created IOMMU table is not<br /> initialized. Later, when the device driver tries to enter TCEs for the<br /> SR-IOV device, NULL pointer execption is thrown from iommu_area_alloc().<br /> <br /> The fix is to initialize the IOMMU table with DDW property stored in the<br /> FDT. There are 2 points to remember:<br /> <br /> 1. For the dedicated adapter, kdump kernel would encounter both<br /> default and DDW in FDT. In this case, DDW property is used to<br /> initialize the IOMMU table.<br /> <br /> 2. A DDW could be direct or dynamic mapped. kdump kernel would<br /> initialize IOMMU table and mark the existing DDW as<br /> "dynamic". This works fine since, at the time of table<br /> initialization, iommu_table_clear() makes some space in the<br /> DDW, for some predefined number of TCEs which are needed for<br /> kdump to succeed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Ensure safe user copy of completion record<br /> <br /> If CONFIG_HARDENED_USERCOPY is enabled, copying completion record from<br /> event log cache to user triggers a kernel bug.<br /> <br /> [ 1987.159822] usercopy: Kernel memory exposure attempt detected from SLUB object &amp;#39;dsa0&amp;#39; (offset 74, size 31)!<br /> [ 1987.170845] ------------[ cut here ]------------<br /> [ 1987.176086] kernel BUG at mm/usercopy.c:102!<br /> [ 1987.180946] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 1987.186866] CPU: 17 PID: 528 Comm: kworker/17:1 Not tainted 6.8.0-rc2+ #5<br /> [ 1987.194537] Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023<br /> [ 1987.206405] Workqueue: wq0.0 idxd_evl_fault_work [idxd]<br /> [ 1987.212338] RIP: 0010:usercopy_abort+0x72/0x90<br /> [ 1987.217381] Code: 58 65 9c 50 48 c7 c2 17 85 61 9c 57 48 c7 c7 98 fd 6b 9c 48 0f 44 d6 48 c7 c6 b3 08 62 9c 4c 89 d1 49 0f 44 f3 e8 1e 2e d5 ff 0b 49 c7 c1 9e 42 61 9c 4c 89 cf 4d 89 c8 eb a9 66 66 2e 0f 1f<br /> [ 1987.238505] RSP: 0018:ff62f5cf20607d60 EFLAGS: 00010246<br /> [ 1987.244423] RAX: 000000000000005f RBX: 000000000000001f RCX: 0000000000000000<br /> [ 1987.252480] RDX: 0000000000000000 RSI: ffffffff9c61429e RDI: 00000000ffffffff<br /> [ 1987.260538] RBP: ff62f5cf20607d78 R08: ff2a6a89ef3fffe8 R09: 00000000fffeffff<br /> [ 1987.268595] R10: ff2a6a89eed00000 R11: 0000000000000003 R12: ff2a66934849c89a<br /> [ 1987.276652] R13: 0000000000000001 R14: ff2a66934849c8b9 R15: ff2a66934849c899<br /> [ 1987.284710] FS: 0000000000000000(0000) GS:ff2a66b22fe40000(0000) knlGS:0000000000000000<br /> [ 1987.293850] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 1987.300355] CR2: 00007fe291a37000 CR3: 000000010fbd4005 CR4: 0000000000f71ef0<br /> [ 1987.308413] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 1987.316470] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> [ 1987.324527] PKRU: 55555554<br /> [ 1987.327622] Call Trace:<br /> [ 1987.330424] <br /> [ 1987.332826] ? show_regs+0x6e/0x80<br /> [ 1987.336703] ? die+0x3c/0xa0<br /> [ 1987.339988] ? do_trap+0xd4/0xf0<br /> [ 1987.343662] ? do_error_trap+0x75/0xa0<br /> [ 1987.347922] ? usercopy_abort+0x72/0x90<br /> [ 1987.352277] ? exc_invalid_op+0x57/0x80<br /> [ 1987.356634] ? usercopy_abort+0x72/0x90<br /> [ 1987.360988] ? asm_exc_invalid_op+0x1f/0x30<br /> [ 1987.365734] ? usercopy_abort+0x72/0x90<br /> [ 1987.370088] __check_heap_object+0xb7/0xd0<br /> [ 1987.374739] __check_object_size+0x175/0x2d0<br /> [ 1987.379588] idxd_copy_cr+0xa9/0x130 [idxd]<br /> [ 1987.384341] idxd_evl_fault_work+0x127/0x390 [idxd]<br /> [ 1987.389878] process_one_work+0x13e/0x300<br /> [ 1987.394435] ? __pfx_worker_thread+0x10/0x10<br /> [ 1987.399284] worker_thread+0x2f7/0x420<br /> [ 1987.403544] ? _raw_spin_unlock_irqrestore+0x2b/0x50<br /> [ 1987.409171] ? __pfx_worker_thread+0x10/0x10<br /> [ 1987.414019] kthread+0x107/0x140<br /> [ 1987.417693] ? __pfx_kthread+0x10/0x10<br /> [ 1987.421954] ret_from_fork+0x3d/0x60<br /> [ 1987.426019] ? __pfx_kthread+0x10/0x10<br /> [ 1987.430281] ret_from_fork_asm+0x1b/0x30<br /> [ 1987.434744] <br /> <br /> The issue arises because event log cache is created using<br /> kmem_cache_create() which is not suitable for user copy.<br /> <br /> Fix the issue by creating event log cache with<br /> kmem_cache_create_usercopy(), ensuring safe user copy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Drop oob_skb ref before purging queue in GC.<br /> <br /> syzbot reported another task hung in __unix_gc(). [0]<br /> <br /> The current while loop assumes that all of the left candidates<br /> have oob_skb and calling kfree_skb(oob_skb) releases the remaining<br /> candidates.<br /> <br /> However, I missed a case that oob_skb has self-referencing fd and<br /> another fd and the latter sk is placed before the former in the<br /> candidate list. Then, the while loop never proceeds, resulting<br /> the task hung.<br /> <br /> __unix_gc() has the same loop just before purging the collected skb,<br /> so we can call kfree_skb(oob_skb) there and let __skb_queue_purge()<br /> release all inflight sockets.<br /> <br /> [0]:<br /> Sending NMI from CPU 0 to CPUs 1:<br /> NMI backtrace for cpu 1<br /> CPU: 1 PID: 2784 Comm: kworker/u4:8 Not tainted 6.8.0-rc4-syzkaller-01028-g71b605d32017 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024<br /> Workqueue: events_unbound __unix_gc<br /> RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:200<br /> Code: 89 fb e8 23 00 00 00 48 8b 3d 84 f5 1a 0c 48 89 de 5b e9 43 26 57 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1e fa 48 8b 04 24 65 48 8b 0d 90 52 70 7e 65 8b 15 91 52 70<br /> RSP: 0018:ffffc9000a17fa78 EFLAGS: 00000287<br /> RAX: ffffffff8a0a6108 RBX: ffff88802b6c2640 RCX: ffff88802c0b3b80<br /> RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000<br /> RBP: ffffc9000a17fbf0 R08: ffffffff89383f1d R09: 1ffff1100ee5ff84<br /> R10: dffffc0000000000 R11: ffffed100ee5ff85 R12: 1ffff110056d84ee<br /> R13: ffffc9000a17fae0 R14: 0000000000000000 R15: ffffffff8f47b840<br /> FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffef5687ff8 CR3: 0000000029b34000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> <br /> <br /> __unix_gc+0xe69/0xf40 net/unix/garbage.c:343<br /> process_one_work kernel/workqueue.c:2633 [inline]<br /> process_scheduled_works+0x913/0x1420 kernel/workqueue.c:2706<br /> worker_thread+0xa5f/0x1000 kernel/workqueue.c:2787<br /> kthread+0x2ef/0x390 kernel/kthread.c:388<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Fix task hung while purging oob_skb in GC.<br /> <br /> syzbot reported a task hung; at the same time, GC was looping infinitely<br /> in list_for_each_entry_safe() for OOB skb. [0]<br /> <br /> syzbot demonstrated that the list_for_each_entry_safe() was not actually<br /> safe in this case.<br /> <br /> A single skb could have references for multiple sockets. If we free such<br /> a skb in the list_for_each_entry_safe(), the current and next sockets could<br /> be unlinked in a single iteration.<br /> <br /> unix_notinflight() uses list_del_init() to unlink the socket, so the<br /> prefetched next socket forms a loop itself and list_for_each_entry_safe()<br /> never stops.<br /> <br /> Here, we must use while() and make sure we always fetch the first socket.<br /> <br /> [0]:<br /> Sending NMI from CPU 0 to CPUs 1:<br /> NMI backtrace for cpu 1<br /> CPU: 1 PID: 5065 Comm: syz-executor236 Not tainted 6.8.0-rc3-syzkaller-00136-g1f719a2f3fa6 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024<br /> RIP: 0010:preempt_count arch/x86/include/asm/preempt.h:26 [inline]<br /> RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline]<br /> RIP: 0010:__sanitizer_cov_trace_pc+0xd/0x60 kernel/kcov.c:207<br /> Code: cc cc cc cc 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 65 48 8b 14 25 40 c2 03 00 8b 05 b4 7c 78 7e a9 00 01 ff 00 48 8b 34 24 74 0f f6 c4 01 74<br /> RSP: 0018:ffffc900033efa58 EFLAGS: 00000283<br /> RAX: ffff88807b077800 RBX: ffff88807b077800 RCX: 1ffffffff27b1189<br /> RDX: ffff88802a5a3b80 RSI: ffffffff8968488d RDI: ffff88807b077f70<br /> RBP: ffffc900033efbb0 R08: 0000000000000001 R09: fffffbfff27a900c<br /> R10: ffffffff93d48067 R11: ffffffff8ae000eb R12: ffff88807b077800<br /> R13: dffffc0000000000 R14: ffff88807b077e40 R15: 0000000000000001<br /> FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000564f4fc1e3a8 CR3: 000000000d57a000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> <br /> <br /> unix_gc+0x563/0x13b0 net/unix/garbage.c:319<br /> unix_release_sock+0xa93/0xf80 net/unix/af_unix.c:683<br /> unix_release+0x91/0xf0 net/unix/af_unix.c:1064<br /> __sock_release+0xb0/0x270 net/socket.c:659<br /> sock_close+0x1c/0x30 net/socket.c:1421<br /> __fput+0x270/0xb80 fs/file_table.c:376<br /> task_work_run+0x14f/0x250 kernel/task_work.c:180<br /> exit_task_work include/linux/task_work.h:38 [inline]<br /> do_exit+0xa8a/0x2ad0 kernel/exit.c:871<br /> do_group_exit+0xd4/0x2a0 kernel/exit.c:1020<br /> __do_sys_exit_group kernel/exit.c:1031 [inline]<br /> __se_sys_exit_group kernel/exit.c:1029 [inline]<br /> __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1029<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xd5/0x270 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x6f/0x77<br /> RIP: 0033:0x7f9d6cbdac09<br /> Code: Unable to access opcode bytes at 0x7f9d6cbdabdf.<br /> RSP: 002b:00007fff5952feb8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9d6cbdac09<br /> RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000<br /> RBP: 00007f9d6cc552b0 R08: ffffffffffffffb8 R09: 0000000000000006<br /> R10: 0000000000000006 R11: 0000000000000246 R12: 00007f9d6cc552b0<br /> R13: 0000000000000000 R14: 00007f9d6cc55d00 R15: 00007f9d6cbabe70<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix possible deadlock in subflow diag<br /> <br /> Syzbot and Eric reported a lockdep splat in the subflow diag:<br /> <br /> WARNING: possible circular locking dependency detected<br /> 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted<br /> <br /> syz-executor.2/24141 is trying to acquire lock:<br /> ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:<br /> tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]<br /> ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:<br /> tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137<br /> <br /> but task is already holding lock:<br /> ffffc9000135e488 (&amp;h-&gt;lhash2[i].lock){+.+.}-{2:2}, at: spin_lock<br /> include/linux/spinlock.h:351 [inline]<br /> ffffc9000135e488 (&amp;h-&gt;lhash2[i].lock){+.+.}-{2:2}, at:<br /> inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #1 (&amp;h-&gt;lhash2[i].lock){+.+.}-{2:2}:<br /> lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754<br /> __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]<br /> _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154<br /> spin_lock include/linux/spinlock.h:351 [inline]<br /> __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743<br /> inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261<br /> __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217<br /> inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239<br /> rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316<br /> rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577<br /> ops_init+0x352/0x610 net/core/net_namespace.c:136<br /> __register_pernet_operations net/core/net_namespace.c:1214 [inline]<br /> register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283<br /> register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370<br /> rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735<br /> do_one_initcall+0x238/0x830 init/main.c:1236<br /> do_initcall_level+0x157/0x210 init/main.c:1298<br /> do_initcalls+0x3f/0x80 init/main.c:1314<br /> kernel_init_freeable+0x42f/0x5d0 init/main.c:1551<br /> kernel_init+0x1d/0x2a0 init/main.c:1441<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242<br /> <br /> -&gt; #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}:<br /> check_prev_add kernel/locking/lockdep.c:3134 [inline]<br /> check_prevs_add kernel/locking/lockdep.c:3253 [inline]<br /> validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869<br /> __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137<br /> lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754<br /> lock_sock_fast include/net/sock.h:1723 [inline]<br /> subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28<br /> tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]<br /> tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137<br /> inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345<br /> inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061<br /> __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263<br /> inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371<br /> netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264<br /> __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370<br /> netlink_dump_start include/linux/netlink.h:338 [inline]<br /> inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405<br /> sock_diag_rcv_msg+0xe7/0x410<br /> netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543<br /> sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]<br /> netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367<br /> netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x221/0x270 net/socket.c:745<br /> ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584<br /> ___sys_sendmsg net/socket.c:2638 [inline]<br /> __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667<br /> do_syscall_64+0xf9/0x240<br /> entry_SYSCALL_64_after_hwframe+0x6f/0x77<br /> <br /> As noted by Eric we can break the lock dependency chain avoid<br /> dumping <br /> ---truncated---

Incorrect Access Control in ITB-GmbH TradePro v9.5, allows remote attackers to receive all orders from the online shop via oordershow component in customer function.

A problem has been identified in the CloudStack additional VM configuration (extraconfig) feature which can be misused by anyone who has privilege to deploy a VM instance or configure settings of an already deployed VM instance, to configure additional VM configuration even when the feature is not explicitly enabled by the administrator. In a KVM based CloudStack environment, an attacker can exploit this issue to attach host devices such as storage disks, and PCI and USB devices such as network adapters and GPUs, in a regular VM instance that can be further exploited to gain access to the underlying network and storage infrastructure resources, and access any VM instance disks on the local storage.<br /> <br /> Users are advised to upgrade to version 4.18.1.1 or 4.19.0.1, which fixes this issue.<br /> <br />