CyberAlerts is shutting down on June 30th, 2025. Thank you for your support!
Threat and Vulnerability Intelligence Database
Example Searches:
CVE
Threat Actors
Countries
Vendors
Severity
Known Exploited
CVE-2024-42224 |
Description: In the Linux kernel, the following vulnerability has been resolved:
net: dsa: mv88e6xxx: Correct check for empty list
Since commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO
busses") mv88e6xxx_default_mdio_bus() has checked that the
return value of list_first_entry() is non-NULL.
This appears to be intended to guard against the list chip->mdios being
empty. However, it is not the correct check as the implementation of
list_first_entry is not designed to return NULL for empty lists.
Instead, use list_first_entry_or_null() which does return NULL if the
list is empty.
Flagged by Smatch.
Compile tested only.
CVSS: MEDIUM (6.1) EPSS Score: 0.07% SSVC Exploitation: none
May 4th, 2025 (about 2 months ago)
|
|
CVE-2024-42223 |
Description: In the Linux kernel, the following vulnerability has been resolved:
media: dvb-frontends: tda10048: Fix integer overflow
state->xtal_hz can be up to 16M, so it can overflow a 32 bit integer
when multiplied by pll_mfactor.
Create a new 64 bit variable to hold the calculations.
CVSS: MEDIUM (5.5) EPSS Score: 0.06% SSVC Exploitation: none
May 4th, 2025 (about 2 months ago)
|
|
CVE-2024-42152 |
Description: In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix a possible leak when destroy a ctrl during qp establishment
In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we
know that a ctrl was allocated (in the admin connect request handler)
and we need to release pending AERs, clear ctrl->sqs and sq->ctrl
(for nvme-loop primarily), and drop the final reference on the ctrl.
However, a small window is possible where nvmet_sq_destroy starts (as
a result of the client giving up and disconnecting) concurrently with
the nvme admin connect cmd (which may be in an early stage). But *before*
kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq
live reference). In this case, sq->ctrl was allocated however after it was
captured in a local variable in nvmet_sq_destroy.
This prevented the final reference drop on the ctrl.
Solve this by re-capturing the sq->ctrl after all inflight request has
completed, where for sure sq->ctrl reference is final, and move forward
based on that.
This issue was observed in an environment with many hosts connecting
multiple ctrls simoutanuosly, creating a delay in allocating a ctrl
leading up to this race window.
CVSS: MEDIUM (4.7) EPSS Score: 0.07% SSVC Exploitation: none
May 4th, 2025 (about 2 months ago)
|
|
CVE-2024-42150 |
Description: In the Linux kernel, the following vulnerability has been resolved:
net: txgbe: remove separate irq request for MSI and INTx
When using MSI or INTx interrupts, request_irq() for pdev->irq will
conflict with request_threaded_irq() for txgbe->misc.irq, to cause
system crash. So remove txgbe_request_irq() for MSI/INTx case, and
rename txgbe_request_msix_irqs() since it only request for queue irqs.
Add wx->misc_irq_domain to determine whether the driver creates an IRQ
domain and threaded request the IRQs.
CVSS: MEDIUM (5.5) EPSS Score: 0.05% SSVC Exploitation: none
May 4th, 2025 (about 2 months ago)
|
|
CVE-2024-42145 |
Description: In the Linux kernel, the following vulnerability has been resolved:
IB/core: Implement a limit on UMAD receive List
The existing behavior of ib_umad, which maintains received MAD
packets in an unbounded list, poses a risk of uncontrolled growth.
As user-space applications extract packets from this list, the rate
of extraction may not match the rate of incoming packets, leading
to potential list overflow.
To address this, we introduce a limit to the size of the list. After
considering typical scenarios, such as OpenSM processing, which can
handle approximately 100k packets per second, and the 1-second retry
timeout for most packets, we set the list size limit to 200k. Packets
received beyond this limit are dropped, assuming they are likely timed
out by the time they are handled by user-space.
Notably, packets queued on the receive list due to reasons like
timed-out sends are preserved even when the list is full.
CVSS: MEDIUM (5.5) EPSS Score: 0.06% SSVC Exploitation: none
May 4th, 2025 (about 2 months ago)
|
|
CVE-2024-42139 |
Description: In the Linux kernel, the following vulnerability has been resolved:
ice: Fix improper extts handling
Extts events are disabled and enabled by the application ts2phc.
However, in case where the driver is removed when the application is
running, a specific extts event remains enabled and can cause a kernel
crash.
As a side effect, when the driver is reloaded and application is started
again, remaining extts event for the channel from a previous run will
keep firing and the message "extts on unexpected channel" might be
printed to the user.
To avoid that, extts events shall be disabled when PTP is released.
CVSS: MEDIUM (5.5) EPSS Score: 0.05% SSVC Exploitation: none
May 4th, 2025 (about 2 months ago)
|
|
CVE-2024-42123 |
Description: In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix double free err_addr pointer warnings
In amdgpu_umc_bad_page_polling_timeout, the amdgpu_umc_handle_bad_pages
will be run many times so that double free err_addr in some special case.
So set the err_addr to NULL to avoid the warnings.
CVSS: MEDIUM (4.4) EPSS Score: 0.04% SSVC Exploitation: none
May 4th, 2025 (about 2 months ago)
|
|
CVE-2024-42114 |
Description: In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values
syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM
to 2^31.
We had a similar issue in sch_fq, fixed with commit
d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]
Modules linked in:
irq event stamp: 131135
hardirqs last enabled at (131134): [] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]
hardirqs last enabled at (131134): [] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95
hardirqs last disabled at (131135): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
hardirqs last disabled at (131135): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
softirqs last enabled at (125892): [] neigh_hh_init net/core/neighbour.c:1538 [inline]
softirqs last enabled at (125892): [] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553
softirqs last disabled at (125896): [] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19
CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Workqueue: mld mld_ifc_work
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __list_del include/linux/list.h:195 [inline]
pc : __list_del_entry include/linux/list.h:21...
CVSS: MEDIUM (4.4) EPSS Score: 0.05% SSVC Exploitation: none
May 4th, 2025 (about 2 months ago)
|
|
CVE-2024-42107 |
Description: In the Linux kernel, the following vulnerability has been resolved:
ice: Don't process extts if PTP is disabled
The ice_ptp_extts_event() function can race with ice_ptp_release() and
result in a NULL pointer dereference which leads to a kernel panic.
Panic occurs because the ice_ptp_extts_event() function calls
ptp_clock_event() with a NULL pointer. The ice driver has already
released the PTP clock by the time the interrupt for the next external
timestamp event occurs.
To fix this, modify the ice_ptp_extts_event() function to check the
PTP state and bail early if PTP is not ready.
CVSS: MEDIUM (4.7) EPSS Score: 0.03% SSVC Exploitation: none
May 4th, 2025 (about 2 months ago)
|
|
CVE-2024-42102 |
Description: In the Linux kernel, the following vulnerability has been resolved:
Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again"
Patch series "mm: Avoid possible overflows in dirty throttling".
Dirty throttling logic assumes dirty limits in page units fit into
32-bits. This patch series makes sure this is true (see patch 2/2 for
more details).
This patch (of 2):
This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.
The commit is broken in several ways. Firstly, the removed (u64) cast
from the multiplication will introduce a multiplication overflow on 32-bit
archs if wb_thresh * bg_thresh >= 1<<32 (which is actually common - the
default settings with 4GB of RAM will trigger this). Secondly, the
div64_u64() is unnecessarily expensive on 32-bit archs. We have
div64_ul() in case we want to be safe & cheap. Thirdly, if dirty
thresholds are larger than 1<<32 pages, then dirty balancing is going to
blow up in many other spectacular ways anyway so trying to fix one
possible overflow is just moot.
CVSS: MEDIUM (4.7) EPSS Score: 0.08% SSVC Exploitation: none
May 4th, 2025 (about 2 months ago)
|