Vulnerabilities

LinkAce is a self-hosted archive to collect links of your favorite websites. Prior to 1.15.6, a reflected cross-site scripting (XSS) vulnerability exists in the LinkAce. This issue occurs in the "URL" field of the "Edit Link" module, where user input is not properly sanitized or encoded before being reflected in the HTML response. This allows attackers to inject and execute arbitrary JavaScript in the context of the victim’s browser, leading to potential session hijacking, data theft, and unauthorized actions. This vulnerability is fixed in 1.15.6.

LinkAce is a self-hosted archive to collect links of your favorite websites. Prior to 1.15.6, a file upload vulnerability exists in the LinkAce. This issue occurs in the "Import Bookmarks" functionality, where malicious HTML files can be uploaded containing JavaScript payloads. These payloads execute when the uploaded links are accessed, leading to potential reflected or persistent XSS scenarios. This vulnerability is fixed in 1.15.6.

changedetection.io is a free open source web page change detection, website watcher, restock monitor and notification service. Improper input validation in the application can allow attackers to perform local file read (LFR) or path traversal attacks. These vulnerabilities occur when user input is used to construct file paths without adequate sanitization or validation. For example, using file:../../../etc/passwd or file: ///etc/passwd can bypass weak validations and allow unauthorized access to sensitive files. Even though this has been addressed in previous patch, it is still insufficient. This vulnerability is fixed in 0.48.05.

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 /> 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 /> 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 /> 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 /> 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 /> usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer<br /> <br /> Considering that in some extreme cases,<br /> when u_serial driver is accessed by multiple threads,<br /> Thread A is executing the open operation and calling the gs_open,<br /> Thread B is executing the disconnect operation and calling the<br /> gserial_disconnect function,The port-&gt;port_usb pointer will be set to NULL.<br /> <br /> E.g.<br /> Thread A Thread B<br /> gs_open() gadget_unbind_driver()<br /> gs_start_io() composite_disconnect()<br /> gs_start_rx() gserial_disconnect()<br /> ... ...<br /> spin_unlock(&amp;port-&gt;port_lock)<br /> status = usb_ep_queue() spin_lock(&amp;port-&gt;port_lock)<br /> spin_lock(&amp;port-&gt;port_lock) port-&gt;port_usb = NULL<br /> gs_free_requests(port-&gt;port_usb-&gt;in) spin_unlock(&amp;port-&gt;port_lock)<br /> Crash<br /> <br /> This causes thread A to access a null pointer (port-&gt;port_usb is null)<br /> when calling the gs_free_requests function, causing a crash.<br /> <br /> If port_usb is NULL, the release request will be skipped as it<br /> will be done by gserial_disconnect.<br /> <br /> So add a null pointer check to gs_start_io before attempting<br /> to access the value of the pointer port-&gt;port_usb.<br /> <br /> Call trace:<br /> gs_start_io+0x164/0x25c<br /> gs_open+0x108/0x13c<br /> tty_open+0x314/0x638<br /> chrdev_open+0x1b8/0x258<br /> do_dentry_open+0x2c4/0x700<br /> vfs_open+0x2c/0x3c<br /> path_openat+0xa64/0xc60<br /> do_filp_open+0xb8/0x164<br /> do_sys_openat2+0x84/0xf0<br /> __arm64_sys_openat+0x70/0x9c<br /> invoke_syscall+0x58/0x114<br /> el0_svc_common+0x80/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x38/0x68

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]