Vulnerabilities

A vulnerability, which was classified as critical, was found in DrayTek Vigor2960 and Vigor300B 1.5.1.4. Affected is an unknown function of the file /cgi-bin/mainfunction.cgi/apmcfgupload of the component Web Management Interface. The manipulation of the argument session leads to os command injection. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 1.5.1.5 is able to address this issue. It is recommended to upgrade the affected component.

The Four-Faith router models F3x24 and F3x36 are affected by an operating system (OS) command injection vulnerability. At least firmware version 2.0 allows authenticated and remote attackers to execute arbitrary OS commands over HTTP when modifying the system time via apply.cgi. Additionally, this firmware version has default credentials which, if not changed, would effectively change this vulnerability into an unauthenticated and remote OS command execution issue.

A vulnerability, which was classified as critical, has been found in DrayTek Vigor2960 and Vigor300B 1.5.1.3/1.5.1.4. This issue affects some unknown processing of the file /cgi-bin/mainfunction.cgi/apmcfgupptim of the component Web Management Interface. The manipulation of the argument session leads to os command injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 1.5.1.5 is able to address this issue. It is recommended to upgrade the affected component.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: mm: Do not call pmd dtor on vmemmap page table teardown<br /> <br /> The vmemmap&amp;#39;s, which is used for RV64 with SPARSEMEM_VMEMMAP, page<br /> tables are populated using pmd (page middle directory) hugetables.<br /> However, the pmd allocation is not using the generic mechanism used by<br /> the VMA code (e.g. pmd_alloc()), or the RISC-V specific<br /> create_pgd_mapping()/alloc_pmd_late(). Instead, the vmemmap page table<br /> code allocates a page, and calls vmemmap_set_pmd(). This results in<br /> that the pmd ctor is *not* called, nor would it make sense to do so.<br /> <br /> Now, when tearing down a vmemmap page table pmd, the cleanup code<br /> would unconditionally, and incorrectly call the pmd dtor, which<br /> results in a crash (best case).<br /> <br /> This issue was found when running the HMM selftests:<br /> <br /> | tools/testing/selftests/mm# ./test_hmm.sh smoke<br /> | ... # when unloading the test_hmm.ko module<br /> | page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10915b<br /> | flags: 0x1000000000000000(node=0|zone=1)<br /> | raw: 1000000000000000 0000000000000000 dead000000000122 0000000000000000<br /> | raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000<br /> | page dumped because: VM_BUG_ON_PAGE(ptdesc-&gt;pmd_huge_pte)<br /> | ------------[ cut here ]------------<br /> | kernel BUG at include/linux/mm.h:3080!<br /> | Kernel BUG [#1]<br /> | Modules linked in: test_hmm(-) sch_fq_codel fuse drm drm_panel_orientation_quirks backlight dm_mod<br /> | CPU: 1 UID: 0 PID: 514 Comm: modprobe Tainted: G W 6.12.0-00982-gf2a4f1682d07 #2<br /> | Tainted: [W]=WARN<br /> | Hardware name: riscv-virtio qemu/qemu, BIOS 2024.10 10/01/2024<br /> | epc : remove_pgd_mapping+0xbec/0x1070<br /> | ra : remove_pgd_mapping+0xbec/0x1070<br /> | epc : ffffffff80010a68 ra : ffffffff80010a68 sp : ff20000000a73940<br /> | gp : ffffffff827b2d88 tp : ff6000008785da40 t0 : ffffffff80fbce04<br /> | t1 : 0720072007200720 t2 : 706d756420656761 s0 : ff20000000a73a50<br /> | s1 : ff6000008915cff8 a0 : 0000000000000039 a1 : 0000000000000008<br /> | a2 : ff600003fff0de20 a3 : 0000000000000000 a4 : 0000000000000000<br /> | a5 : 0000000000000000 a6 : c0000000ffffefff a7 : ffffffff824469b8<br /> | s2 : ff1c0000022456c0 s3 : ff1ffffffdbfffff s4 : ff6000008915c000<br /> | s5 : ff6000008915c000 s6 : ff6000008915c000 s7 : ff1ffffffdc00000<br /> | s8 : 0000000000000001 s9 : ff1ffffffdc00000 s10: ffffffff819a31f0<br /> | s11: ffffffffffffffff t3 : ffffffff8000c950 t4 : ff60000080244f00<br /> | t5 : ff60000080244000 t6 : ff20000000a73708<br /> | status: 0000000200000120 badaddr: ffffffff80010a68 cause: 0000000000000003<br /> | [] remove_pgd_mapping+0xbec/0x1070<br /> | [] vmemmap_free+0x14/0x1e<br /> | [] section_deactivate+0x220/0x452<br /> | [] sparse_remove_section+0x4a/0x58<br /> | [] __remove_pages+0x7e/0xba<br /> | [] memunmap_pages+0x2bc/0x3fe<br /> | [] dmirror_device_remove_chunks+0x2ea/0x518 [test_hmm]<br /> | [] hmm_dmirror_exit+0x3e/0x1018 [test_hmm]<br /> | [] __riscv_sys_delete_module+0x15a/0x2a6<br /> | [] do_trap_ecall_u+0x1f2/0x266<br /> | [] _new_vmalloc_restore_context_a0+0xc6/0xd2<br /> | Code: bf51 7597 0184 8593 76a5 854a 4097 0029 80e7 2c00 (9002) 7597<br /> | ---[ end trace 0000000000000000 ]---<br /> | Kernel panic - not syncing: Fatal exception in interrupt<br /> <br /> Add a check to avoid calling the pmd dtor, if the calling context is<br /> vmemmap_free().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_net: correct netdev_tx_reset_queue() invocation point<br /> <br /> When virtnet_close is followed by virtnet_open, some TX completions can<br /> possibly remain unconsumed, until they are finally processed during the<br /> first NAPI poll after the netdev_tx_reset_queue(), resulting in a crash<br /> [1]. Commit b96ed2c97c79 ("virtio_net: move netdev_tx_reset_queue() call<br /> before RX napi enable") was not sufficient to eliminate all BQL crash<br /> cases for virtio-net.<br /> <br /> This issue can be reproduced with the latest net-next master by running:<br /> `while :; do ip l set DEV down; ip l set DEV up; done` under heavy network<br /> TX load from inside the machine.<br /> <br /> netdev_tx_reset_queue() can actually be dropped from virtnet_open path;<br /> the device is not stopped in any case. For BQL core part, it&amp;#39;s just like<br /> traffic nearly ceases to exist for some period. For stall detector added<br /> to BQL, even if virtnet_close could somehow lead to some TX completions<br /> delayed for long, followed by virtnet_open, we can just take it as stall<br /> as mentioned in commit 6025b9135f7a ("net: dqs: add NIC stall detector<br /> based on BQL"). Note also that users can still reset stall_max via sysfs.<br /> <br /> So, drop netdev_tx_reset_queue() from virtnet_enable_queue_pair(). This<br /> eliminates the BQL crashes. As a result, netdev_tx_reset_queue() is now<br /> explicitly required in freeze/restore path. This patch adds it to<br /> immediately after free_unused_bufs(), following the rule of thumb:<br /> netdev_tx_reset_queue() should follow any SKB freeing not followed by<br /> netdev_tx_completed_queue(). This seems the most consistent and<br /> streamlined approach, and now netdev_tx_reset_queue() runs whenever<br /> free_unused_bufs() is done.<br /> <br /> [1]:<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/dynamic_queue_limits.c:99!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 7 UID: 0 PID: 1598 Comm: ip Tainted: G N 6.12.0net-next_main+ #2<br /> Tainted: [N]=TEST<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), \<br /> BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:dql_completed+0x26b/0x290<br /> Code: b7 c2 49 89 e9 44 89 da 89 c6 4c 89 d7 e8 ed 17 47 00 58 65 ff 0d<br /> 4d 27 90 7e 0f 85 fd fe ff ff e8 ea 53 8d ff e9 f3 fe ff ff 0b 01<br /> d2 44 89 d1 29 d1 ba 00 00 00 00 0f 48 ca e9 28 ff ff ff<br /> RSP: 0018:ffffc900002b0d08 EFLAGS: 00010297<br /> RAX: 0000000000000000 RBX: ffff888102398c80 RCX: 0000000080190009<br /> RDX: 0000000000000000 RSI: 000000000000006a RDI: 0000000000000000<br /> RBP: ffff888102398c00 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 00000000000000ca R11: 0000000000015681 R12: 0000000000000001<br /> R13: ffffc900002b0d68 R14: ffff88811115e000 R15: ffff8881107aca40<br /> FS: 00007f41ded69500(0000) GS:ffff888667dc0000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000556ccc2dc1a0 CR3: 0000000104fd8003 CR4: 0000000000772ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? die+0x32/0x80<br /> ? do_trap+0xd9/0x100<br /> ? dql_completed+0x26b/0x290<br /> ? dql_completed+0x26b/0x290<br /> ? do_error_trap+0x6d/0xb0<br /> ? dql_completed+0x26b/0x290<br /> ? exc_invalid_op+0x4c/0x60<br /> ? dql_completed+0x26b/0x290<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? dql_completed+0x26b/0x290<br /> __free_old_xmit+0xff/0x170 [virtio_net]<br /> free_old_xmit+0x54/0xc0 [virtio_net]<br /> virtnet_poll+0xf4/0xe30 [virtio_net]<br /> ? __update_load_avg_cfs_rq+0x264/0x2d0<br /> ? update_curr+0x35/0x260<br /> ? reweight_entity+0x1be/0x260<br /> __napi_poll.constprop.0+0x28/0x1c0<br /> net_rx_action+0x329/0x420<br /> ? enqueue_hrtimer+0x35/0x90<br /> ? trace_hardirqs_on+0x1d/0x80<br /> ? kvm_sched_clock_read+0xd/0x20<br /> ? sched_clock+0xc/0x30<br /> ? kvm_sched_clock_read+0xd/0x20<br /> ? sched_clock+0xc/0x30<br /> ? sched_clock_cpu+0xd/0x1a0<br /> handle_softirqs+0x138/0x3e0<br /> do_softirq.part.0+0x89/0xc0<br /> <br /> <br /> __local_bh_enable_ip+0xa7/0xb0<br /> virtnet_open+0xc8/0x310 [virtio_net]<br /> __dev_open+0xfa/0x1b0<br /> __dev_change_flags+0x1de/0x250<br /> dev_change_flags+0x22/0x60<br /> do_setlink.isra.0+0x2df/0x10b0<br /> ? rtnetlink_rcv_msg+0x34f/0x3f0<br /> ? netlink_rcv_skb+0x54/0x100<br /> ? netlink_unicas<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix UAF via mismatching bpf_prog/attachment RCU flavors<br /> <br /> Uprobes always use bpf_prog_run_array_uprobe() under tasks-trace-RCU<br /> protection. But it is possible to attach a non-sleepable BPF program to a<br /> uprobe, and non-sleepable BPF programs are freed via normal RCU (see<br /> __bpf_prog_put_noref()). This leads to UAF of the bpf_prog because a normal<br /> RCU grace period does not imply a tasks-trace-RCU grace period.<br /> <br /> Fix it by explicitly waiting for a tasks-trace-RCU grace period after<br /> removing the attachment of a bpf_prog to a perf_event.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-cgroup: Fix UAF in blkcg_unpin_online()<br /> <br /> blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To<br /> walk up, it uses blkcg_parent(blkcg) but it was calling that after<br /> blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the<br /> following UAF:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270<br /> Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117<br /> <br /> CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022<br /> Workqueue: cgwb_release cgwb_release_workfn<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x27/0x80<br /> print_report+0x151/0x710<br /> kasan_report+0xc0/0x100<br /> blkcg_unpin_online+0x15a/0x270<br /> cgwb_release_workfn+0x194/0x480<br /> process_scheduled_works+0x71b/0xe20<br /> worker_thread+0x82a/0xbd0<br /> kthread+0x242/0x2c0<br /> ret_from_fork+0x33/0x70<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> ...<br /> Freed by task 1944:<br /> kasan_save_track+0x2b/0x70<br /> kasan_save_free_info+0x3c/0x50<br /> __kasan_slab_free+0x33/0x50<br /> kfree+0x10c/0x330<br /> css_free_rwork_fn+0xe6/0xb30<br /> process_scheduled_works+0x71b/0xe20<br /> worker_thread+0x82a/0xbd0<br /> kthread+0x242/0x2c0<br /> ret_from_fork+0x33/0x70<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Note that the UAF is not easy to trigger as the free path is indirected<br /> behind a couple RCU grace periods and a work item execution. I could only<br /> trigger it with artifical msleep() injected in blkcg_unpin_online().<br /> <br /> Fix it by reading the parent pointer before destroying the blkcg&amp;#39;s blkg&amp;#39;s.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Dereference null return value<br /> <br /> In the function pqm_uninit there is a call-assignment of "pdd =<br /> kfd_get_process_device_data" which could be null, and this value was<br /> later dereferenced without checking.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix NULL pointer dereference in capture_engine<br /> <br /> When the intel_context structure contains NULL,<br /> it raises a NULL pointer dereference error in drm_info().<br /> <br /> (cherry picked from commit 754302a5bc1bd8fd3b7d85c168b0a1af6d4bba4d)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Fix qi_batch NULL pointer with nested parent domain<br /> <br /> The qi_batch is allocated when assigning cache tag for a domain. While<br /> for nested parent domain, it is missed. Hence, when trying to map pages<br /> to the nested parent, NULL dereference occurred. Also, there is potential<br /> memleak since there is no lock around domain-&gt;qi_batch allocation.<br /> <br /> To solve it, add a helper for qi_batch allocation, and call it in both<br /> the __cache_tag_assign_domain() and __cache_tag_assign_parent_domain().<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000200<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 8104795067 P4D 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 223 UID: 0 PID: 4357 Comm: qemu-system-x86 Not tainted 6.13.0-rc1-00028-g4b50c3c3b998-dirty #2632<br /> Call Trace:<br /> ? __die+0x24/0x70<br /> ? page_fault_oops+0x80/0x150<br /> ? do_user_addr_fault+0x63/0x7b0<br /> ? exc_page_fault+0x7c/0x220<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? cache_tag_flush_range_np+0x13c/0x260<br /> intel_iommu_iotlb_sync_map+0x1a/0x30<br /> iommu_map+0x61/0xf0<br /> batch_to_domain+0x188/0x250<br /> iopt_area_fill_domains+0x125/0x320<br /> ? rcu_is_watching+0x11/0x50<br /> iopt_map_pages+0x63/0x100<br /> iopt_map_common.isra.0+0xa7/0x190<br /> iopt_map_user_pages+0x6a/0x80<br /> iommufd_ioas_map+0xcd/0x1d0<br /> iommufd_fops_ioctl+0x118/0x1c0<br /> __x64_sys_ioctl+0x93/0xc0<br /> do_syscall_64+0x71/0x140<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Remove cache tags before disabling ATS<br /> <br /> The current implementation removes cache tags after disabling ATS,<br /> leading to potential memory leaks and kernel crashes. Specifically,<br /> CACHE_TAG_DEVTLB type cache tags may still remain in the list even<br /> after the domain is freed, causing a use-after-free condition.<br /> <br /> This issue really shows up when multiple VFs from different PFs<br /> passed through to a single user-space process via vfio-pci. In such<br /> cases, the kernel may crash with kernel messages like:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000014<br /> PGD 19036a067 P4D 1940a3067 PUD 136c9b067 PMD 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 74 UID: 0 PID: 3183 Comm: testCli Not tainted 6.11.9 #2<br /> RIP: 0010:cache_tag_flush_range+0x9b/0x250<br /> Call Trace:<br /> <br /> ? __die+0x1f/0x60<br /> ? page_fault_oops+0x163/0x590<br /> ? exc_page_fault+0x72/0x190<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? cache_tag_flush_range+0x9b/0x250<br /> ? cache_tag_flush_range+0x5d/0x250<br /> intel_iommu_tlb_sync+0x29/0x40<br /> intel_iommu_unmap_pages+0xfe/0x160<br /> __iommu_unmap+0xd8/0x1a0<br /> vfio_unmap_unpin+0x182/0x340 [vfio_iommu_type1]<br /> vfio_remove_dma+0x2a/0xb0 [vfio_iommu_type1]<br /> vfio_iommu_type1_ioctl+0xafa/0x18e0 [vfio_iommu_type1]<br /> <br /> Move cache_tag_unassign_domain() before iommu_disable_pci_caps() to fix<br /> it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: graniterapids: Fix vGPIO driver crash<br /> <br /> Move setting irq_chip.name from probe() function to the initialization<br /> of "irq_chip" struct in order to fix vGPIO driver crash during bootup.<br /> <br /> Crash was caused by unauthorized modification of irq_chip.name field<br /> where irq_chip struct was initialized as const.<br /> <br /> This behavior is a consequence of suboptimal implementation of<br /> gpio_irq_chip_set_chip(), which should be changed to avoid<br /> casting away const qualifier.<br /> <br /> Crash log:<br /> BUG: unable to handle page fault for address: ffffffffc0ba81c0<br /> /#PF: supervisor write access in kernel mode<br /> /#PF: error_code(0x0003) - permissions violation<br /> CPU: 33 UID: 0 PID: 1075 Comm: systemd-udevd Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7 #1<br /> Hardware name: Intel Corporation Kaseyville RP/Kaseyville RP, BIOS KVLDCRB1.PGS.0026.D73.2410081258 10/08/2024<br /> RIP: 0010:gnr_gpio_probe+0x171/0x220 [gpio_graniterapids]