Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Check validity of link-&gt;type in bpf_link_show_fdinfo()<br /> <br /> If a newly-added link type doesn&amp;#39;t invoke BPF_LINK_TYPE(), accessing<br /> bpf_link_type_strs[link-&gt;type] may result in an out-of-bounds access.<br /> <br /> To spot such missed invocations early in the future, checking the<br /> validity of link-&gt;type in bpf_link_show_fdinfo() and emitting a warning<br /> when such invocations are missed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: tcp: avoid race between queue_lock lock and destroy<br /> <br /> Commit 76d54bf20cdc ("nvme-tcp: don&amp;#39;t access released socket during<br /> error recovery") added a mutex_lock() call for the queue-&gt;queue_lock<br /> in nvme_tcp_get_address(). However, the mutex_lock() races with<br /> mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below.<br /> <br /> DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)<br /> WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220<br /> Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs]<br /> CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014<br /> RIP: 0010:__mutex_lock+0xcf0/0x1220<br /> Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1<br /> RSP: 0018:ffff88811305f760 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001<br /> RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341<br /> R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000<br /> R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058<br /> FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __warn.cold+0x5b/0x1af<br /> ? __mutex_lock+0xcf0/0x1220<br /> ? report_bug+0x1ec/0x390<br /> ? handle_bug+0x3c/0x80<br /> ? exc_invalid_op+0x13/0x40<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? __mutex_lock+0xcf0/0x1220<br /> ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]<br /> ? __pfx___mutex_lock+0x10/0x10<br /> ? __lock_acquire+0xd6a/0x59e0<br /> ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]<br /> nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]<br /> ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp]<br /> nvme_sysfs_show_address+0x81/0xc0 [nvme_core]<br /> dev_attr_show+0x42/0x80<br /> ? __asan_memset+0x1f/0x40<br /> sysfs_kf_seq_show+0x1f0/0x370<br /> seq_read_iter+0x2cb/0x1130<br /> ? rw_verify_area+0x3b1/0x590<br /> ? __mutex_lock+0x433/0x1220<br /> vfs_read+0x6a6/0xa20<br /> ? lockdep_hardirqs_on+0x78/0x100<br /> ? __pfx_vfs_read+0x10/0x10<br /> ksys_read+0xf7/0x1d0<br /> ? __pfx_ksys_read+0x10/0x10<br /> ? __x64_sys_openat+0x105/0x1d0<br /> do_syscall_64+0x93/0x180<br /> ? lockdep_hardirqs_on_prepare+0x16d/0x400<br /> ? do_syscall_64+0x9f/0x180<br /> ? lockdep_hardirqs_on+0x78/0x100<br /> ? do_syscall_64+0x9f/0x180<br /> ? __pfx_ksys_read+0x10/0x10<br /> ? lockdep_hardirqs_on_prepare+0x16d/0x400<br /> ? do_syscall_64+0x9f/0x180<br /> ? lockdep_hardirqs_on+0x78/0x100<br /> ? do_syscall_64+0x9f/0x180<br /> ? lockdep_hardirqs_on_prepare+0x16d/0x400<br /> ? do_syscall_64+0x9f/0x180<br /> ? lockdep_hardirqs_on+0x78/0x100<br /> ? do_syscall_64+0x9f/0x180<br /> ? lockdep_hardirqs_on_prepare+0x16d/0x400<br /> ? do_syscall_64+0x9f/0x180<br /> ? lockdep_hardirqs_on+0x78/0x100<br /> ? do_syscall_64+0x9f/0x180<br /> ? lockdep_hardirqs_on_prepare+0x16d/0x400<br /> ? do_syscall_64+0x9f/0x180<br /> ? lockdep_hardirqs_on+0x78/0x100<br /> ? do_syscall_64+0x9f/0x180<br /> ? do_syscall_64+0x9f/0x180<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f9713f55cfa<br /> Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: resolve faulty mmap_region() error path behaviour<br /> <br /> The mmap_region() function is somewhat terrifying, with spaghetti-like<br /> control flow and numerous means by which issues can arise and incomplete<br /> state, memory leaks and other unpleasantness can occur.<br /> <br /> A large amount of the complexity arises from trying to handle errors late<br /> in the process of mapping a VMA, which forms the basis of recently<br /> observed issues with resource leaks and observable inconsistent state.<br /> <br /> Taking advantage of previous patches in this series we move a number of<br /> checks earlier in the code, simplifying things by moving the core of the<br /> logic into a static internal function __mmap_region().<br /> <br /> Doing this allows us to perform a number of checks up front before we do<br /> any real work, and allows us to unwind the writable unmap check<br /> unconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE<br /> validation unconditionally also.<br /> <br /> We move a number of things here:<br /> <br /> 1. We preallocate memory for the iterator before we call the file-backed<br /> memory hook, allowing us to exit early and avoid having to perform<br /> complicated and error-prone close/free logic. We carefully free<br /> iterator state on both success and error paths.<br /> <br /> 2. The enclosing mmap_region() function handles the mapping_map_writable()<br /> logic early. Previously the logic had the mapping_map_writable() at the<br /> point of mapping a newly allocated file-backed VMA, and a matching<br /> mapping_unmap_writable() on success and error paths.<br /> <br /> We now do this unconditionally if this is a file-backed, shared writable<br /> mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however<br /> doing so does not invalidate the seal check we just performed, and we in<br /> any case always decrement the counter in the wrapper.<br /> <br /> We perform a debug assert to ensure a driver does not attempt to do the<br /> opposite.<br /> <br /> 3. We also move arch_validate_flags() up into the mmap_region()<br /> function. This is only relevant on arm64 and sparc64, and the check is<br /> only meaningful for SPARC with ADI enabled. We explicitly add a warning<br /> for this arch if a driver invalidates this check, though the code ought<br /> eventually to be fixed to eliminate the need for this.<br /> <br /> With all of these measures in place, we no longer need to explicitly close<br /> the VMA on error paths, as we place all checks which might fail prior to a<br /> call to any driver mmap hook.<br /> <br /> This eliminates an entire class of errors, makes the code easier to reason<br /> about and more robust.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: krealloc: Fix MTE false alarm in __do_krealloc<br /> <br /> This patch addresses an issue introduced by commit 1a83a716ec233 ("mm:<br /> krealloc: consider spare memory for __GFP_ZERO") which causes MTE<br /> (Memory Tagging Extension) to falsely report a slab-out-of-bounds error.<br /> <br /> The problem occurs when zeroing out spare memory in __do_krealloc. The<br /> original code only considered software-based KASAN and did not account<br /> for MTE. It does not reset the KASAN tag before calling memset, leading<br /> to a mismatch between the pointer tag and the memory tag, resulting<br /> in a false positive.<br /> <br /> Example of the error:<br /> ==================================================================<br /> swapper/0: BUG: KASAN: slab-out-of-bounds in __memset+0x84/0x188<br /> swapper/0: Write at addr f4ffff8005f0fdf0 by task swapper/0/1<br /> swapper/0: Pointer tag: [f4], memory tag: [fe]<br /> swapper/0:<br /> swapper/0: CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.<br /> swapper/0: Hardware name: MT6991(ENG) (DT)<br /> swapper/0: Call trace:<br /> swapper/0: dump_backtrace+0xfc/0x17c<br /> swapper/0: show_stack+0x18/0x28<br /> swapper/0: dump_stack_lvl+0x40/0xa0<br /> swapper/0: print_report+0x1b8/0x71c<br /> swapper/0: kasan_report+0xec/0x14c<br /> swapper/0: __do_kernel_fault+0x60/0x29c<br /> swapper/0: do_bad_area+0x30/0xdc<br /> swapper/0: do_tag_check_fault+0x20/0x34<br /> swapper/0: do_mem_abort+0x58/0x104<br /> swapper/0: el1_abort+0x3c/0x5c<br /> swapper/0: el1h_64_sync_handler+0x80/0xcc<br /> swapper/0: el1h_64_sync+0x68/0x6c<br /> swapper/0: __memset+0x84/0x188<br /> swapper/0: btf_populate_kfunc_set+0x280/0x3d8<br /> swapper/0: __register_btf_kfunc_id_set+0x43c/0x468<br /> swapper/0: register_btf_kfunc_id_set+0x48/0x60<br /> swapper/0: register_nf_nat_bpf+0x1c/0x40<br /> swapper/0: nf_nat_init+0xc0/0x128<br /> swapper/0: do_one_initcall+0x184/0x464<br /> swapper/0: do_initcall_level+0xdc/0x1b0<br /> swapper/0: do_initcalls+0x70/0xc0<br /> swapper/0: do_basic_setup+0x1c/0x28<br /> swapper/0: kernel_init_freeable+0x144/0x1b8<br /> swapper/0: kernel_init+0x20/0x1a8<br /> swapper/0: ret_from_fork+0x10/0x20<br /> ==================================================================

An Open Redirect vulnerability in Taiga v6.8.1 allows attackers to redirect users to arbitrary websites via appending a crafted link to /login?next= in the login page URL.

Incorrect access control in Adapt Learning Adapt Authoring Tool

A NoSQL injection vulnerability in Adapt Learning Adapt Authoring Tool

Autolab is a course management service that enables auto-graded programming assignments. From Autolab versions v.3.0.0 onward students can download all assignments from another student, as long as they are logged in, using the download_all_submissions feature. This can allow for leakage of submissions to unauthorized users, such as downloading submissions from other students in the class, or even instructor test submissions, given they know their user IDs. This issue has been patched in commit `1aa4c769` which is not yet in a release version, but is expected to be included in version 3.0.3. Users are advised to either manually patch or to wait for version 3.0.3. As a workaround administrators can disable the feature.

SvelteKit is a framework for rapidly developing robust, performant web applications using Svelte. "Unsanitized input from *the request URL* flows into `end`, where it is used to render an HTML page returned to the user. This may result in a Cross-Site Scripting attack (XSS)." The files `packages/kit/src/exports/vite/dev/index.js` and `packages/kit/src/exports/vite/utils.js` both contain user controllable data which under specific conditions may flow to dev mode pages. There is little to no expected impact. The Vite development is not exposed to the network by default and even if someone were able to trick a developer into executing an XSS against themselves, a development database should not have any sensitive data. None the less this issue has been addressed in version 2.8.3 and all users are advised to upgrade.

SvelteKit is a framework for rapidly developing robust, performant web applications using Svelte. The static error.html template for errors contains placeholders that are replaced without escaping the content first. error.html is the page that is rendered when everything else fails. It can contain the following placeholders: %sveltekit.status% — the HTTP status, and %sveltekit.error.message% — the error message. This leads to possible injection if an app explicitly creates an error with a message that contains user controlled content. Only applications where user provided input is used in the `Error` message will be vulnerable, so the vast majority of applications will not be vulnerable This issue has been addressed in version 2.8.3 and all users are advised to upgrade. There are no known workarounds for this vulnerability.

Joplin is an open source, privacy-focused note taking app with sync capabilities for Windows, macOS, Linux, Android and iOS. In affected versions attackers are able to abuse the fact that openExternal is used without any filtering of URI schemes to obtain remote code execution in Windows environments. This issue has been addressed in version 3.0.3 and all users are advised to upgrade. There are no known workarounds for this vulnerability.

Cilium is a networking, observability, and security solution with an eBPF-based dataplane. For users with the following configuration: 1. An allow policy that selects a Layer 3 destination and a port range `AND` 2. A Layer 7 allow policy that selects a specific port within the first policy&amp;#39;s range the Layer 7 enforcement would not occur for the traffic selected by the Layer 7 policy. This issue only affects users who use Cilium&amp;#39;s port range functionality, which was introduced in Cilium v1.16. This issue is patched in PR #35150. This issue affects Cilium v1.16 between v1.16.0 and v1.16.3 inclusive. This issue is patched in Cilium v1.16.4. Users are advised to upgrade. Users with network policies that match the pattern described above can work around the issue by rewriting any policies that use port ranges to individually specify the ports permitted for traffic.