deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2023-52447
Published: 2024-02-22
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Defer the free of inner map when necessary

When updating or deleting an inner map in map array or map htab, the map
may still be accessed by non-sleepable program or sleepable program.
However bpf_map_fd_put_ptr() decreases the ref-counter of the inner map
directly through bpf_map_put(), if the ref-counter is the last one
(which is true for most cases), the inner map will be freed by
ops->map_free() in a kworker. But for now, most .map_free() callbacks
don't use synchronize_rcu() or its variants to wait for the elapse of a
RCU grace period, so after the invocation of ops->map_free completes,
the bpf program which is accessing the inner map may incur
use-after-free problem.

Fix the free of inner map by invoking bpf_map_free_deferred() after both
one RCU grace period and one tasks trace RCU grace period if the inner
map has been removed from the outer map before. The deferment is
accomplished by using call_rcu() or call_rcu_tasks_trace() when
releasing the last ref-counter of bpf map. The newly-added rcu_head
field in bpf_map shares the same storage space with work field to
reduce the size of bpf_map.
CVSS Score: 6.7 (MEDIUM)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/37d98fb9c3144c0fddf7f6e99aece9927ac8dce6; https://git.kernel.org/stable/c/62fca83303d608ad4fec3f7428c8685680bb01b0; https://git.kernel.org/stable/c/[PII_REDACTED]61da50eed6b472d746ef88242b2368
CVE: CVE-2023-52448
Published: 2024-02-22
Description: In the Linux kernel, the following vulnerability has been resolved:

gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump

Syzkaller has reported a NULL pointer dereference when accessing
rgd->rd_rgl in gfs2_rgrp_dump().  This can happen when creating
rgd->rd_gl fails in read_rindex_entry().  Add a NULL pointer check in
gfs2_rgrp_dump() to prevent that.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/067a7c48c2c70f05f9460d6f0e8423e234729f05; https://git.kernel.org/stable/c/5c28478af371a1c3fdb570ca67f110e1ae60fc37; https://git.kernel.org/stable/c/8877243beafa7c6bfc42022cbfdf9e39b25bd4fa
CVE: CVE-2023-52449
Published: 2024-02-22
Description: In the Linux kernel, the following vulnerability has been resolved:

mtd: Fix gluebi NULL pointer dereference caused by ftl notifier

If both ftl.ko and gluebi.ko are loaded, the notifier of ftl
triggers NULL pointer dereference when trying to access
‘gluebi->desc’ in gluebi_read().

ubi_gluebi_init
  ubi_register_volume_notifier
    ubi_enumerate_volumes
      ubi_notify_all
        gluebi_notify    nb->notifier_call()
          gluebi_create
            mtd_device_register
              mtd_device_parse_register
                add_mtd_device
                  blktrans_notify_add   not->add()
                    ftl_add_mtd         tr->add_mtd()
                      scan_header
                        mtd_read
                          mtd_read_oob
                            mtd_read_oob_std
                              gluebi_read   mtd->read()
                                gluebi->desc - NULL

Detailed reproduction information available at the Link [1],

In the normal case, obtain gluebi->desc in the gluebi_get_device(),
and access gluebi->desc in the gluebi_read(). However,
gluebi_get_device() is not executed in advance in the
ftl_add_mtd() process, which leads to NULL pointer dereference.

The solution for the gluebi module is to run jffs2 on the UBI
volume without considering working with ftl or mtdblock [2].
Therefore, this problem can be avoided by preventing gluebi from
creating the mtdblock device after creating mtd partition of the
type MTD_UBIVOLUME.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/001a3f59d8c914ef8273461d4bf495df384cc5f8; https://git.kernel.org/stable/c/1bf4fe14e97cda621522eb2f28b0a4e87c5b0745; https://git.kernel.org/stable/c/5389407bba1eab1266c6d83e226fb0840cb98dd5
CVE: CVE-2023-52450
Published: 2024-02-22
Description: In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel/uncore: Fix NULL pointer dereference issue in upi_fill_topology()

Get logical socket id instead of physical id in discover_upi_topology()
to avoid out-of-bound access on 'upi = &type->topology[nid][idx];' line
that leads to NULL pointer dereference in upi_fill_topology()
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1692cf434ba13ee212495b5af795b6a07e986ce4; https://git.kernel.org/stable/c/3d6f4a78b104c65e4256c3776c9949f49a1b459e; https://git.kernel.org/stable/c/bf1bf09e6b[PII_REDACTED]57f[PII_REDACTED]a48d015
CVE: CVE-2023-52451
Published: 2024-02-22
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/pseries/memhp: Fix access beyond end of drmem array

dlpar_memory_remove_by_index() may access beyond the bounds of the
drmem lmb array when the LMB lookup fails to match an entry with the
given DRC index. When the search fails, the cursor is left pointing to
&drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the
last valid entry in the array. The debug message at the end of the
function then dereferences this pointer:

        pr_debug("Failed to hot-remove memory at %llx\n",
                 lmb->base_addr);

This was found by inspection and confirmed with KASAN:

  pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234
  ==================================================================
  BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658
  Read of size 8 at addr c000000364e97fd0 by task bash/949

  dump_stack_lvl+0xa4/0xfc (unreliable)
  print_report+0x214/0x63c
  kasan_report+0x140/0x2e0
  __asan_load8+0xa8/0xe0
  dlpar_memory+0x298/0x1658
  handle_dlpar_errorlog+0x130/0x1d0
  dlpar_store+0x18c/0x3e0
  kobj_attr_store+0x68/0xa0
  sysfs_kf_write+0xc4/0x110
  kernfs_fop_write_iter+0x26c/0x390
  vfs_write+0x2d4/0x4e0
  ksys_write+0xac/0x1a0
  system_call_exception+0x268/0x530
  system_call_vectored_common+0x15c/0x2ec

  Allocated by task 1:
   kasan_save_stack+0x48/0x80
   kasan_set_track+0x34/0x50
   kasan_save_alloc_info+0x34/0x50
   __kasan_kmalloc+0xd0/0x120
   __kmalloc+0x8c/0x320
   kmalloc_array.constprop.0+0x48/0x5c
   drmem_init+0x2a0/0x41c
   do_one_initcall+0xe0/0x5c0
   kernel_init_freeable+0x4ec/0x5a0
   kernel_init+0x30/0x1e0
   ret_from_kernel_user_thread+0x14/0x1c

  The buggy address belongs to the object at c000000364e80000
   which belongs to the cache kmalloc-128k of size 131072
  The buggy address is located 0 bytes to the right of
   allocated 98256-byte region [c000000364e80000, c000000364e97fd0)

  ==================================================================
  pseries-hotplug-mem: Failed to hot-remove memory at 0

Log failed lookups with a separate message and dereference the
cursor only when it points to a valid entry.
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/026fd977dc50ff4a5e09bfb0603557f104d3f3a0; https://git.kernel.org/stable/c/708a4b59baad96c4718dc0bd3a3427d3ab22fedc; https://git.kernel.org/stable/c/999a27b3ce9a69d54ccd5db000ec3a447bc43e6d
CVE: CVE-2023-52452
Published: 2024-02-22
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix accesses to uninit stack slots

Privileged programs are supposed to be able to read uninitialized stack
memory (ever since 6715df8d5) but, before this patch, these accesses
were permitted inconsistently. In particular, accesses were permitted
above state->allocated_stack, but not below it. In other words, if the
stack was already "large enough", the access was permitted, but
otherwise the access was rejected instead of being allowed to "grow the
stack". This undesired rejection was happening in two places:
- in check_stack_slot_within_bounds()
- in check_stack_range_initialized()
This patch arranges for these accesses to be permitted. A bunch of tests
that were relying on the old rejection had to change; all of them were
changed to add also run unprivileged, in which case the old behavior
persists. One tests couldn't be updated - global_func16 - because it
can't run unprivileged for other reasons.

This patch also fixes the tracking of the stack size for variable-offset
reads. This second fix is bundled in the same commit as the first one
because they're inter-related. Before this patch, writes to the stack
using registers containing a variable offset (as opposed to registers
with fixed, known values) were not properly contributing to the
function's needed stack size. As a result, it was possible for a program
to verify, but then to attempt to read out-of-bounds data at runtime
because a too small stack had been allocated for it.

Each function tracks the size of the stack it needs in
bpf_subprog_info.stack_depth, which is maintained by
update_stack_depth(). For regular memory accesses, check_mem_access()
was calling update_state_depth() but it was passing in only the fixed
part of the offset register, ignoring the variable offset. This was
incorrect; the minimum possible value of that register should be used
instead.

This tracking is now fixed by centralizing the tracking of stack size in
grow_stack_state(), and by lifting the calls to grow_stack_state() to
check_stack_access_within_bounds() as suggested by Andrii. The code is
now simpler and more convincingly tracks the correct maximum stack size.
check_stack_range_initialized() can now rely on enough stack having been
allocated for the access; this helps with the fix for the first issue.

A few tests were changed to also check the stack depth computation. The
one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.
CVSS Score: 7.8 (HIGH)
CWE: CWE-665
References: https://git.kernel.org/stable/c/0954982db8283016bf38e9db2da5adf47a102e19; https://git.kernel.org/stable/c/6b4a64bafd107e521c01eec3453ce94a3fb38529; https://git.kernel.org/stable/c/fbcf372c8eda[PII_REDACTED]e0afb5ab5d5f5d5fde
CVE: CVE-2024-26586
Published: 2024-02-22
Description: In the Linux kernel, the following vulnerability has been resolved:

mlxsw: spectrum_acl_tcam: Fix stack corruption

When tc filters are first added to a net device, the corresponding local
port gets bound to an ACL group in the device. The group contains a list
of ACLs. In turn, each ACL points to a different TCAM region where the
filters are stored. During forwarding, the ACLs are sequentially
evaluated until a match is found.

One reason to place filters in different regions is when they are added
with decreasing priorities and in an alternating order so that two
consecutive filters can never fit in the same region because of their
key usage.

In Spectrum-2 and newer ASICs the firmware started to report that the
maximum number of ACLs in a group is more than 16, but the layout of the
register that configures ACL groups (PAGT) was not updated to account
for that. It is therefore possible to hit stack corruption [1] in the
rare case where more than 16 ACLs in a group are required.

Fix by limiting the maximum ACL group size to the minimum between what
the firmware reports and the maximum ACLs that fit in the PAGT register.

Add a test case to make sure the machine does not crash when this
condition is hit.

[1]
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120
[...]
 dump_stack_lvl+0x36/0x50
 panic+0x305/0x330
 __stack_chk_fail+0x15/0x20
 mlxsw_sp_acl_tcam_group_update+0x116/0x120
 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110
 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20
 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0
 mlxsw_sp_acl_rule_add+0x47/0x240
 mlxsw_sp_flower_replace+0x1a9/0x1d0
 tc_setup_cb_add+0xdc/0x1c0
 fl_hw_replace_filter+0x146/0x1f0
 fl_change+0xc17/0x1360
 tc_new_tfilter+0x472/0xb90
 rtnetlink_rcv_msg+0x313/0x3b0
 netlink_rcv_skb+0x58/0x100
 netlink_unicast+0x244/0x390
 netlink_sendmsg+0x1e4/0x440
 ____sys_sendmsg+0x164/0x260
 ___sys_sendmsg+0x9a/0xe0
 __sys_sendmsg+0x7a/0xc0
 do_syscall_64+0x40/0xe0
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
CVSS Score: 6.7 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/2f5e[PII_REDACTED]06332c06f36211d4ce0f88e62; https://git.kernel.org/stable/c/348112522a35527c5bcba933b9fefb40a4f44f15; https://git.kernel.org/stable/c/483ae90d8f976f8339cf81066312e1329f2d3706
CVE: CVE-2024-26587
Published: 2024-02-22
Description: In the Linux kernel, the following vulnerability has been resolved:

net: netdevsim: don't try to destroy PHC on VFs

PHC gets initialized in nsim_init_netdevsim(), which
is only called if (nsim_dev_port_is_pf()).

Create a counterpart of nsim_init_netdevsim() and
move the mock_phc_destroy() there.

This fixes a crash trying to destroy netdevsim with
VFs instantiated, as caught by running the devlink.sh test:

    BUG: kernel NULL pointer dereference, address:[PII_REDACTED]0000b8
    RIP: 0010:mock_phc_destroy+0xd/0x30
    Call Trace:
     <TASK>
     nsim_destroy+0x4a/0x70 [netdevsim]
     __nsim_dev_port_del+0x47/0x70 [netdevsim]
     nsim_dev_reload_destroy+0x105/0x120 [netdevsim]
     nsim_drv_remove+0x2f/0xb0 [netdevsim]
     device_release_driver_internal+0x1a1/0x210
     bus_remove_device+0xd5/0x120
     device_del+0x159/0x490
     device_unregister+0x12/0x30
     del_device_store+0x11a/0x1a0 [netdevsim]
     kernfs_fop_write_iter+0x130/0x1d0
     vfs_write+0x30b/0x4b0
     ksys_write+0x69/0xf0
     do_syscall_64+0xcc/0x1e0
     entry_SYSCALL_64_after_hwframe+0x6f/0x77
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/08aca65997fb6f233066883b1f1e653bcb1f26ca; https://git.kernel.org/stable/c/c5068e442eed063d2f1658e6b6d3c1c6fcf1e588; https://git.kernel.org/stable/c/ea937f77208323d35ffe2f8d8fc81b00118bfcda
CVE: CVE-2024-26589
Published: 2024-02-22
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS

For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off
for validation. However, variable offset ptr alu is not prohibited
for this ptr kind. So the variable offset is not checked.

The following prog is accepted:

  func#0 @0
  0: R1=ctx() R10=fp0
  0: (bf) r6 = r1                       ; R1=ctx() R6_w=ctx()
  1: (79) r7 = *(u64 *)(r6 +144)        ; R6_w=ctx() R7_w=flow_keys()
  2: (b7) r8 = 1024                     ; R8_w=1024
  3: (37) r8 /= 1                       ; R8_w=scalar()
  4: (57) r8 &= 1024                    ; R8_w=scalar(smin=smin32=0,
  smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400))
  5: (0f) r7 += r8
  mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1
  mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024
  mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1
  mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024
  6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off
  =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024,
  var_off=(0x0; 0x400))
  6: (79) r0 = *(u64 *)(r7 +0)          ; R0_w=scalar()
  7: (95) exit

This prog loads flow_keys to r7, and adds the variable offset r8
to r7, and finally causes out-of-bounds access:

  BUG: unable to handle page fault for address: ffffc90014c80038
  [...]
  Call Trace:
   <TASK>
   bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline]
   __bpf_prog_run include/linux/filter.h:651 [inline]
   bpf_prog_run include/linux/filter.h:658 [inline]
   bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline]
   bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991
   bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359
   bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline]
   __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
   __do_sys_bpf kernel/bpf/syscall.c:5561 [inline]
   __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
   __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559
   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
   do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83
   entry_SYSCALL_64_after_hwframe+0x63/0x6b

Fix this by rejecting ptr alu with variable offset on flow_keys.
Applying the patch rejects the program with "R7 pointer arithmetic
on flow_keys prohibited".
CVSS Score: 7.8 (HIGH)
CWE: CWE-119
References: https://git.kernel.org/stable/c/1b500d5d6cecf98dd6ca88bc9e7ae1783c83e6d3; https://git.kernel.org/stable/c/22c7fa171a02d310e3a3f6ed46a698ca8a0060ed; https://git.kernel.org/stable/c/29ffa63f21bcdcef3e36b03cccf9d0cd031f6ab0
CVE: CVE-2024-26590
Published: 2024-02-22
Description: In the Linux kernel, the following vulnerability has been resolved:

erofs: fix inconsistent per-file compression format

EROFS can select compression algorithms on a per-file basis, and each
per-file compression algorithm needs to be marked in the on-disk
superblock for initialization.

However, syzkaller can generate inconsistent crafted images that use
an unsupported algorithmtype for specific inodes, e.g. use MicroLZMA
algorithmtype even it's not set in `sbi->available_compr_algs`.  This
can lead to an unexpected "BUG: kernel NULL pointer dereference" if
the corresponding decompressor isn't built-in.

Fix this by checking against `sbi->available_compr_algs` for each
m_algorithmformat request.  Incorrect !erofs_sb_has_compr_cfgs preset
bitmap is now fixed together since it was harmless previously.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/118a8cf504d7dfa519562d000f423ee3ca75d2c4; https://git.kernel.org/stable/c/47467e04816cb297905c0f09bc2d11ef865942d9; https://git.kernel.org/stable/c/823ba1d2106019ddf195287ba53057aee33cf724
CVE: CVE-2024-26591
Published: 2024-02-22
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix re-attachment branch in bpf_tracing_prog_attach

The following case can cause a crash due to missing attach_btf:

1) load rawtp program
2) load fentry program with rawtp as target_fd
3) create tracing link for fentry program with target_fd = 0
4) repeat 3

In the end we have:

- prog->aux->dst_trampoline == NULL
- tgt_prog == NULL (because we did not provide target_fd to link_create)
- prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X)
- the program was loaded for tgt_prog but we have no way to find out which one

    BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
    Call Trace:
     <TASK>
     ? __die+0x20/0x70
     ? page_fault_oops+0x15b/0x430
     ? fixup_exception+0x22/0x330
     ? exc_page_fault+0x6f/0x170
     ? asm_exc_page_fault+0x22/0x30
     ? bpf_tracing_prog_attach+0x279/0x560
     ? btf_obj_id+0x5/0x10
     bpf_tracing_prog_attach+0x439/0x560
     __sys_bpf+0x1cf4/0x2de0
     __x64_sys_bpf+0x1c/0x30
     do_syscall_64+0x41/0xf0
     entry_SYSCALL_64_after_hwframe+0x6e/0x76

Return -EINVAL in this situation.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/50ae82f080cf87e84828f066c31723b781d68f5b; https://git.kernel.org/stable/c/6cc9c0af0aa06f781fa515a1734b1a4239dfd2c0; https://git.kernel.org/stable/c/715d82ba636cb3629a6e18a33bb9dbe53f9936ee
CVE: CVE-2024-26592
Published: 2024-02-22
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix UAF issue in ksmbd_tcp_new_connection()

The race is between the handling of a new TCP connection and
its disconnection. It leads to UAF on `struct tcp_transport` in
ksmbd_tcp_new_connection() function.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/24290ba94cd0136e417283b0dbf8fcdabcf62111; https://git.kernel.org/stable/c/380965e48e9c32ee4263c023e1d830ea7e462ed1; https://git.kernel.org/stable/c/38d20c62903d669693a1869aa68c4dd5674e2544
CVE: CVE-2024-24817
Published: 2024-02-22
Description: 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.
CVSS Score: 4.3 (MEDIUM)
CWE: CWE-200
References: https://github.com/discourse/discourse-calendar/commit/84ef46a38cf02748ecacad16c5d9c6fec12dc8da; https://github.com/discourse/discourse-calendar/security/advisories/GHSA-wwq5-g5cp-c69f; https://github.com/discourse/discourse-calendar/commit/84ef46a38cf02748ecacad16c5d9c6fec12dc8da
CVE: CVE-2024-25802
Published: 2024-02-22
Description: 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.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-434, CWE-434
References: https://shrouded-trowel-50c.notion.site/S-Museum-Version-7-02-3-Unrestricted-File-Upload-b73d4590b[PII_REDACTED]64ddcc175b8f7?pvs=4; https://shrouded-trowel-50c.notion.site/S-Museum-Version-7-02-3-Unrestricted-File-Upload-b73d4590b[PII_REDACTED]64ddcc175b8f7?pvs=4
CVE: CVE-2024-22547
Published: 2024-02-22
Description: WayOS IBR-7150 <17.06.23 is vulnerable to Cross Site Scripting (XSS).
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-79
References: https://github.com/WarmBrew/web_vul/blob/main/wayos/wayos.md; https://github.com/WarmBrew/web_vul/blob/main/wayos/wayos.md
CVE: CVE-2024-25129
Published: 2024-02-22
Description: 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.
CVSS Score: 2.7 (LOW)
CWE: CWE-611, CWE-611
References: https://github.com/github/codeql-cli-binaries/releases/tag/v2.16.3; https://github.com/github/codeql-cli-binaries/security/advisories/GHSA-gf8p-v3g3-3wph; https://github.com/github/codeql/blob/main/java/ql/src/Security/CWE/CWE-611/XXELocal.ql