Nicht bewertetEPSS 0,17%Keine Korrektur veröffentlicht
net/mlx5e: Move representor vnic reporter to eswitch devlink port
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Move representor vnic reporter to eswitch devlink port
The representor vnic devlink health reporter is created and destroyed
along the representor netdev (un)load path, which is not serialized by
the devlink instance lock. Destroying the reporter from there triggers
a devl_assert_locked() splat on driver unbind:
WARNING: net/devlink/core.c:259 at devl_assert_locked+0x54/0x70, CPU#2: bash/3758
Modules linked in: mlx5_vdpa vringh vdpa mlx5_ib mlx5_fwctl mlx5_core ...
CPU: 2 UID: 0 PID: 3758 Comm: bash Tainted: G W 6.19.0+ #1 PREEMPT
Tainted
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel: Prevent drain_pebs() reentry
The PEBS buffer is shared by all events on a CPU, so drain_pebs() must
not be reentered. If so, one instance may observe stale buffer state and
potentially access out-of-bound memory.
Most invocations happen in NMI context, which naturally prevents reentry.
However, drain_pebs() is also reachable from process context via
intel_pmu_drain_pebs_buffer().
In those paths, the PMU is often already disabled, but not guaranteed.
For example, __intel_pmu_pebs_disable() only disables the target counter,
so other active counters can still
In the Linux kernel, the following vulnerability has been resolved:
idpf: disable DIM work before freeing q_vectors
idpf never drains the Tx/Rx DIM works before freeing the memory they
live in. tx_dim and rx_dim are embedded in struct idpf_q_vector, they
are queued from the NAPI poll via net_dim(), and idpf_vport_intr_rel()
ends with kfree(rsrc->q_vectors). Nothing in the driver cancels them.
idpf_tx_dim_work() and idpf_rx_dim_work() then run on freed memory:
idpf_vport_intr_write_itr() writes the ITR register through
q_vector->intr_reg.tx_itr / rx_itr, void __iomem pointers loaded out of
the freed q_vector. No configuration is needed t
Nicht bewertetEPSS 0,2%Keine Korrektur veröffentlicht
ieee802154: cc2520: fix FIFOP work use-after-free
In the Linux kernel, the following vulnerability has been resolved:
ieee802154: cc2520: fix FIFOP work use-after-free
The FIFOP interrupt handler queues cc2520_fifop_irqwork. On removal,
cc2520_remove() only flushes the work. The devm-managed FIFOP IRQ
remains active until after ->remove() returns and can queue the work
again after that flush, allowing it to run after the private data is
released.
Disable the work with disable_work_sync() instead of flushing it, so
the handler can no longer queue it once removal begins. Destroy the
buffer mutex last, since the worker and the stop callback invoked
through ieee802154_unregister_hw() both
smb: client: reject short READ responses in CIFSSMBRead()
In the Linux kernel, the following vulnerability has been resolved:
smb: client: reject short READ responses in CIFSSMBRead()
CIFSSMBRead() reads DataLengthHigh, DataLength and DataOffset out of
the READ_RSP returned by the server without first checking that a
whole READ_RSP was actually received. The length of the response is
recorded in rsp_iov.iov_len, but nothing constrains it to be at least
read_rsp_size before those fields are dereferenced.
A malicious or compromised SMB1 server can return a response shorter
than the READ_RSP header, so that parsing the header itself reads past
the end of the receive buffer. SMB1 is not negotiated by
smb: client: reject out-of-bounds DataOffset in CIFSSMBRead()
In the Linux kernel, the following vulnerability has been resolved:
smb: client: reject out-of-bounds DataOffset in CIFSSMBRead()
The SMB1 synchronous read helper CIFSSMBRead() validates the server's
DataLength against CIFSMaxBufSize and the caller's count, but never
validates DataOffset. The copy source is formed as
&pSMBr->hdr.Protocol + le16_to_cpu(pSMBr->DataOffset)
and memcpy()'d for DataLength bytes with no check that the
[DataOffset, DataOffset + DataLength) range lies within the response
actually received from the server.
A malicious or compromised SMB1 server can return a response carrying
an in-range DataLength and a large Dat
smb: client: honor forceuid/forcegid when mapping SIDs to uid/gid
In the Linux kernel, the following vulnerability has been resolved:
smb: client: honor forceuid/forcegid when mapping SIDs to uid/gid
When the administrator mounts with forceuid or forcegid (uid=/gid=
mount options), they expect all files to appear owned by the specified
user/group. However, several code paths unconditionally called
sid_to_id() to overwrite cf_uid/cf_gid with server-provided values,
ignoring the administrator's explicit override:
- smb311_posix_info_to_fattr() (stat via POSIX extensions)
- cifs_posix_to_fattr() (readdir via POSIX extensions)
- parse_sec_desc() (CIFS ACL ownership mapping)
This allowed an untrusted
smb: client: avoid using uninitialized SIDs in cifs_posix_to_fattr()
In the Linux kernel, the following vulnerability has been resolved:
smb: client: avoid using uninitialized SIDs in cifs_posix_to_fattr()
cifs_posix_to_fattr() ignores the return value of posix_info_parse().
When a malformed POSIX directory entry is encountered (e.g. invalid
SID lengths from an untrusted server), posix_info_parse() returns -1
without populating the 'parsed' struct. The uninitialized stack
memory in parsed.owner and parsed.group is then passed to
sid_to_id(), which processes the garbage bytes and passes them to
request_key() to construct a SID string, potentially leaking kernel
stack contents to the userspace idmap daemon.
Nicht bewertetEPSS 0,15%Keine Korrektur veröffentlicht
gfs2: fix quota init duplicate scan
In the Linux kernel, the following vulnerability has been resolved:
gfs2: fix quota init duplicate scan
gfs2_quota_init() checks for duplicate quota_change IDs while holding
qd_lock and the quota hash bucket bitlock. That path used
gfs2_qd_search_bucket(), which takes a lockref reference via
lockref_get_not_dead().
On PREEMPT_RT this may sleep, which is not allowed under the bucket
bitlock, triggering "sleeping function called from invalid context".
Use a no-ref bucket lookup in this path, then continue duplicate
handling without taking a lockref there.
Refactor gfs2_qd_search_bucket() to build on top of the no-ref helper
so lookup trave
Nicht bewertetEPSS 0,14%Keine Korrektur veröffentlicht
drm/xe: Fix null pointer dereference in devcoredump cleanup
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Fix null pointer dereference in devcoredump cleanup
In xe_devcoredump_snapshot_free(), ss->gt may be NULL when the snapshot
was never fully populated (e.g., when cleanup is triggered without a
prior capture). Guard the xe_guc_capture_put_matched_nodes() call with
IS_ERR_OR_NULL() to prevent a null dereference.
In xe_devcoredump_free(), the deferred work is only queued when a
coredump is captured, so guard cancel_work_sync() with a check on
coredump->captured.
i3c: master: svc: Prevent IRQ storm from false SLVSTART on NPCM845
In the Linux kernel, the following vulnerability has been resolved:
i3c: master: svc: Prevent IRQ storm from false SLVSTART on NPCM845
On NPCM845, when a target on the I3C bus gets stuck holding SDA low,
the controller reports a false Master Request (MR) in-band interrupt
event. The driver handles this by emitting a STOP condition to restore
the bus.
However, the hardware quirk SVC_I3C_QUIRK_FALSE_SLVSTART indicates that
emitting a STOP condition may spuriously set the SLVSTART interrupt
status bit. In the Master Request case, this creates a feedback loop:
the STOP triggers a new SLVSTART event, the IRQ handler fires again,
the controller
media: chips-media: wave5: Release m2m_ctx after Instance Removed from List
In the Linux kernel, the following vulnerability has been resolved:
media: chips-media: wave5: Release m2m_ctx after Instance Removed from List
Possible use after free if IRQ thread manages to obtain spinlock between
m2m_ctx release and wave5_release function removing stream instance from
list of active instances. The IRQ thread looks for the m2m_ctx which is
freed so null pointer dereference occurs.
wifi: mac80211: avoid out-of-bounds access in monitor
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: avoid out-of-bounds access in monitor
In NAN, we don't know on what band the frame will be sent. Therefore we
set info->band to NUM_NL80211_BANDS. However, this leads to out-of-bound
access in ieee80211_add_tx_radiotap_header when we try to access the
sbands array.
Fix it by not accessing the array if the band is NUM_NL80211_BANDS.
This means that we will not report rate info for legacy rate in NAN.
But nobody really cares about it.
Nicht bewertetEPSS 0,15%Keine Korrektur veröffentlicht
watchdog: lenovo_se10_wdt: Fix use-after-free and resource leak risk
In the Linux kernel, the following vulnerability has been resolved:
watchdog: lenovo_se10_wdt: Fix use-after-free and resource leak risk
Review by sashiko.dev highlighted potential use after free and resource
leak instances.
Set se10_pdev to null to prevent use after free
Remove DMI call back and instead directly call
se10_create_platform_device. Handle error cases appropriately
Nicht bewertetEPSS 0,16%Keine Korrektur veröffentlicht
genirq/proc: Size interrupt directory names for 10-digit interrupt numbers
In the Linux kernel, the following vulnerability has been resolved:
genirq/proc: Size interrupt directory names for 10-digit interrupt numbers
/proc/irq/<n>/ directory names are built in `char name[10]` buffers
with `sprintf(name, "%u", irq)`.
Ten-digit IRQ numbers already need 11 bytes including the trailing NUL, and
current sparse-IRQ configurations allow interrupt numbers in that range.
Size the temporary name buffer for the current decimal form and switch
to bounded formatting when creating or removing the proc entry.
Nicht bewertetEPSS 0,17%Keine Korrektur veröffentlicht
pinctrl: mediatek: paris: bypass pinctrl GPIO layer in set GPIO direction
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: mediatek: paris: bypass pinctrl GPIO layer in set GPIO direction
pinctrl_gpio_direction_input() / pinctrl_gpio_direction_output() take
the pinctrl mutex. This causes a gpiochip operations to need to sleep.
Worse yet, the .can_sleep field in the gpiochip is not set. This causes
the shared GPIO proxy to trip over, as it uses gpiod_cansleep() to check
whether it can use a spinlock or needs a mutex. In this case, it ends
up taking a spinlock, then calls pinctrl_gpio_direction_output(), which
takes a mutex. This causes a huge warning.
While this class of Mediatek hardw
Nicht bewertetEPSS 0,15%Keine Korrektur veröffentlicht
coresight: perf: Retrieve path and source from event data
In the Linux kernel, the following vulnerability has been resolved:
coresight: perf: Retrieve path and source from event data
ETM perf callbacks currently use the per-CPU csdev_src pointer, which
can race with updates during device registration and unregistration.
The AUX setup already builds and stores the path in the event data.
Use this path to retrieve the source instead of csdev_src to avoid
the race.
Export coresight_get_source() and add etm_event_get_ctxt_path() to
retrieve the context's path and its source with READ_ONCE() /
WRITE_ONCE() accessors. Give the comments to explain why this
approach is safe when pause or resume callbac
drm/amdgpu/userq: pin mqd and fw object bo to avoid eviction
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/userq: pin mqd and fw object bo to avoid eviction
mqd and fw objects are queue core objects which should remain
valid and never be unmapped and evicted for user queues to work
properly.
During eviction if these buffers are evicted the hw continue to
use the invalid addresses and caused page faults and system hung.
drm/amdgpu: Bound GPIO I2C table entry count from VBIOS
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Bound GPIO I2C table entry count from VBIOS
Reject undersized tables and cap the derived entry count
to AMDGPU_MAX_I2C_BUS so we do not overrun adev->i2c_bus[]
or walk an absurd number of entries on corrupt size fields.
Nicht bewertetEPSS 0,17%Keine Korrektur veröffentlicht
tty: serial: 8250: protect against NULL uart->port.dev in register
In the Linux kernel, the following vulnerability has been resolved:
tty: serial: 8250: protect against NULL uart->port.dev in register
serial8250_register_8250_port() conditionally copies uart->port.dev
from up->port.dev only when up->port.dev is non-NULL:
if (up->port.dev) {
uart->port.dev = up->port.dev;
...
}
So if both the existing uart slot and up have a NULL ->dev,
uart->port.dev remains NULL. The very next ACPI companion check
then dereferences it unconditionally:
if (!has_acpi_companion(uart->port.dev)) {
has_acpi_companion() reads dev->fwnode without a NULL guard
(include/linux/acpi.h), so this NULL-derefs the kernel for