harinpurumandla/cve-severity-dataset huggingface dataset:
CVE-2024-56747 (2024)
In the Linux kernel, the following vulnerability has been resolved:

scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()

Hook "qedi_ops->common->sb_init = qed_sb_init" does not release the DMA
memory sb_virt when it fails. Add dma_free_coherent() to free it. This
is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56748 (2024)
In the Linux kernel, the following vulnerability has been resolved:

scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()

Hook "qed_ops->common->sb_init = qed_sb_init" does not release the DMA
memory sb_virt when it fails. Add dma_free_coherent() to free it. This
is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56749 (2024)
In the Linux kernel, the following vulnerability has been resolved:

dlm: fix dlm_recover_members refcount on error

If dlm_recover_members() fails we don't drop the references of the
previous created root_list that holds and keep all rsbs alive during the
recovery. It might be not an unlikely event because ping_members() could
run into an -EINTR if another recovery progress was triggered again.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-5675 (2024)
Untrusted data deserialization vulnerability has been found in Mentor - Employee Portal, affecting version 3.83.35. This vulnerability could allow an attacker to execute arbitrary code, by injecting a malicious payload into the “ViewState” field.
CVSS v3.1 vector: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CVE-2024-56750 (2024)
In the Linux kernel, the following vulnerability has been resolved:

erofs: fix blksize < PAGE_SIZE for file-backed mounts

Adjust sb->s_blocksize{,_bits} directly for file-backed
mounts when the fs block size is smaller than PAGE_SIZE.

Previously, EROFS used sb_set_blocksize(), which caused
a panic if bdev-backed mounts is not used.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56751 (2024)
In the Linux kernel, the following vulnerability has been resolved:

ipv6: release nexthop on device removal

The CI is hitting some aperiodic hangup at device removal time in the
pmtu.sh self-test:

unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6
ref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at
	dst_init+0x84/0x4a0
	dst_alloc+0x97/0x150
	ip6_dst_alloc+0x23/0x90
	ip6_rt_pcpu_alloc+0x1e6/0x520
	ip6_pol_route+0x56f/0x840
	fib6_rule_lookup+0x334/0x630
	ip6_route_output_flags+0x259/0x480
	ip6_dst_lookup_tail.constprop.0+0x5c2/0x940
	ip6_dst_lookup_flow+0x88/0x190
	udp_tunnel6_dst_lookup+0x2a7/0x4c0
	vxlan_xmit_one+0xbde/0x4a50 [vxlan]
	vxlan_xmit+0x9ad/0xf20 [vxlan]
	dev_hard_start_xmit+0x10e/0x360
	__dev_queue_xmit+0xf95/0x18c0
	arp_solicit+0x4a2/0xe00
	neigh_probe+0xaa/0xf0

While the first suspect is the dst_cache, explicitly tracking the dst
owing the last device reference via probes proved such dst is held by
the nexthop in the originating fib6_info.

Similar to commit f5b51fe804ec ("ipv6: route: purge exception on
removal"), we need to explicitly release the originating fib info when
disconnecting a to-be-removed device from a live ipv6 dst: move the
fib6_info cleanup into ip6_dst_ifdown().

Tested running:

./pmtu.sh cleanup_ipv6_exception

in a tight loop for more than 400 iterations with no spat, running an
unpatched kernel  I observed a splat every ~10 iterations.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56752 (2024)
In the Linux kernel, the following vulnerability has been resolved:

drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new()

When the call to gf100_grctx_generate() fails, unlock gr->fecs.mutex
before returning the error.

Fixes smatch warning:

drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:480 gf100_gr_chan_new() warn: inconsistent returns '&gr->fecs.mutex'.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56753 (2024)
In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu/gfx9: Add Cleaner Shader Deinitialization in gfx_v9_0 Module

This commit addresses an omission in the previous patch related to the
cleaner shader support for GFX9 hardware. Specifically, it adds the
necessary deinitialization code for the cleaner shader in the
gfx_v9_0_sw_fini function.

The added line amdgpu_gfx_cleaner_shader_sw_fini(adev); ensures that any
allocated resources for the cleaner shader are freed correctly, avoiding
potential memory leaks and ensuring that the GPU state is clean for the
next initialization sequence.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56754 (2024)
In the Linux kernel, the following vulnerability has been resolved:

crypto: caam - Fix the pointer passed to caam_qi_shutdown()

The type of the last parameter given to devm_add_action_or_reset() is
"struct caam_drv_private *", but in caam_qi_shutdown(), it is casted to
"struct device *".

Pass the correct parameter to devm_add_action_or_reset() so that the
resources are released as expected.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56755 (2024)
In the Linux kernel, the following vulnerability has been resolved:

netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING

In fscache_create_volume(), there is a missing memory barrier between the
bit-clearing operation and the wake-up operation. This may cause a
situation where, after a wake-up, the bit-clearing operation hasn't been
detected yet, leading to an indefinite wait. The triggering process is as
follows:

  [cookie1]                [cookie2]                  [volume_work]
fscache_perform_lookup
  fscache_create_volume
                        fscache_perform_lookup
                          fscache_create_volume
			                        fscache_create_volume_work
                                                  cachefiles_acquire_volume
                                                  clear_and_wake_up_bit
    test_and_set_bit
                            test_and_set_bit
                              goto maybe_wait
      goto no_wait

In the above process, cookie1 and cookie2 has the same volume. When cookie1
enters the -no_wait- process, it will clear the bit and wake up the waiting
process. If a barrier is missing, it may cause cookie2 to remain in the
-wait- process indefinitely.

In commit 3288666c7256 ("fscache: Use clear_and_wake_up_bit() in
fscache_create_volume_work()"), barriers were added to similar operations
in fscache_create_volume_work(), but fscache_create_volume() was missed.

By combining the clear and wake operations into clear_and_wake_up_bit() to
fix this issue.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56756 (2024)
In the Linux kernel, the following vulnerability has been resolved:

nvme-pci: fix freeing of the HMB descriptor table

The HMB descriptor table is sized to the maximum number of descriptors
that could be used for a given device, but __nvme_alloc_host_mem could
break out of the loop earlier on memory allocation failure and end up
using less descriptors than planned for, which leads to an incorrect
size passed to dma_free_coherent.

In practice this was not showing up because the number of descriptors
tends to be low and the dma coherent allocator always allocates and
frees at least a page.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56757 (2024)
In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btusb: mediatek: add intf release flow when usb disconnect

MediaTek claim an special usb intr interface for ISO data transmission.
The interface need to be released before unregistering hci device when
usb disconnect. Removing BT usb dongle without properly releasing the
interface may cause Kernel panic while unregister hci device.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56758 (2024)
In the Linux kernel, the following vulnerability has been resolved:

btrfs: check folio mapping after unlock in relocate_one_folio()

When we call btrfs_read_folio() to bring a folio uptodate, we unlock the
folio. The result of that is that a different thread can modify the
mapping (like remove it with invalidate) before we call folio_lock().
This results in an invalid page and we need to try again.

In particular, if we are relocating concurrently with aborting a
transaction, this can result in a crash like the following:

  BUG: kernel NULL pointer dereference, address: 0000000000000000
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP
  CPU: 76 PID: 1411631 Comm: kworker/u322:5
  Workqueue: events_unbound btrfs_reclaim_bgs_work
  RIP: 0010:set_page_extent_mapped+0x20/0xb0
  RSP: 0018:ffffc900516a7be8 EFLAGS: 00010246
  RAX: ffffea009e851d08 RBX: ffffea009e0b1880 RCX: 0000000000000000
  RDX: 0000000000000000 RSI: ffffc900516a7b90 RDI: ffffea009e0b1880
  RBP: 0000000003573000 R08: 0000000000000001 R09: ffff88c07fd2f3f0
  R10: 0000000000000000 R11: 0000194754b575be R12: 0000000003572000
  R13: 0000000003572fff R14: 0000000000100cca R15: 0000000005582fff
  FS:  0000000000000000(0000) GS:ffff88c07fd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000000 CR3: 000000407d00f002 CR4: 00000000007706f0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  PKRU: 55555554
  Call Trace:
  <TASK>
  ? __die+0x78/0xc0
  ? page_fault_oops+0x2a8/0x3a0
  ? __switch_to+0x133/0x530
  ? wq_worker_running+0xa/0x40
  ? exc_page_fault+0x63/0x130
  ? asm_exc_page_fault+0x22/0x30
  ? set_page_extent_mapped+0x20/0xb0
  relocate_file_extent_cluster+0x1a7/0x940
  relocate_data_extent+0xaf/0x120
  relocate_block_group+0x20f/0x480
  btrfs_relocate_block_group+0x152/0x320
  btrfs_relocate_chunk+0x3d/0x120
  btrfs_reclaim_bgs_work+0x2ae/0x4e0
  process_scheduled_works+0x184/0x370
  worker_thread+0xc6/0x3e0
  ? blk_add_timer+0xb0/0xb0
  kthread+0xae/0xe0
  ? flush_tlb_kernel_range+0x90/0x90
  ret_from_fork+0x2f/0x40
  ? flush_tlb_kernel_range+0x90/0x90
  ret_from_fork_asm+0x11/0x20
  </TASK>

This occurs because cleanup_one_transaction() calls
destroy_delalloc_inodes() which calls invalidate_inode_pages2() which
takes the folio_lock before setting mapping to NULL. We fail to check
this, and subsequently call set_extent_mapping(), which assumes that
mapping != NULL (in fact it asserts that in debug mode)

Note that the "fixes" patch here is not the one that introduced the
race (the very first iteration of this code from 2009) but a more recent
change that made this particular crash happen in practice.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56759 (2024)
In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix use-after-free when COWing tree bock and tracing is enabled

When a COWing a tree block, at btrfs_cow_block(), and we have the
tracepoint trace_btrfs_cow_block() enabled and preemption is also enabled
(CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extent
buffer while inside the tracepoint code. This is because in some paths
that call btrfs_cow_block(), such as btrfs_search_slot(), we are holding
the last reference on the extent buffer @buf so btrfs_force_cow_block()
drops the last reference on the @buf extent buffer when it calls
free_extent_buffer_stale(buf), which schedules the release of the extent
buffer with RCU. This means that if we are on a kernel with preemption,
the current task may be preempted before calling trace_btrfs_cow_block()
and the extent buffer already released by the time trace_btrfs_cow_block()
is called, resulting in a use-after-free.

Fix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() to
btrfs_force_cow_block() before the COWed extent buffer is freed.
This also has a side effect of invoking the tracepoint in the tree defrag
code, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() is
called there, but this is fine and it was actually missing there.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2024-5676 (2024)
The Paradox IP150 Internet Module in version 1.40.00 is vulnerable to Cross-Site Request Forgery (CSRF) attacks due to a lack of countermeasures and the use of the HTTP method `GET` to introduce changes in the system.
CVSS v3.1 vector: AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:H
CVE-2024-56760 (2024)
In the Linux kernel, the following vulnerability has been resolved:

PCI/MSI: Handle lack of irqdomain gracefully

Alexandre observed a warning emitted from pci_msi_setup_msi_irqs() on a
RISCV platform which does not provide PCI/MSI support:

 WARNING: CPU: 1 PID: 1 at drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x2c/0x32
 __pci_enable_msix_range+0x30c/0x596
 pci_msi_setup_msi_irqs+0x2c/0x32
 pci_alloc_irq_vectors_affinity+0xb8/0xe2

RISCV uses hierarchical interrupt domains and correctly does not implement
the legacy fallback. The warning triggers from the legacy fallback stub.

That warning is bogus as the PCI/MSI layer knows whether a PCI/MSI parent
domain is associated with the device or not. There is a check for MSI-X,
which has a legacy assumption. But that legacy fallback assumption is only
valid when legacy support is enabled, but otherwise the check should simply
return -ENOTSUPP.

Loongarch tripped over the same problem and blindly enabled legacy support
without implementing the legacy fallbacks. There are weak implementations
which return an error, so the problem was papered over.

Correct pci_msi_domain_supports() to evaluate the legacy mode and add
the missing supported check into the MSI enable path to complete it.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56761 (2024)
In the Linux kernel, the following vulnerability has been resolved:

x86/fred: Clear WFE in missing-ENDBRANCH #CPs

An indirect branch instruction sets the CPU indirect branch tracker
(IBT) into WAIT_FOR_ENDBRANCH (WFE) state and WFE stays asserted
across the instruction boundary.  When the decoder finds an
inappropriate instruction while WFE is set ENDBR, the CPU raises a #CP
fault.

For the "kernel IBT no ENDBR" selftest where #CPs are deliberately
triggered, the WFE state of the interrupted context needs to be
cleared to let execution continue.  Otherwise when the CPU resumes
from the instruction that just caused the previous #CP, another
missing-ENDBRANCH #CP is raised and the CPU enters a dead loop.

This is not a problem with IDT because it doesn't preserve WFE and
IRET doesn't set WFE.  But FRED provides space on the entry stack
(in an expanded CS area) to save and restore the WFE state, thus the
WFE state is no longer clobbered, so software must clear it.

Clear WFE to avoid dead looping in ibt_clear_fred_wfe() and the
!ibt_fatal code path when execution is allowed to continue.

Clobbering WFE in any other circumstance is a security-relevant bug.

[ dhansen: changelog rewording ]
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56763 (2024)
In the Linux kernel, the following vulnerability has been resolved:

tracing: Prevent bad count for tracing_cpumask_write

If a large count is provided, it will trigger a warning in bitmap_parse_user.
Also check zero for it.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56764 (2024)
In the Linux kernel, the following vulnerability has been resolved:

ublk: detach gendisk from ublk device if add_disk() fails

Inside ublk_abort_requests(), gendisk is grabbed for aborting all
inflight requests. And ublk_abort_requests() is called when exiting
the uring context or handling timeout.

If add_disk() fails, the gendisk may have been freed when calling
ublk_abort_requests(), so use-after-free can be caused when getting
disk's reference in ublk_abort_requests().

Fixes the bug by detaching gendisk from ublk device if add_disk() fails.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2024-56766 (2024)
In the Linux kernel, the following vulnerability has been resolved:

mtd: rawnand: fix double free in atmel_pmecc_create_user()

The "user" pointer was converted from being allocated with kzalloc() to
being allocated by devm_kzalloc().  Calling kfree(user) will lead to a
double free.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2024-56767 (2024)
In the Linux kernel, the following vulnerability has been resolved:

dmaengine: at_xdmac: avoid null_prt_deref in at_xdmac_prep_dma_memset

The at_xdmac_memset_create_desc may return NULL, which will lead to a
null pointer dereference. For example, the len input is error, or the
atchan->free_descs_list is empty and memory is exhausted. Therefore, add
check to avoid this.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56768 (2024)
In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix bpf_get_smp_processor_id() on !CONFIG_SMP

On x86-64 calling bpf_get_smp_processor_id() in a kernel with CONFIG_SMP
disabled can trigger the following bug, as pcpu_hot is unavailable:

 [    8.471774] BUG: unable to handle page fault for address: 00000000936a290c
 [    8.471849] #PF: supervisor read access in kernel mode
 [    8.471881] #PF: error_code(0x0000) - not-present page

Fix by inlining a return 0 in the !CONFIG_SMP case.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-5677 (2024)
The Featured Image Generator plugin for WordPress is vulnerable to unauthorized image upload due to a missing capability check on the fig_save_after_generate_image function in all versions up to, and including, 1.3.1. This makes it possible for authenticated attackers, with Subscriber-level access and above, to upload arbitrary images to a post-related gallery.
CVSS v3.1 vector: AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
CVE-2024-56770 (2024)
In the Linux kernel, the following vulnerability has been resolved:

net/sched: netem: account for backlog updates from child qdisc

In general, 'qlen' of any classful qdisc should keep track of the
number of packets that the qdisc itself and all of its children holds.
In case of netem, 'qlen' only accounts for the packets in its internal
tfifo. When netem is used with a child qdisc, the child qdisc can use
'qdisc_tree_reduce_backlog' to inform its parent, netem, about created
or dropped SKBs. This function updates 'qlen' and the backlog statistics
of netem, but netem does not account for changes made by a child qdisc.
'qlen' then indicates the wrong number of packets in the tfifo.
If a child qdisc creates new SKBs during enqueue and informs its parent
about this, netem's 'qlen' value is increased. When netem dequeues the
newly created SKBs from the child, the 'qlen' in netem is not updated.
If 'qlen' reaches the configured sch->limit, the enqueue function stops
working, even though the tfifo is not full.

Reproduce the bug:
Ensure that the sender machine has GSO enabled. Configure netem as root
qdisc and tbf as its child on the outgoing interface of the machine
as follows:
$ tc qdisc add dev <oif> root handle 1: netem delay 100ms limit 100
$ tc qdisc add dev <oif> parent 1:0 tbf rate 50Mbit burst 1542 latency 50ms

Send bulk TCP traffic out via this interface, e.g., by running an iPerf3
client on the machine. Check the qdisc statistics:
$ tc -s qdisc show dev <oif>

Statistics after 10s of iPerf3 TCP test before the fix (note that
netem's backlog > limit, netem stopped accepting packets):
qdisc netem 1: root refcnt 2 limit 1000 delay 100ms
 Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0)
 backlog 4294528236b 1155p requeues 0
qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms
 Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0)
 backlog 0b 0p requeues 0

Statistics after the fix:
qdisc netem 1: root refcnt 2 limit 1000 delay 100ms
 Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms
 Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0)
 backlog 0b 0p requeues 0

tbf segments the GSO SKBs (tbf_segment) and updates the netem's 'qlen'.
The interface fully stops transferring packets and "locks". In this case,
the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is at
its limit and no more packets are accepted.

This patch adds a counter for the entries in the tfifo. Netem's 'qlen' is
only decreased when a packet is returned by its dequeue function, and not
during enqueuing into the child qdisc. External updates to 'qlen' are thus
accounted for and only the behavior of the backlog statistics changes. As
in other qdiscs, 'qlen' then keeps track of  how many packets are held in
netem and all of its children. As before, sch->limit remains as the
maximum number of packets in the tfifo. The same applies to netem's
backlog statistics.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56771 (2024)
In the Linux kernel, the following vulnerability has been resolved:

mtd: spinand: winbond: Fix 512GW, 01GW, 01JW and 02JW ECC information

These four chips:
* W25N512GW
* W25N01GW
* W25N01JW
* W25N02JW
all require a single bit of ECC strength and thus feature an on-die
Hamming-like ECC engine. There is no point in filling a ->get_status()
callback for them because the main ECC status bytes are located in
standard places, and retrieving the number of bitflips in case of
corrected chunk is both useless and unsupported (if there are bitflips,
then there is 1 at most, so no need to query the chip for that).

Without this change, a kernel warning triggers every time a bit flips.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56772 (2024)
In the Linux kernel, the following vulnerability has been resolved:

kunit: string-stream: Fix a UAF bug in kunit_init_suite()

In kunit_debugfs_create_suite(), if alloc_string_stream() fails in the
kunit_suite_for_each_test_case() loop, the "suite->log = stream"
has assigned before, and the error path only free the suite->log's stream
memory but not set it to NULL, so the later string_stream_clear() of
suite->log in kunit_init_suite() will cause below UAF bug.

Set stream pointer to NULL after free to fix it.

	Unable to handle kernel paging request at virtual address 006440150000030d
	Mem abort info:
	  ESR = 0x0000000096000004
	  EC = 0x25: DABT (current EL), IL = 32 bits
	  SET = 0, FnV = 0
	  EA = 0, S1PTW = 0
	  FSC = 0x04: level 0 translation fault
	Data abort info:
	  ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
	  CM = 0, WnR = 0, TnD = 0, TagAccess = 0
	  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
	[006440150000030d] address between user and kernel address ranges
	Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
	Dumping ftrace buffer:
	   (ftrace buffer empty)
	Modules linked in: iio_test_gts industrialio_gts_helper cfg80211 rfkill ipv6 [last unloaded: iio_test_gts]
	CPU: 5 UID: 0 PID: 6253 Comm: modprobe Tainted: G    B   W        N 6.12.0-rc4+ #458
	Tainted: [B]=BAD_PAGE, [W]=WARN, [N]=TEST
	Hardware name: linux,dummy-virt (DT)
	pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
	pc : string_stream_clear+0x54/0x1ac
	lr : string_stream_clear+0x1a8/0x1ac
	sp : ffffffc080b47410
	x29: ffffffc080b47410 x28: 006440550000030d x27: ffffff80c96b5e98
	x26: ffffff80c96b5e80 x25: ffffffe461b3f6c0 x24: 0000000000000003
	x23: ffffff80c96b5e88 x22: 1ffffff019cdf4fc x21: dfffffc000000000
	x20: ffffff80ce6fa7e0 x19: 032202a80000186d x18: 0000000000001840
	x17: 0000000000000000 x16: 0000000000000000 x15: ffffffe45c355cb4
	x14: ffffffe45c35589c x13: ffffffe45c03da78 x12: ffffffb810168e75
	x11: 1ffffff810168e74 x10: ffffffb810168e74 x9 : dfffffc000000000
	x8 : 0000000000000004 x7 : 0000000000000003 x6 : 0000000000000001
	x5 : ffffffc080b473a0 x4 : 0000000000000000 x3 : 0000000000000000
	x2 : 0000000000000001 x1 : ffffffe462fbf620 x0 : dfffffc000000000
	Call trace:
	 string_stream_clear+0x54/0x1ac
	 __kunit_test_suites_init+0x108/0x1d8
	 kunit_exec_run_tests+0xb8/0x100
	 kunit_module_notify+0x400/0x55c
	 notifier_call_chain+0xfc/0x3b4
	 blocking_notifier_call_chain+0x68/0x9c
	 do_init_module+0x24c/0x5c8
	 load_module+0x4acc/0x4e90
	 init_module_from_file+0xd4/0x128
	 idempotent_init_module+0x2d4/0x57c
	 __arm64_sys_finit_module+0xac/0x100
	 invoke_syscall+0x6c/0x258
	 el0_svc_common.constprop.0+0x160/0x22c
	 do_el0_svc+0x44/0x5c
	 el0_svc+0x48/0xb8
	 el0t_64_sync_handler+0x13c/0x158
	 el0t_64_sync+0x190/0x194
	Code: f9400753 d2dff800 f2fbffe0 d343fe7c (38e06b80)
	---[ end trace 0000000000000000 ]---
	Kernel panic - not syncing: Oops: Fatal exception
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2024-56773 (2024)
In the Linux kernel, the following vulnerability has been resolved:

kunit: Fix potential null dereference in kunit_device_driver_test()

kunit_kzalloc() may return a NULL pointer, dereferencing it without
NULL check may lead to NULL dereference.
Add a NULL check for test_state.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56774 (2024)
In the Linux kernel, the following vulnerability has been resolved:

btrfs: add a sanity check for btrfs root in btrfs_search_slot()

Syzbot reports a null-ptr-deref in btrfs_search_slot().

The reproducer is using rescue=ibadroots, and the extent tree root is
corrupted thus the extent tree is NULL.

When scrub tries to search the extent tree to gather the needed extent
info, btrfs_search_slot() doesn't check if the target root is NULL or
not, resulting the null-ptr-deref.

Add sanity check for btrfs root before using it in btrfs_search_slot().
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56775 (2024)
In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix handling of plane refcount

[Why]
The mechanism to backup and restore plane states doesn't maintain
refcount, which can cause issues if the refcount of the plane changes
in between backup and restore operations, such as memory leaks if the
refcount was supposed to go down, or double frees / invalid memory
accesses if the refcount was supposed to go up.

[How]
Cache and re-apply current refcount when restoring plane states.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2024-56776 (2024)
In the Linux kernel, the following vulnerability has been resolved:

drm/sti: avoid potential dereference of error pointers

The return value of drm_atomic_get_crtc_state() needs to be
checked. To avoid use of error pointer 'crtc_state' in case
of the failure.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56777 (2024)
In the Linux kernel, the following vulnerability has been resolved:

drm/sti: avoid potential dereference of error pointers in sti_gdp_atomic_check

The return value of drm_atomic_get_crtc_state() needs to be
checked. To avoid use of error pointer 'crtc_state' in case
of the failure.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56778 (2024)
In the Linux kernel, the following vulnerability has been resolved:

drm/sti: avoid potential dereference of error pointers in sti_hqvdp_atomic_check

The return value of drm_atomic_get_crtc_state() needs to be
checked. To avoid use of error pointer 'crtc_state' in case
of the failure.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-5678 (2024)
Zohocorp ManageEngine Applications Manager versions 170900 and below are vulnerable to the authenticated admin-only SQL Injection in the Create Monitor feature.
CVSS v3.1 vector: AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L
CVE-2024-56780 (2024)
In the Linux kernel, the following vulnerability has been resolved:

quota: flush quota_release_work upon quota writeback

One of the paths quota writeback is called from is:

freeze_super()
  sync_filesystem()
    ext4_sync_fs()
      dquot_writeback_dquots()

Since we currently don't always flush the quota_release_work queue in
this path, we can end up with the following race:

 1. dquot are added to releasing_dquots list during regular operations.
 2. FS Freeze starts, however, this does not flush the quota_release_work queue.
 3. Freeze completes.
 4. Kernel eventually tries to flush the workqueue while FS is frozen which
    hits a WARN_ON since transaction gets started during frozen state:

  ext4_journal_check_start+0x28/0x110 [ext4] (unreliable)
  __ext4_journal_start_sb+0x64/0x1c0 [ext4]
  ext4_release_dquot+0x90/0x1d0 [ext4]
  quota_release_workfn+0x43c/0x4d0

Which is the following line:

  WARN_ON(sb->s_writers.frozen == SB_FREEZE_COMPLETE);

Which ultimately results in generic/390 failing due to dmesg
noise. This was detected on powerpc machine 15 cores.

To avoid this, make sure to flush the workqueue during
dquot_writeback_dquots() so we dont have any pending workitems after
freeze.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56782 (2024)
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.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56783 (2024)
In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_socket: remove WARN_ON_ONCE on maximum cgroup level

cgroup maximum depth is INT_MAX by default, there is a cgroup toggle to
restrict this maximum depth to a more reasonable value not to harm
performance. Remove unnecessary WARN_ON_ONCE which is reachable from
userspace.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56784 (2024)
In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Adding array index check to prevent memory corruption

[Why & How]
Array indices out of bound caused memory corruption. Adding checks to
ensure that array index stays in bound.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2024-56785 (2024)
In the Linux kernel, the following vulnerability has been resolved:

MIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a

Fix the dtc warnings:

    arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
    arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider
    arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider'

And a runtime warning introduced in commit 045b14ca5c36 ("of: WARN on
deprecated #address-cells/#size-cells handling"):

    WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0
    Missing '#address-cells' in /bus@10000000/pci@1a000000/pci_bridge@9,0

The fix is similar to commit d89a415ff8d5 ("MIPS: Loongson64: DTS: Fix PCIe
port nodes for ls7a"), which has fixed the issue for ls2k (despite its
subject mentions ls7a).
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56787 (2024)
In the Linux kernel, the following vulnerability has been resolved:

soc: imx8m: Probe the SoC driver as platform driver

With driver_async_probe=* on kernel command line, the following trace is
produced because on i.MX8M Plus hardware because the soc-imx8m.c driver
calls of_clk_get_by_name() which returns -EPROBE_DEFER because the clock
driver is not yet probed. This was not detected during regular testing
without driver_async_probe.

Convert the SoC code to platform driver and instantiate a platform device
in its current device_initcall() to probe the platform driver. Rework
.soc_revision callback to always return valid error code and return SoC
revision via parameter. This way, if anything in the .soc_revision callback
return -EPROBE_DEFER, it gets propagated to .probe and the .probe will get
retried later.

"
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1 at drivers/soc/imx/soc-imx8m.c:115 imx8mm_soc_revision+0xdc/0x180
CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-next-20240924-00002-g2062bb554dea #603
Hardware name: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3) (DT)
pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : imx8mm_soc_revision+0xdc/0x180
lr : imx8mm_soc_revision+0xd0/0x180
sp : ffff8000821fbcc0
x29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120
x26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311
x23: ffff8000817f42c8 x22: ffff0000df8be210 x21: fffffffffffffdfb
x20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffff
x17: ffff800081fff418 x16: ffff8000823e1000 x15: ffff0000c03b65e8
x14: ffff0000c00051b0 x13: ffff800082790000 x12: 0000000000000801
x11: ffff80008278ffff x10: ffff80008209d3a6 x9 : ffff80008062e95c
x8 : ffff8000821fb9a0 x7 : 0000000000000000 x6 : 00000000000080e3
x5 : ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfb
Call trace:
 imx8mm_soc_revision+0xdc/0x180
 imx8_soc_init+0xb0/0x1e0
 do_one_initcall+0x94/0x1a8
 kernel_init_freeable+0x240/0x2a8
 kernel_init+0x28/0x140
 ret_from_fork+0x10/0x20
---[ end trace 0000000000000000 ]---
SoC: i.MX8MP revision 1.1
"
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-56788 (2024)
In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: oa_tc6: fix tx skb race condition between reference pointers

There are two skb pointers to manage tx skb's enqueued from n/w stack.
waiting_tx_skb pointer points to the tx skb which needs to be processed
and ongoing_tx_skb pointer points to the tx skb which is being processed.

SPI thread prepares the tx data chunks from the tx skb pointed by the
ongoing_tx_skb pointer. When the tx skb pointed by the ongoing_tx_skb is
processed, the tx skb pointed by the waiting_tx_skb is assigned to
ongoing_tx_skb and the waiting_tx_skb pointer is assigned with NULL.
Whenever there is a new tx skb from n/w stack, it will be assigned to
waiting_tx_skb pointer if it is NULL. Enqueuing and processing of a tx skb
handled in two different threads.

Consider a scenario where the SPI thread processed an ongoing_tx_skb and
it moves next tx skb from waiting_tx_skb pointer to ongoing_tx_skb pointer
without doing any NULL check. At this time, if the waiting_tx_skb pointer
is NULL then ongoing_tx_skb pointer is also assigned with NULL. After
that, if a new tx skb is assigned to waiting_tx_skb pointer by the n/w
stack and there is a chance to overwrite the tx skb pointer with NULL in
the SPI thread. Finally one of the tx skb will be left as unhandled,
resulting packet missing and memory leak.

- Consider the below scenario where the TXC reported from the previous
transfer is 10 and ongoing_tx_skb holds an tx ethernet frame which can be
transported in 20 TXCs and waiting_tx_skb is still NULL.
	tx_credits = 10; /* 21 are filled in the previous transfer */
	ongoing_tx_skb = 20;
	waiting_tx_skb = NULL; /* Still NULL */
- So, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) becomes true.
- After oa_tc6_prepare_spi_tx_buf_for_tx_skbs()
	ongoing_tx_skb = 10;
	waiting_tx_skb = NULL; /* Still NULL */
- Perform SPI transfer.
- Process SPI rx buffer to get the TXC from footers.
- Now let's assume previously filled 21 TXCs are freed so we are good to
transport the next remaining 10 tx chunks from ongoing_tx_skb.
	tx_credits = 21;
	ongoing_tx_skb = 10;
	waiting_tx_skb = NULL;
- So, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) becomes true again.
- In the oa_tc6_prepare_spi_tx_buf_for_tx_skbs()
	ongoing_tx_skb = NULL;
	waiting_tx_skb = NULL;

- Now the below bad case might happen,

Thread1 (oa_tc6_start_xmit)	Thread2 (oa_tc6_spi_thread_handler)
---------------------------	-----------------------------------
- if waiting_tx_skb is NULL
				- if ongoing_tx_skb is NULL
				- ongoing_tx_skb = waiting_tx_skb
- waiting_tx_skb = skb
				- waiting_tx_skb = NULL
				...
				- ongoing_tx_skb = NULL
- if waiting_tx_skb is NULL
- waiting_tx_skb = skb

To overcome the above issue, protect the moving of tx skb reference from
waiting_tx_skb pointer to ongoing_tx_skb pointer and assigning new tx skb
to waiting_tx_skb pointer, so that the other thread can't access the
waiting_tx_skb pointer until the current thread completes moving the tx
skb reference safely.
CVSS v3.1 vector: AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2024-5679 (2024)
CWE-787: Out-of-Bounds Write vulnerability exists that could cause local denial-of-service, or
kernel memory leak when a malicious actor with local user access crafts a script/program using
an IOCTL call in the Foxboro.sys driver.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
CVE-2024-56799 (2024)
Simofa is a tool to help automate static website building and deployment. Prior to version 0.2.7, due to a design mistake in the RouteLoader class, some API routes may be publicly accessible when they should require authentication. This vulnerability has been patched in v0.2.7.
CVSS v3.1 vector: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
CVE-2024-5680 (2024)
CWE-129: Improper Validation of Array Index vulnerability exists that could cause local denial-of-service when a malicious actor with local user access crafts a script/program using an IOCTL
call in the Foxboro.sys driver.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
CVE-2024-56800 (2024)
Firecrawl is a web scraper that allows users to extract the content of a webpage for a large language model. Versions prior to 1.1.1 contain a server-side request forgery (SSRF) vulnerability. The scraping engine could be exploited by crafting a malicious site that redirects to a local IP address. This allowed exfiltration of local network resources through the API. The cloud service was patched on December 27th, 2024, and the maintainers have checked that no user data was exposed by this vulnerability. Scraping engines used in the open sourced version of Firecrawl were patched on December 29th, 2024, except for the playwright services which the maintainers have determined to be un-patchable. All users of open-source software (OSS) Firecrawl should upgrade to v1.1.1. As a workaround, OSS Firecrawl users should supply the playwright services with a secure proxy. A proxy can be specified through the `PROXY_SERVER` env in the environment variables. Please refer to the documentation for instructions. Ensure that the proxy server one is using is setup to block all traffic going to link-local IP addresses.
CVSS v3.1 vector: AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L
CVE-2024-56801 (2024)
Tasklists provides plugin tasklists for GLPI. Versions prior to 2.0.4 have a blind SQL injection vulnerability. Version 2.0.4 contains a patch for the vulnerability.
CVSS v3.1 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVE-2024-56804 (2024)
An SQL injection vulnerability has been reported to affect Video Station. If a remote attacker gains a user account, they can then exploit the vulnerability to execute unauthorized code or commands.

We have already fixed the vulnerability in the following version:
Video Station 5.8.4 and later
CVSS v3.1 vector: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2024-56805 (2024)
A buffer overflow vulnerability has been reported to affect several QNAP operating system versions. If exploited, the vulnerability could allow remote attackers who have gained user access to modify memory or crash processes.

We have already fixed the vulnerability in the following versions:
QTS 5.2.4.3079 build 20250321 and later
QuTS hero h5.2.4.3079 build 20250321 and later
CVSS v3.1 vector: AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
CVE-2024-56807 (2024)
An out-of-bounds read vulnerability has been reported to affect Media Streaming add-on. If an attacker gains local network access, they can then exploit the vulnerability to obtain secret data.

We have already fixed the vulnerability in the following version:
Media Streaming add-on 500.1.1.6 ( 2024/08/02 ) and later
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
CVE-2024-56808 (2024)
A command injection vulnerability has been reported to affect Media Streaming add-on. If an attacker gains local network access who have also gained a user account, they can then exploit the vulnerability to execute arbitrary commands.

We have already fixed the vulnerability in the following version:
Media Streaming add-on 500.1.1.6 ( 2024/08/02 ) and later
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2024-5681 (2024)
CWE-20: Improper Input Validation vulnerability exists that could cause local denial-of-service,
privilege escalation, and potentially kernel execution when a malicious actor with local user
access crafts a script/program using an IOCTL call in the Foxboro.sys driver.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2024-56810 (2024)
IBM EntireX 11.1 could allow a local user to obtain sensitive information when a detailed technical error message is returned.  This information could be used in further attacks against the system.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
CVE-2024-56811 (2024)
IBM EntireX 11.1 could allow a local user to obtain sensitive information when a detailed technical error message is returned.  This information could be used in further attacks against the system.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
CVE-2024-56812 (2024)
IBM EntireX 11.1 could allow a local user to obtain sensitive information when a detailed technical error message is returned.  This information could be used in further attacks against the system.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
CVE-2024-5682 (2024)
Improper Restriction of Excessive Authentication Attempts vulnerability in Yordam Information Technology Yordam Library Automation System allows Interface Manipulation.

This issue affects Yordam Library Automation System: before 20.1.
CVSS v3.1 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L
CVE-2024-56826 (2024)
A flaw was found in the OpenJPEG project. A heap buffer overflow condition may be triggered when certain options are specified while using the opj_decompress utility.  This can lead to an application crash or other undefined behavior.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:H
CVE-2024-56827 (2024)
A flaw was found in the OpenJPEG project. A heap buffer overflow condition may be triggered when certain options are specified while using the opj_decompress utility.  This can lead to an application crash or other undefined behavior.
CVSS v3.1 vector: AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:H
CVE-2024-56828 (2024)
File Upload vulnerability in ChestnutCMS through 1.5.0. Based on the code analysis, it was determined that the /api/member/avatar API endpoint receives a base64 string as input. This string is then passed to the memberService.uploadAvatarByBase64 method for processing. Within the service, the base64-encoded image is parsed. For example, given a string like: data:image/html;base64,PGh0bWw+PGltZyBzcmM9eCBvbmVycm9yPWFsZXJ0KDEpPjwvaHRtbD4= the content after the comma is extracted and decoded using Base64.getDecoder().decode(). The substring from the 11th character up to the first occurrence of a semicolon (;) is assigned to the suffix variable (representing the file extension). The decoded content is then written to a file. However, the file extension is not validated, and since this functionality is exposed to the frontend, it poses significant security risks.
CVSS v3.1 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVE-2024-56829 (2024)
Huang Yaoshi Pharmaceutical Management Software through 16.0 allows arbitrary file upload via a .asp filename in the fileName element of the UploadFile element in a SOAP request to /XSDService.asmx.
CVSS v3.1 vector: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CVE-2024-5683 (2024)
Improper Control of Generation of Code ('Code Injection') vulnerability in Next4Biz CRM & BPM Software Business Process Manangement (BPM) allows Remote Code Inclusion.

This issue affects Business Process Manangement (BPM): from 6.6.4.4 before 6.6.4.5.
CVSS v3.1 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVE-2024-56830 (2024)
The Net::EasyTCP package 0.15 through 0.26 for Perl uses Perl's builtin rand() if no strong randomization module is present.
CVSS v3.1 vector: AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N
CVE-2024-56835 (2024)
A vulnerability has been identified in RUGGEDCOM ROX MX5000 (All versions < V2.17.0), RUGGEDCOM ROX MX5000RE (All versions < V2.17.0), RUGGEDCOM ROX RX1400 (All versions < V2.17.0), RUGGEDCOM ROX RX1500 (All versions < V2.17.0), RUGGEDCOM ROX RX1501 (All versions < V2.17.0), RUGGEDCOM ROX RX1510 (All versions < V2.17.0), RUGGEDCOM ROX RX1511 (All versions < V2.17.0), RUGGEDCOM ROX RX1512 (All versions < V2.17.0), RUGGEDCOM ROX RX1524 (All versions < V2.17.0), RUGGEDCOM ROX RX1536 (All versions < V2.17.0), RUGGEDCOM ROX RX5000 (All versions < V2.17.0). The DHCP Server configuration file of the affected products is subject to code injection. An attacker could leverage this vulnerability to spawn a reverse shell and gain root access on the affected system.
CVSS v3.1 vector: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2024-56836 (2024)
A vulnerability has been identified in RUGGEDCOM ROX MX5000 (All versions < V2.17.0), RUGGEDCOM ROX MX5000RE (All versions < V2.17.0), RUGGEDCOM ROX RX1400 (All versions < V2.17.0), RUGGEDCOM ROX RX1500 (All versions < V2.17.0), RUGGEDCOM ROX RX1501 (All versions < V2.17.0), RUGGEDCOM ROX RX1510 (All versions < V2.17.0), RUGGEDCOM ROX RX1511 (All versions < V2.17.0), RUGGEDCOM ROX RX1512 (All versions < V2.17.0), RUGGEDCOM ROX RX1524 (All versions < V2.17.0), RUGGEDCOM ROX RX1536 (All versions < V2.17.0), RUGGEDCOM ROX RX5000 (All versions < V2.17.0). During the Dynamic DNS configuration of the affected product it is possible to inject additional configuration parameters. Under certain circumstances, an attacker could leverage this vulnerability to spawn a reverse shell and gain root access on the affected system.
CVSS v3.1 vector: AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2024-56837 (2024)
A vulnerability has been identified in RUGGEDCOM ROX MX5000 (All versions < V2.17.0), RUGGEDCOM ROX MX5000RE (All versions < V2.17.0), RUGGEDCOM ROX RX1400 (All versions < V2.17.0), RUGGEDCOM ROX RX1500 (All versions < V2.17.0), RUGGEDCOM ROX RX1501 (All versions < V2.17.0), RUGGEDCOM ROX RX1510 (All versions < V2.17.0), RUGGEDCOM ROX RX1511 (All versions < V2.17.0), RUGGEDCOM ROX RX1512 (All versions < V2.17.0), RUGGEDCOM ROX RX1524 (All versions < V2.17.0), RUGGEDCOM ROX RX1536 (All versions < V2.17.0), RUGGEDCOM ROX RX5000 (All versions < V2.17.0). Due to the insufficient validation during the installation and load of certain configuration files of the affected device, an attacker could spawn a reverse shell and gain root access on the affected system.
CVSS v3.1 vector: AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
CVE-2024-56838 (2024)
A vulnerability has been identified in RUGGEDCOM ROX MX5000 (All versions < V2.17.0), RUGGEDCOM ROX MX5000RE (All versions < V2.17.0), RUGGEDCOM ROX RX1400 (All versions < V2.17.0), RUGGEDCOM ROX RX1500 (All versions < V2.17.0), RUGGEDCOM ROX RX1501 (All versions < V2.17.0), RUGGEDCOM ROX RX1510 (All versions < V2.17.0), RUGGEDCOM ROX RX1511 (All versions < V2.17.0), RUGGEDCOM ROX RX1512 (All versions < V2.17.0), RUGGEDCOM ROX RX1524 (All versions < V2.17.0), RUGGEDCOM ROX RX1536 (All versions < V2.17.0), RUGGEDCOM ROX RX5000 (All versions < V2.17.0). The SCEP client available in the affected device for secure certificate enrollment lacks validation of multiple fields. An attacker could leverage this scenario to execute arbitrary code as root user.
CVSS v3.1 vector: AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
CVE-2024-56839 (2024)
A vulnerability has been identified in RUGGEDCOM ROX MX5000 (All versions < V2.17.0), RUGGEDCOM ROX MX5000RE (All versions < V2.17.0), RUGGEDCOM ROX RX1400 (All versions < V2.17.0), RUGGEDCOM ROX RX1500 (All versions < V2.17.0), RUGGEDCOM ROX RX1501 (All versions < V2.17.0), RUGGEDCOM ROX RX1510 (All versions < V2.17.0), RUGGEDCOM ROX RX1511 (All versions < V2.17.0), RUGGEDCOM ROX RX1512 (All versions < V2.17.0), RUGGEDCOM ROX RX1524 (All versions < V2.17.0), RUGGEDCOM ROX RX1536 (All versions < V2.17.0), RUGGEDCOM ROX RX5000 (All versions < V2.17.0). Code injection can be achieved when the affected device is using VRF (Virtual Routing and Forwarding). An attacker could leverage this scenario to execute arbitrary code as root user.
CVSS v3.1 vector: AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H