vdanen/rhvex-cve huggingface dataset:
CVE-2024-45004 (Moderate severity, published 2024-09-03)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
CWE: CWE-522
Description: In the Linux kernel, the following vulnerability has been resolved:

KEYS: trusted: dcp: fix leak of blob encryption key

Trusted keys unseal the key blob on load, but keep the sealed payload in
the blob field so that every subsequent read (export) will simply
convert this field to hex and send it to userspace.

With DCP-based trusted keys, we decrypt the blob encryption key (BEK)
in the Kernel due hardware limitations and then decrypt the blob payload.
BEK decryption is done in-place which means that the trusted key blob
field is modified and it consequently holds the BEK in plain text.
Every subsequent read of that key thus send the plain text BEK instead
of the encrypted BEK to userspace.

This issue only occurs when importing a trusted DCP-based key and
then exporting it again. This should rarely happen as the common use cases
are to either create a new trusted key and export it, or import a key
blob and then just use it without exporting it again.

Fix this by performing BEK decryption and encryption in a dedicated
buffer. Further always wipe the plain text BEK buffer to prevent leaking
the key via uninitialized memory.
CVE-2024-49924 (Moderate severity, published 2024-10-20)
CVSS score: 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
CWE: CWE-416
Description: In the Linux kernel, the following vulnerability has been resolved:

fbdev: pxafb: Fix possible use after free in pxafb_task()

In the pxafb_probe function, it calls the pxafb_init_fbinfo function,
after which &fbi->task is associated with pxafb_task. Moreover,
within this pxafb_init_fbinfo function, the pxafb_blank function
within the &pxafb_ops struct is capable of scheduling work.

If we remove the module which will call pxafb_remove to make cleanup,
it will call unregister_framebuffer function which can call
do_unregister_framebuffer to free fbi->fb through
put_fb_info(fb_info), while the work mentioned above will be used.
The sequence of operations that may lead to a UAF bug is as follows:

CPU0                                                CPU1

                                   | pxafb_task
pxafb_remove                       |
unregister_framebuffer(info)       |
do_unregister_framebuffer(fb_info) |
put_fb_info(fb_info)               |
// free fbi->fb                    | set_ctrlr_state(fbi, state)
                                   | __pxafb_lcd_power(fbi, 0)
                                   | fbi->lcd_power(on, &fbi->fb.var)
                                   | //use fbi->fb

Fix it by ensuring that the work is canceled before proceeding
with the cleanup in pxafb_remove.

Note that only root user can remove the driver at runtime.
CVE-2024-56782 (Low severity, published 2025-01-07)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-476
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPI: x86: Add adev NULL check to acpi_quirk_skip_serdev_enumeration()

acpi_dev_hid_match() does not check for adev == NULL, dereferencing
it unconditional.

Add a check for adev being NULL before calling acpi_dev_hid_match().

At the moment acpi_quirk_skip_serdev_enumeration() is never called with
a controller_parent without an ACPI companion, but better safe than sorry.
CVE-2024-57890 (Moderate severity, published 2025-01-14)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-190
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/uverbs: Prevent integer overflow issue

In the expression "cmd.wqe_size * cmd.wr_count", both variables are u32
values that come from the user so the multiplication can lead to integer
wrapping.  Then we pass the result to uverbs_request_next_ptr() which also
could potentially wrap.  The "cmd.sge_count * sizeof(struct ib_uverbs_sge)"
multiplication can also overflow on 32bit systems although it's fine on
64bit systems.

This patch does two things.  First, I've re-arranged the condition in
uverbs_request_next_ptr() so that the use controlled variable "len" is on
one side of the comparison by itself without any math.  Then I've modified
all the callers to use size_mul() for the multiplications.
CVE-2024-53580 (Important severity, published 2024-12-17)
CVSS score: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-476
Description: A flaw was found in iperf. This vulnerability allows a Denial of Service (DoS) via the injection of malformed JSON data, which can result in a segmentation fault when a NULL pointer is passed to strdup().
Statement: This vulnerability marked as important severity rather than moderate due to its potential to cause a complete denial of service (DoS) by exploiting a segmentation fault through malformed JSON data. The flaw stems from improper input validation, which allows attackers to crash the server by sending invalid data that triggers memory mismanagement. Since iperf is widely used in performance testing of network systems, a DoS attack could disrupt critical operations in production environments, leading to service outages or performance degradation in large-scale networks.
Mitigation: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
CVE-2024-49861 (Low severity, published 2024-10-20)
CVSS score: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-99
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix helper writes to read-only maps

Lonial found an issue that despite user- and BPF-side frozen BPF map
(like in case of .rodata), it was still possible to write into it from
a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT}
as arguments.

In check_func_arg() when the argument is as mentioned, the meta->raw_mode
is never set. Later, check_helper_mem_access(), under the case of
PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the
subsequent call to check_map_access_type() and given the BPF map is
read-only it succeeds.

The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT
when results are written into them as opposed to read out of them. The
latter indicates that it's okay to pass a pointer to uninitialized memory
as the memory is written to anyway.

However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM
just with additional alignment requirement. So it is better to just get
rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the
fixed size memory types. For this, add MEM_ALIGNED to additionally ensure
alignment given these helpers write directly into the args via *<ptr> = val.
The .arg*_size has been initialized reflecting the actual sizeof(*<ptr>).

MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated
argument types, since in !MEM_FIXED_SIZE cases the verifier does not know
the buffer size a priori and therefore cannot blindly write *<ptr> = val.
Statement: The default Red Hat Enterprise Linux kernel prevents unprivileged users from being able to use eBPF by the kernel.unprivileged_bpf_disabled sysctl. This would require a privileged user with CAP_SYS_ADMIN or root to be able to abuse this flaw reducing its attack space.

For the Red Hat Enterprise Linux 9 to confirm the current state, inspect the sysctl with the command:

    cat /proc/sys/kernel/unprivileged_bpf_disabled

The setting of 1 would mean that unprivileged users can not use eBPF, mitigating the flaw.
CVE-2024-36896 (Low severity, published 2024-05-29)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-170
Description: In the Linux kernel, the following vulnerability has been resolved:

USB: core: Fix access violation during port device removal

Testing with KASAN and syzkaller revealed a bug in port.c:disable_store():
usb_hub_to_struct_hub() can return NULL if the hub that the port belongs to
is concurrently removed, but the function does not check for this
possibility before dereferencing the returned value.

It turns out that the first dereference is unnecessary, since hub->intfdev
is the parent of the port device, so it can be changed easily.  Adding a
check for hub == NULL prevents further problems.

The same bug exists in the disable_show() routine, and it can be fixed the
same way.
CVE-2024-21200 (Moderate severity, published 2024-10-15)
CVSS score: 4.9 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Description: Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.35 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
CVE-2024-26896 (Low severity, published 2024-04-16)
CVSS score: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-401
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: wfx: fix memory leak when starting AP

Kmemleak reported this error:

    unreferenced object 0xd73d1180 (size 184):
      comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00  ................
      backtrace:
        [<5ca11420>] kmem_cache_alloc+0x20c/0x5ac
        [<127bdd74>] __alloc_skb+0x144/0x170
        [<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
        [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
        [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
        [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
        [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
        [<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
        [<47bd8b68>] genl_rcv_msg+0x198/0x378
        [<453ef796>] netlink_rcv_skb+0xd0/0x130
        [<6b7c977a>] genl_rcv+0x34/0x44
        [<66b2d04d>] netlink_unicast+0x1b4/0x258
        [<f965b9b6>] netlink_sendmsg+0x1e8/0x428
        [<aadb8231>] ____sys_sendmsg+0x1e0/0x274
        [<d2b5212d>] ___sys_sendmsg+0x80/0xb4
        [<69954f45>] __sys_sendmsg+0x64/0xa8
    unreferenced object 0xce087000 (size 1024):
      comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
      backtrace:
        [<9a993714>] __kmalloc_track_caller+0x230/0x600
        [<f83ea192>] kmalloc_reserve.constprop.0+0x30/0x74
        [<a2c61343>] __alloc_skb+0xa0/0x170
        [<fb8a5e38>] __netdev_alloc_skb+0x50/0x180
        [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
        [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
        [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx]
        [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211]
        [<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
        [<47bd8b68>] genl_rcv_msg+0x198/0x378
        [<453ef796>] netlink_rcv_skb+0xd0/0x130
        [<6b7c977a>] genl_rcv+0x34/0x44
        [<66b2d04d>] netlink_unicast+0x1b4/0x258
        [<f965b9b6>] netlink_sendmsg+0x1e8/0x428
        [<aadb8231>] ____sys_sendmsg+0x1e0/0x274
        [<d2b5212d>] ___sys_sendmsg+0x80/0xb4

However, since the kernel is build optimized, it seems the stack is not
accurate. It appears the issue is related to wfx_set_mfp_ap(). The issue
is obvious in this function: memory allocated by ieee80211_beacon_get()
is never released. Fixing this leak makes kmemleak happy.
CVE-2024-27439 (Important severity, published 2024-03-18)
CVSS score: 8.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)
CWE: CWE-444
Description: A flaw was found in Apache Wicket. Under certain circumstances, this flaw allows an attacker to bypass Cross-Site Request Forgery (CSRF) protections.
CVE-2024-50154 (Moderate severity, published 2024-11-06)
CVSS score: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
CWE: CWE-416
Description: A use-after-free (UAF) vulnerability was found and fixed in the Linux kernel's TCP subsystem related to request socket (reqsk) timers during handshake handling. This issue stems from a race condition caused by relying on `timer_pending()` in `reqsk_queue_unlink()`. This could result in the timer continuing to run after the socket (`req->sk`) is freed, allowing BPF programs to access invalid memory.
Statement: This vulnerability is classified as moderate severity rather than important because the issue primarily affects a narrow set of conditions, notably when BPF programs are involved in tracing TCP retransmissions. In most scenarios, the reqsk timer is pinned and the race condition is unlikely to be triggered. Additionally, the problem only occurs if the request socket (`req->sk`) is closed while the timer is still pending, which is an uncommon sequence of events. While the potential for a use-after-free (UAF) exists, it requires specific timing and conditions to exploit, limiting its overall risk and impact on typical systems.
Mitigation: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
CVE-2024-27069 (Moderate severity, published 2024-04-30)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

ovl: relax WARN_ON in ovl_verify_area()

syzbot hit an assertion in copy up data loop which looks like it is
the result of a lower file whose size is being changed underneath
overlayfs.

This type of use case is documented to cause undefined behavior, so
returning EIO error for the copy up makes sense, but it should not be
causing a WARN_ON assertion.
CVE-2024-40857 (Moderate severity, published 2024-09-24)
CVSS score: 7.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L)
CWE: CWE-79
Description: A flaw was found in WebKit. Processing maliciously crafted web content may lead to universal cross-site scripting.
Mitigation: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
CVE-2024-35957 (Moderate severity, published 2024-05-19)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: CVE-2024-35957 is a vulnerability in the Linux kernel's Intel Virtualization Technology for Directed I/O (VT-d) subsystem. The issue stems from an incorrect assumption that each device has a unique source ID, leading to potential conflicts and system warnings during the IOMMU probe process. This flaw has been addressed by modifying the tracking mechanism to include only devices with PCI Address Translation Services (ATS) capabilities, thereby preventing unnecessary warnings and ensuring system stability. Users are advised to update their Linux kernel to a version that includes this fix to maintain optimal system performance.
CVE-2024-46829 (Moderate severity, published 2024-09-26)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-667
Description: In the Linux kernel, the following vulnerability has been resolved:

rtmutex: Drop rt_mutex::wait_lock before scheduling

rt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held.  In the
good case it returns with the lock held and in the deadlock case it emits a
warning and goes into an endless scheduling loop with the lock held, which
triggers the 'scheduling in atomic' warning.

Unlock rt_mutex::wait_lock in the dead lock case before issuing the warning
and dropping into the schedule for ever loop.

[ tglx: Moved unlock before the WARN(), removed the pointless comment,
  	massaged changelog, added Fixes tag ]
CVE-2024-26678 (Low severity, published 2024-04-01)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-20
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section

The .compat section is a dummy PE section that contains the address of
the 32-bit entrypoint of the 64-bit kernel image if it is bootable from
32-bit firmware (i.e., CONFIG_EFI_MIXED=y)

This section is only 8 bytes in size and is only referenced from the
loader, and so it is placed at the end of the memory view of the image,
to avoid the need for padding it to 4k, which is required for sections
appearing in the middle of the image.

Unfortunately, this violates the PE/COFF spec, and even if most EFI
loaders will work correctly (including the Tianocore reference
implementation), PE loaders do exist that reject such images, on the
basis that both the file and memory views of the file contents should be
described by the section headers in a monotonically increasing manner
without leaving any gaps.

So reorganize the sections to avoid this issue. This results in a slight
padding overhead (< 4k) which can be avoided if desired by disabling
CONFIG_EFI_MIXED (which is only needed in rare cases these days)
CVE-2024-47691 (Moderate severity, published 2024-10-20)
CVSS score: 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
CWE: CWE-416
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()

syzbot reports a f2fs bug as below:

 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
 print_report+0xe8/0x550 mm/kasan/report.c:491
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
 instrument_atomic_read_write include/linux/instrumented.h:96 [inline]
 atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]
 __refcount_add include/linux/refcount.h:184 [inline]
 __refcount_inc include/linux/refcount.h:241 [inline]
 refcount_inc include/linux/refcount.h:258 [inline]
 get_task_struct include/linux/sched/task.h:118 [inline]
 kthread_stop+0xca/0x630 kernel/kthread.c:704
 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210
 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283
 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]
 __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:907 [inline]
 __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The root cause is below race condition, it may cause use-after-free
issue in sbi->gc_th pointer.

- remount
 - f2fs_remount
  - f2fs_stop_gc_thread
   - kfree(gc_th)
				- f2fs_ioc_shutdown
				 - f2fs_do_shutdown
				  - f2fs_stop_gc_thread
				   - kthread_stop(gc_th->f2fs_gc_task)
   : sbi->gc_thread = NULL;

We will call f2fs_do_shutdown() in two paths:
- for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore
for fixing.
- for f2fs_shutdown() path, it's safe since caller has already grabbed
sb->s_umount semaphore.
CVE-2024-26697 (Moderate severity, published 2024-04-02)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-99
Description: A flaw was found in the Linux kernel, which affects the NILFS2 file system. This issue involves data corruption during dsync block recovery operations when using small block sizes, possibly leading to unexpected data loss or corruption.
Statement: Red Hat Enterprise Linux is not vulnerable to this CVE, as it does not affect the versions or configurations of the Linux kernel used in its distributions.
Mitigation: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
CVE-2024-56595 (Moderate severity, published 2024-12-26)
CVSS score: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
CWE: CWE-129
Description: In the Linux kernel, the following vulnerability has been resolved:

jfs: add a check to prevent array-index-out-of-bounds in dbAdjTree

When the value of lp is 0 at the beginning of the for loop, it will
become negative in the next assignment and we should bail out.
CVE-2024-44951 (Moderate severity, published 2024-09-03)
CVSS score: 5.1 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:L)
CWE: CWE-667
Description: In the Linux kernel, the following vulnerability has been resolved:

serial: sc16is7xx: fix TX fifo corruption

Sometimes, when a packet is received on channel A at almost the same time
as a packet is about to be transmitted on channel B, we observe with a
logic analyzer that the received packet on channel A is transmitted on
channel B. In other words, the Tx buffer data on channel B is corrupted
with data from channel A.

The problem appeared since commit 4409df5866b7 ("serial: sc16is7xx: change
EFR lock to operate on each channels"), which changed the EFR locking to
operate on each channel instead of chip-wise.

This commit has introduced a regression, because the EFR lock is used not
only to protect the EFR registers access, but also, in a very obscure and
undocumented way, to protect access to the data buffer, which is shared by
the Tx and Rx handlers, but also by each channel of the IC.

Fix this regression first by switching to kfifo_out_linear_ptr() in
sc16is7xx_handle_tx() to eliminate the need for a shared Rx/Tx buffer.

Secondly, replace the chip-wise Rx buffer with a separate Rx buffer for
each channel.
CVE-2024-5971 (Important severity, published 2024-07-08)
CVSS score: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-674
Description: A vulnerability was found in Undertow, where the chunked response hangs after the body was flushed. The response headers and body were sent but the client would continue waiting as Undertow does not send the expected 0\r\n termination of the chunked response. This results in uncontrolled resource consumption, leaving the server side to a denial of service attack. This happens only with Java 17 TLSv1.3 scenarios.
Statement: The identified vulnerability in Undertow, where chunked responses fail to terminate properly under Java 17 with TLSv1.3, represents a significant security concern due to its potential for uncontrolled resource consumption and denial of service (DoS) attacks. This issue arises from Undertow's mishandling of chunked response termination after initial data flushing, leading to clients waiting indefinitely for completion signals that are not sent. Such behavior could be exploited by malicious actors to exhaust server resources, resulting in service degradation or unavailability.
Mitigation: Mitigation for this issue is either not available or the currently available options don't meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
CVE-2024-12798 (Moderate severity, published 2024-12-19)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:H/A:L)
CWE: CWE-917
Description: A flaw was found in Logback. This flaw allows a privileged attacker with write access to modify Logback configuration files or inject a malicious environment variable to execute arbitrary code via the JaninoEventEvaluator extension.