Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gtp: fix use-after-free and null-ptr-deref in gtp_newlink()<br /> <br /> The gtp_link_ops operations structure for the subsystem must be<br /> registered after registering the gtp_net_ops pernet operations structure.<br /> <br /> Syzkaller hit &amp;#39;general protection fault in gtp_genl_dump_pdp&amp;#39; bug:<br /> <br /> [ 1010.702740] gtp: GTP module unloaded<br /> [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI<br /> [ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1<br /> [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014<br /> [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp]<br /> [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00<br /> [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203<br /> [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000<br /> [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282<br /> [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000<br /> [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80<br /> [ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400<br /> [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000<br /> [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0<br /> [ 1010.715968] PKRU: 55555554<br /> [ 1010.715972] Call Trace:<br /> [ 1010.715985] ? __die_body.cold+0x1a/0x1f<br /> [ 1010.715995] ? die_addr+0x43/0x70<br /> [ 1010.716002] ? exc_general_protection+0x199/0x2f0<br /> [ 1010.716016] ? asm_exc_general_protection+0x1e/0x30<br /> [ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp]<br /> [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp]<br /> [ 1010.716042] __rtnl_newlink+0x1063/0x1700<br /> [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0<br /> [ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0<br /> [ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0<br /> [ 1010.716076] ? __kernel_text_address+0x56/0xa0<br /> [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0<br /> [ 1010.716091] ? create_prof_cpu_mask+0x30/0x30<br /> [ 1010.716098] ? arch_stack_walk+0x9e/0xf0<br /> [ 1010.716106] ? stack_trace_save+0x91/0xd0<br /> [ 1010.716113] ? stack_trace_consume_entry+0x170/0x170<br /> [ 1010.716121] ? __lock_acquire+0x15c5/0x5380<br /> [ 1010.716139] ? mark_held_locks+0x9e/0xe0<br /> [ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0<br /> [ 1010.716155] ? __rtnl_newlink+0x1700/0x1700<br /> [ 1010.716160] rtnl_newlink+0x69/0xa0<br /> [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50<br /> [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0<br /> [ 1010.716179] ? lock_acquire+0x1fe/0x560<br /> [ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50<br /> [ 1010.716196] netlink_rcv_skb+0x14d/0x440<br /> [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0<br /> [ 1010.716208] ? netlink_ack+0xab0/0xab0<br /> [ 1010.716213] ? netlink_deliver_tap+0x202/0xd50<br /> [ 1010.716220] ? netlink_deliver_tap+0x218/0xd50<br /> [ 1010.716226] ? __virt_addr_valid+0x30b/0x590<br /> [ 1010.716233] netlink_unicast+0x54b/0x800<br /> [ 1010.716240] ? netlink_attachskb+0x870/0x870<br /> [ 1010.716248] ? __check_object_size+0x2de/0x3b0<br /> [ 1010.716254] netlink_sendmsg+0x938/0xe40<br /> [ 1010.716261] ? netlink_unicast+0x800/0x800<br /> [ 1010.716269] ? __import_iovec+0x292/0x510<br /> [ 1010.716276] ? netlink_unicast+0x800/0x800<br /> [ 1010.716284] __sock_sendmsg+0x159/0x190<br /> [ 1010.716290] ____sys_sendmsg+0x712/0x880<br /> [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0<br /> [ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270<br /> [ 1010.716309] ? lock_acquire+0x1fe/0x560<br /> [ 1010.716315] ? drain_array_locked+0x90/0x90<br /> [ 1010.716324] ___sys_sendmsg+0xf8/0x170<br /> [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170<br /> [ 1010.716337] ? lockdep_init_map<br /> ---truncated---

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: Sparse-Memory/vmemmap out-of-bounds fix<br /> <br /> Offset vmemmap so that the first page of vmemmap will be mapped<br /> to the first page of physical memory in order to ensure that<br /> vmemmap’s bounds will be respected during<br /> pfn_to_page()/page_to_pfn() operations.<br /> The conversion macros will produce correct SV39/48/57 addresses<br /> for every possible/valid DRAM_BASE inside the physical memory limits.<br /> <br /> v2:Address Alex&amp;#39;s comments

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: perf: ctr_get_width function for legacy is not defined<br /> <br /> With parameters CONFIG_RISCV_PMU_LEGACY=y and CONFIG_RISCV_PMU_SBI=n<br /> linux kernel crashes when you try perf record:<br /> <br /> $ perf record ls<br /> [ 46.749286] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [ 46.750199] Oops [#1]<br /> [ 46.750342] Modules linked in:<br /> [ 46.750608] CPU: 0 PID: 107 Comm: perf-exec Not tainted 6.6.0 #2<br /> [ 46.750906] Hardware name: riscv-virtio,qemu (DT)<br /> [ 46.751184] epc : 0x0<br /> [ 46.751430] ra : arch_perf_update_userpage+0x54/0x13e<br /> [ 46.751680] epc : 0000000000000000 ra : ffffffff8072ee52 sp : ff2000000022b8f0<br /> [ 46.751958] gp : ffffffff81505988 tp : ff6000000290d400 t0 : ff2000000022b9c0<br /> [ 46.752229] t1 : 0000000000000001 t2 : 0000000000000003 s0 : ff2000000022b930<br /> [ 46.752451] s1 : ff600000028fb000 a0 : 0000000000000000 a1 : ff600000028fb000<br /> [ 46.752673] a2 : 0000000ae2751268 a3 : 00000000004fb708 a4 : 0000000000000004<br /> [ 46.752895] a5 : 0000000000000000 a6 : 000000000017ffe3 a7 : 00000000000000d2<br /> [ 46.753117] s2 : ff600000028fb000 s3 : 0000000ae2751268 s4 : 0000000000000000<br /> [ 46.753338] s5 : ffffffff8153e290 s6 : ff600000863b9000 s7 : ff60000002961078<br /> [ 46.753562] s8 : ff60000002961048 s9 : ff60000002961058 s10: 0000000000000001<br /> [ 46.753783] s11: 0000000000000018 t3 : ffffffffffffffff t4 : ffffffffffffffff<br /> [ 46.754005] t5 : ff6000000292270c t6 : ff2000000022bb30<br /> [ 46.754179] status: 0000000200000100 badaddr: 0000000000000000 cause: 000000000000000c<br /> [ 46.754653] Code: Unable to access instruction at 0xffffffffffffffec.<br /> [ 46.754939] ---[ end trace 0000000000000000 ]---<br /> [ 46.755131] note: perf-exec[107] exited with irqs disabled<br /> [ 46.755546] note: perf-exec[107] exited with preempt_count 4<br /> <br /> This happens because in the legacy case the ctr_get_width function was not<br /> defined, but it is used in arch_perf_update_userpage.<br /> <br /> Also remove extra check in riscv_pmu_ctr_get_width_mask

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Prevent potential buffer overflow in map_hw_resources<br /> <br /> Adds a check in the map_hw_resources function to prevent a potential<br /> buffer overflow. The function was accessing arrays using an index that<br /> could potentially be greater than the size of the arrays, leading to a<br /> buffer overflow.<br /> <br /> Adds a check to ensure that the index is within the bounds of the<br /> arrays. If the index is out of bounds, an error message is printed and<br /> break it will continue execution with just ignoring extra data early to<br /> prevent the buffer overflow.<br /> <br /> Reported by smatch:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:79 map_hw_resources() error: buffer overflow &amp;#39;dml2-&gt;v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_stream_id&amp;#39; 6 v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_plane_id&amp;#39; 6

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: qcom: Fix uninitialized pointer dmactl<br /> <br /> In the case where __lpass_get_dmactl_handle is called and the driver<br /> id dai_id is invalid the pointer dmactl is not being assigned a value,<br /> and dmactl contains a garbage value since it has not been initialized<br /> and so the null check may not work. Fix this to initialize dmactl to<br /> NULL. One could argue that modern compilers will set this to zero, but<br /> it is useful to keep this initialized as per the same way in functions<br /> __lpass_platform_codec_intf_init and lpass_cdc_dma_daiops_hw_params.<br /> <br /> Cleans up clang scan build warning:<br /> sound/soc/qcom/lpass-cdc-dma.c:275:7: warning: Branch condition<br /> evaluates to a garbage value [core.uninitialized.Branch]

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;

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.)

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.