Vulnerabilities

A Client-Side Template Injection (CSTI) vulnerability in the component /project/new/scrum of Taiga v 8.6.1 allows remote attackers to execute arbitrary code by injecting a malicious payload within the new project details.

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 /> fs: Fix uninitialized value issue in from_kuid and from_kgid<br /> <br /> ocfs2_setattr() uses attr-&gt;ia_mode, attr-&gt;ia_uid and attr-&gt;ia_gid in<br /> a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren&amp;#39;t set.<br /> <br /> Initialize all fields of newattrs to avoid uninitialized variables, by<br /> checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/ufence: Prefetch ufence addr to catch bogus address<br /> <br /> access_ok() only checks for addr overflow so also try to read the addr<br /> to catch invalid addr sent from userspace.<br /> <br /> (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)

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.