Vulnerabilities

The CodeQL CLI repo holds binaries for the CodeQL command line interface (CLI). Prior to version 2.16.3, an XML parser used by the CodeQL CLI to read various auxiliary files is vulnerable to an XML External Entity attack. If a vulnerable version of the CLI is used to process either a maliciously modified CodeQL database, or a specially prepared set of QL query sources, the CLI can be made to make an outgoing HTTP request to an URL that contains material read from a local file chosen by the attacker. This may result in a loss of privacy of exfiltration of secrets. Security researchers and QL authors who receive databases or QL source files from untrusted sources may be impacted. A single untrusted `.ql` or `.qll` file cannot be affected, but a zip archive or tarball containing QL sources may unpack auxiliary files that will trigger an attack when CodeQL sees them in the file system. Those using CodeQL for routine analysis of source trees with a preselected set of trusted queries are not affected. In particular, extracting XML files from a source tree into the CodeQL database does not make one vulnerable. The problem is fixed in release 2.16.3 of the CodeQL CLI. Other than upgrading, workarounds include not accepting CodeQL databases or queries from untrusted sources, or only processing such material on a machine without an Internet connection. Customers who use older releases of CodeQL for security scanning in an automated CI system and cannot upgrade for compliance reasons can continue using that version. That use case is safe. If such customers have a private query pack and use the `codeql pack create` command to precompile them before using them in the CI system, they should be using the production CodeQL release to run `codeql pack create`. That command is safe as long as the QL source it precompiled is trusted. All other development of the query pack should use an upgraded CLI.

Tuleap is an open source suite to improve management of software developments and collaboration. Prior to version 15.5.99.76 of Tuleap Community Edition and prior to versions 15.5-4 and 15.4-7 of Tuleap Enterprise Edition, users with a read access to a tracker where the mass update feature is used might get access to restricted information. Tuleap Community Edition 15.5.99.76, Tuleap Enterprise Edition 15.5-4, and Tuleap Enterprise Edition 15.4-7 contain a patch for this issue.

Discourse Calendar adds the ability to create a dynamic calendar in the first post of a topic on the open-source discussion platform Discourse. Prior to version 0.4, event invitees created in topics in private categories or PMs (private messages) can be retrieved by anyone, even if they're not logged in. This problem is resolved in version 0.4 of the discourse-calendar plugin. While no known workaround is available, putting the site behind `login_required` will disallow this endpoint to be used by anonymous users, but logged in users can still get the list of invitees in the private topics.

SKINsoft S-Museum 7.02.3 allows Unrestricted File Upload via the Add Media function. Unlike in CVE-2024-25801, the attack payload is the file content.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS<br /> <br /> For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off<br /> for validation. However, variable offset ptr alu is not prohibited<br /> for this ptr kind. So the variable offset is not checked.<br /> <br /> The following prog is accepted:<br /> <br /> func#0 @0<br /> 0: R1=ctx() R10=fp0<br /> 0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx()<br /> 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys()<br /> 2: (b7) r8 = 1024 ; R8_w=1024<br /> 3: (37) r8 /= 1 ; R8_w=scalar()<br /> 4: (57) r8 &amp;= 1024 ; R8_w=scalar(smin=smin32=0,<br /> smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400))<br /> 5: (0f) r7 += r8<br /> mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1<br /> mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &amp;= 1024<br /> mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1<br /> mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024<br /> 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off<br /> =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024,<br /> var_off=(0x0; 0x400))<br /> 6: (79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar()<br /> 7: (95) exit<br /> <br /> This prog loads flow_keys to r7, and adds the variable offset r8<br /> to r7, and finally causes out-of-bounds access:<br /> <br /> BUG: unable to handle page fault for address: ffffc90014c80038<br /> [...]<br /> Call Trace:<br /> <br /> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline]<br /> __bpf_prog_run include/linux/filter.h:651 [inline]<br /> bpf_prog_run include/linux/filter.h:658 [inline]<br /> bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline]<br /> bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991<br /> bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359<br /> bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline]<br /> __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475<br /> __do_sys_bpf kernel/bpf/syscall.c:5561 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]<br /> __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> Fix this by rejecting ptr alu with variable offset on flow_keys.<br /> Applying the patch rejects the program with "R7 pointer arithmetic<br /> on flow_keys prohibited".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix inconsistent per-file compression format<br /> <br /> EROFS can select compression algorithms on a per-file basis, and each<br /> per-file compression algorithm needs to be marked in the on-disk<br /> superblock for initialization.<br /> <br /> However, syzkaller can generate inconsistent crafted images that use<br /> an unsupported algorithmtype for specific inodes, e.g. use MicroLZMA<br /> algorithmtype even it&amp;#39;s not set in `sbi-&gt;available_compr_algs`. This<br /> can lead to an unexpected "BUG: kernel NULL pointer dereference" if<br /> the corresponding decompressor isn&amp;#39;t built-in.<br /> <br /> Fix this by checking against `sbi-&gt;available_compr_algs` for each<br /> m_algorithmformat request. Incorrect !erofs_sb_has_compr_cfgs preset<br /> bitmap is now fixed together since it was harmless previously.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix re-attachment branch in bpf_tracing_prog_attach<br /> <br /> The following case can cause a crash due to missing attach_btf:<br /> <br /> 1) load rawtp program<br /> 2) load fentry program with rawtp as target_fd<br /> 3) create tracing link for fentry program with target_fd = 0<br /> 4) repeat 3<br /> <br /> In the end we have:<br /> <br /> - prog-&gt;aux-&gt;dst_trampoline == NULL<br /> - tgt_prog == NULL (because we did not provide target_fd to link_create)<br /> - prog-&gt;aux-&gt;attach_btf == NULL (the program was loaded with attach_prog_fd=X)<br /> - the program was loaded for tgt_prog but we have no way to find out which one<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000058<br /> Call Trace:<br /> <br /> ? __die+0x20/0x70<br /> ? page_fault_oops+0x15b/0x430<br /> ? fixup_exception+0x22/0x330<br /> ? exc_page_fault+0x6f/0x170<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? bpf_tracing_prog_attach+0x279/0x560<br /> ? btf_obj_id+0x5/0x10<br /> bpf_tracing_prog_attach+0x439/0x560<br /> __sys_bpf+0x1cf4/0x2de0<br /> __x64_sys_bpf+0x1c/0x30<br /> do_syscall_64+0x41/0xf0<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> Return -EINVAL in this situation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix UAF issue in ksmbd_tcp_new_connection()<br /> <br /> The race is between the handling of a new TCP connection and<br /> its disconnection. It leads to UAF on `struct tcp_transport` in<br /> ksmbd_tcp_new_connection() function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: avoid crash when parsed profile name is empty<br /> <br /> When processing a packed profile in unpack_profile() described like<br /> <br /> "profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}"<br /> <br /> a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then<br /> passed to aa_splitn_fqname().<br /> <br /> aa_splitn_fqname() treats ":samba-dcerpcd" as only containing a namespace.<br /> Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later<br /> aa_alloc_profile() crashes as the new profile name is NULL now.<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014<br /> RIP: 0010:strlen+0x1e/0xa0<br /> Call Trace:<br /> <br /> ? strlen+0x1e/0xa0<br /> aa_policy_init+0x1bb/0x230<br /> aa_alloc_profile+0xb1/0x480<br /> unpack_profile+0x3bc/0x4960<br /> aa_unpack+0x309/0x15e0<br /> aa_replace_profiles+0x213/0x33c0<br /> policy_update+0x261/0x370<br /> profile_replace+0x20e/0x2a0<br /> vfs_write+0x2af/0xe00<br /> ksys_write+0x126/0x250<br /> do_syscall_64+0x46/0xf0<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:strlen+0x1e/0xa0<br /> <br /> It seems such behaviour of aa_splitn_fqname() is expected and checked in<br /> other places where it is called (e.g. aa_remove_profiles). Well, there<br /> is an explicit comment "a ns name without a following profile is allowed"<br /> inside.<br /> <br /> AFAICS, nothing can prevent unpacked "name" to be in form like<br /> ":samba-dcerpcd" - it is passed from userspace.<br /> <br /> Deny the whole profile set replacement in such case and inform user with<br /> EPROTO and an explaining message.<br /> <br /> Found by Linux Verification Center (linuxtesting.org).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid dirent corruption<br /> <br /> As Al reported in link[1]:<br /> <br /> f2fs_rename()<br /> ...<br /> if (old_dir != new_dir &amp;&amp; !whiteout)<br /> f2fs_set_link(old_inode, old_dir_entry,<br /> old_dir_page, new_dir);<br /> else<br /> f2fs_put_page(old_dir_page, 0);<br /> <br /> You want correct inumber in the ".." link. And cross-directory<br /> rename does move the source to new parent, even if you&amp;#39;d been asked<br /> to leave a whiteout in the old place.<br /> <br /> [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/<br /> <br /> With below testcase, it may cause dirent corruption, due to it missed<br /> to call f2fs_set_link() to update ".." link to new directory.<br /> - mkdir -p dir/foo<br /> - renameat2 -w dir/foo bar<br /> <br /> [ASSERT] (__chk_dots_dentries:1421) --&gt; Bad inode number[0x4] for &amp;#39;..&amp;#39;, parent parent ino is [0x3]<br /> [FSCK] other corrupted bugs [Fail]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: pvrusb2: fix use after free on context disconnection<br /> <br /> Upon module load, a kthread is created targeting the<br /> pvr2_context_thread_func function, which may call pvr2_context_destroy<br /> and thus call kfree() on the context object. However, that might happen<br /> before the usb hub_event handler is able to notify the driver. This<br /> patch adds a sanity check before the invalid read reported by syzbot,<br /> within the context disconnection call stack.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix a race condition between btf_put() and map_free()<br /> <br /> When running `./test_progs -j` in my local vm with latest kernel,<br /> I once hit a kasan error like below:<br /> <br /> [ 1887.184724] BUG: KASAN: slab-use-after-free in bpf_rb_root_free+0x1f8/0x2b0<br /> [ 1887.185599] Read of size 4 at addr ffff888106806910 by task kworker/u12:2/2830<br /> [ 1887.186498]<br /> [ 1887.186712] CPU: 3 PID: 2830 Comm: kworker/u12:2 Tainted: G OEL 6.7.0-rc3-00699-g90679706d486-dirty #494<br /> [ 1887.188034] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 1887.189618] Workqueue: events_unbound bpf_map_free_deferred<br /> [ 1887.190341] Call Trace:<br /> [ 1887.190666] <br /> [ 1887.190949] dump_stack_lvl+0xac/0xe0<br /> [ 1887.191423] ? nf_tcp_handle_invalid+0x1b0/0x1b0<br /> [ 1887.192019] ? panic+0x3c0/0x3c0<br /> [ 1887.192449] print_report+0x14f/0x720<br /> [ 1887.192930] ? preempt_count_sub+0x1c/0xd0<br /> [ 1887.193459] ? __virt_addr_valid+0xac/0x120<br /> [ 1887.194004] ? bpf_rb_root_free+0x1f8/0x2b0<br /> [ 1887.194572] kasan_report+0xc3/0x100<br /> [ 1887.195085] ? bpf_rb_root_free+0x1f8/0x2b0<br /> [ 1887.195668] bpf_rb_root_free+0x1f8/0x2b0<br /> [ 1887.196183] ? __bpf_obj_drop_impl+0xb0/0xb0<br /> [ 1887.196736] ? preempt_count_sub+0x1c/0xd0<br /> [ 1887.197270] ? preempt_count_sub+0x1c/0xd0<br /> [ 1887.197802] ? _raw_spin_unlock+0x1f/0x40<br /> [ 1887.198319] bpf_obj_free_fields+0x1d4/0x260<br /> [ 1887.198883] array_map_free+0x1a3/0x260<br /> [ 1887.199380] bpf_map_free_deferred+0x7b/0xe0<br /> [ 1887.199943] process_scheduled_works+0x3a2/0x6c0<br /> [ 1887.200549] worker_thread+0x633/0x890<br /> [ 1887.201047] ? __kthread_parkme+0xd7/0xf0<br /> [ 1887.201574] ? kthread+0x102/0x1d0<br /> [ 1887.202020] kthread+0x1ab/0x1d0<br /> [ 1887.202447] ? pr_cont_work+0x270/0x270<br /> [ 1887.202954] ? kthread_blkcg+0x50/0x50<br /> [ 1887.203444] ret_from_fork+0x34/0x50<br /> [ 1887.203914] ? kthread_blkcg+0x50/0x50<br /> [ 1887.204397] ret_from_fork_asm+0x11/0x20<br /> [ 1887.204913] <br /> [ 1887.204913] <br /> [ 1887.205209]<br /> [ 1887.205416] Allocated by task 2197:<br /> [ 1887.205881] kasan_set_track+0x3f/0x60<br /> [ 1887.206366] __kasan_kmalloc+0x6e/0x80<br /> [ 1887.206856] __kmalloc+0xac/0x1a0<br /> [ 1887.207293] btf_parse_fields+0xa15/0x1480<br /> [ 1887.207836] btf_parse_struct_metas+0x566/0x670<br /> [ 1887.208387] btf_new_fd+0x294/0x4d0<br /> [ 1887.208851] __sys_bpf+0x4ba/0x600<br /> [ 1887.209292] __x64_sys_bpf+0x41/0x50<br /> [ 1887.209762] do_syscall_64+0x4c/0xf0<br /> [ 1887.210222] entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> [ 1887.210868]<br /> [ 1887.211074] Freed by task 36:<br /> [ 1887.211460] kasan_set_track+0x3f/0x60<br /> [ 1887.211951] kasan_save_free_info+0x28/0x40<br /> [ 1887.212485] ____kasan_slab_free+0x101/0x180<br /> [ 1887.213027] __kmem_cache_free+0xe4/0x210<br /> [ 1887.213514] btf_free+0x5b/0x130<br /> [ 1887.213918] rcu_core+0x638/0xcc0<br /> [ 1887.214347] __do_softirq+0x114/0x37e<br /> <br /> The error happens at bpf_rb_root_free+0x1f8/0x2b0:<br /> <br /> 00000000000034c0 :<br /> ; {<br /> 34c0: f3 0f 1e fa endbr64<br /> 34c4: e8 00 00 00 00 callq 0x34c9 <br /> 34c9: 55 pushq %rbp<br /> 34ca: 48 89 e5 movq %rsp, %rbp<br /> ...<br /> ; if (rec &amp;&amp; rec-&gt;refcount_off &gt;= 0 &amp;&amp;<br /> 36aa: 4d 85 ed testq %r13, %r13<br /> 36ad: 74 a9 je 0x3658 <br /> 36af: 49 8d 7d 10 leaq 0x10(%r13), %rdi<br /> 36b3: e8 00 00 00 00 callq 0x36b8 <br />