| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Locking vulnerability. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to filesystem access for attacker. |
| netty-incubator-codec-ohttp implements Oblivious HTTP (OHTTP) gateway and client functionality using Netty. Prior to 0.0.23.Final, the OHTTP gateway decryption path in codec-ohttp/src/main/java/io/netty/incubator/codec/ohttp/OHttpRequestResponseContext.java allocates a pooled direct ByteBuf for decrypted plaintext before the AEAD tag is verified. When an invalid tag causes decryptChunk() to throw CryptoException, OHttpRequestResponseContext.decodeChunk() does not release the ByteBuf because the allocation is not guarded by try/finally. Repeated invalid encrypted requests can therefore leak native off-heap memory until the gateway is unable to continue serving requests. This issue is fixed in version 0.0.23.Final. |
| Floodlight 71fe8a7 allows disruption of host communication via link spoofing. A port is misclassified as a non-boundary. |
| An issue was discovered in the CheckUser extension for MediaWiki through 1.39.3. Special:CheckUserLog shows usernames that have been hidden. |
| In Oraios AI Serena before 1.0.0, the listen address of the MCP server in HTTP mode is 0.0.0.0. NOTE: the Supplier observed that 0.0.0.0 was a "potential security hazard" but the Serena documentation, at the time of the issue report proposing 127.0.0.1 instead of 0.0.0.0, recommended "use a sandboxed environment for running Serena." |
| In Mbed TLS 3.6.x before 3.6.7 and 4.1.x before 4.1.2, the TLS 1.3 client accepts HelloRetryRequest selecting an unadvertised group. |
| The ITE it82xx2 USB device-controller driver initialized its bus-suspend detection work with k_work_init_delayable(&priv->suspended_work, suspended_handler) inside it82xx2_enable() (the driver's .enable op) in drivers/usb/udc/udc_it82xx2.c. This work item is scheduled essentially continuously while the USB bus is active: the interrupt handler reschedules it on every SOF frame and suspended_handler() reschedules itself, so its timeout node is normally linked in the kernel timeout list / a workqueue pending queue.
k_work_init_delayable() (kernel/work.c) unconditionally overwrites the entire k_work_delayable structure, including its timeout and queue linkage, with no busy check. Because it82xx2_disable() does not cancel the work, a normal disable-then-enable cycle re-runs api->enable() (udc_enable() only rejects a redundant enable, not a re-enable after disable) and re-initializes the still-pending work in place, corrupting the kernel timeout/workqueue linked lists and causing a kernel panic.
An external USB host — for example a host performing USB DFU detach (dfu-util --detach) or forcing repeated attach/reset/re-enumeration — drives the udc_disable()/udc_enable() transitions and controls suspend/resume timing, so it can arrange for the suspend work to be pending across a re-enable. This yields an unauthenticated denial of service (kernel panic) reachable across the USB boundary from a removable, physically-connected host, with no confidentiality or integrity impact demonstrated.
The fix moves the k_work_init_delayable() call into the one-time preinit function so the work is initialized exactly once, eliminating the re-initialization of an in-use item. |
| A memory corruption vulnerability was addressed with improved locking. This issue is fixed in Safari 26.6.1, iOS 18.7.10 and iPadOS 18.7.10, iOS 26.6.1 and iPadOS 26.6.1, macOS Tahoe 26.6.2, visionOS 27. Processing maliciously crafted web content may lead to an unexpected Safari crash. |
| A memory corruption vulnerability was addressed with improved locking. This issue is fixed in Safari 26.6.1, iOS 18.7.10 and iPadOS 18.7.10, iOS 26.6.1 and iPadOS 26.6.1, macOS Tahoe 26.6.2, visionOS 27. Processing maliciously crafted web content may lead to an unexpected Safari crash. |
| In the Linux kernel, the following vulnerability has been resolved:
ocfs2: cluster: don't sleep while holding o2hb_live_lock in o2hb_region_pin()
Patch series "ocfs2: cluster: o2hb_region_pin() fixes", v2.
This series fixes three related issues in o2hb_region_pin(), all are from
the original implementation in commit: 58a3158a5d17 ("ocfs2/cluster:
Pin/unpin o2hb regions"):
1) It is called with o2hb_live_lock (a spinlock) held, but the
underlying configfs_depend_item() sleeps (takes inode rwsem and
pins the filesystem). This triggers BUG under
CONFIG_DEBUG_ATOMIC_SLEEP.
2) When called from the configfs drop_item callback, it creates a
lock order inversion: parent inode_lock -> configfs root
inode_lock, which can deadlock against subsystem unregistration
paths taking root -> parent.
3) If pinning fails partway through o2hb_region_inc_user(), the
o2hb_dependent_users counter is leaked and partially-pinned
regions are never released, leaving heartbeat regions
unprotected on subsequent mounts.
Patch 1 reworks o2hb_region_pin() to drop o2hb_live_lock across each
sleeping configfs_depend_item() call, using a config_item reference to
keep the region alive while unlocked.
Patch 2 adds a from_callback parameter to select
configfs_depend_item_unlocked() when called from configfs context,
avoiding the inode_lock nesting.
Patch 3 fixes the error path in o2hb_region_inc_user() to unpin and
decrement the counter on failure.
This patch (of 3):
o2hb_region_pin() is always called with the o2hb_live_lock spinlock held
(from o2hb_region_inc_user() and o2hb_heartbeat_group_drop_item()), but it
calls o2nm_depend_item() -> configfs_depend_item(), which sleeps: it pins
the configfs filesystem and takes the configfs root inode rwsem. Under
CONFIG_DEBUG_ATOMIC_SLEEP this triggers:
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c
in_atomic(): 1, ... name: mount.ocfs2
down_write
configfs_depend_item
o2hb_region_pin
o2hb_region_inc_user
o2hb_register_callback
dlm_register_domain_handlers
...
ocfs2_dlm_init
ocfs2_mount_volume
ocfs2_fill_super
Rework o2hb_region_pin() to pin one region at a time with the lock dropped
across the sleeping call: under o2hb_live_lock find the next eligible
region and take a config_item reference to keep it alive, drop the lock,
call o2nm_depend_item(), then retake the lock and record the pin. The
config_item_put() is done with the lock released as well, since
o2hb_region_release() also acquires o2hb_live_lock and can sleep. The
region list may change while unlocked, so the scan restarts from the top
after each pin. Local heartbeat still pins only the matching region;
global heartbeat pins all eligible regions.
The unpin path is unaffected: configfs_undepend_item() only takes a
spinlock and does not sleep. |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring/waitid: honor task_work cancellation
io_waitid_cb() may run through the fallback task_work path when
task_work_add() can no longer queue work to the originating task. The
fallback runs from a kworker and io_uring marks such task work as
canceled through tw.cancel.
io_waitid_cb() currently ignores tw.cancel and calls __do_wait().
waitid is task-context dependent: __do_wait() performs child lookup
relative to current, and the retry path also uses
current->signal->wait_chldexit. If the callback runs from the fallback
kworker, current is therefore not the task that submitted the request.
Honor tw.cancel before entering __do_wait(). Complete the request with
-ECANCELED and skip the siginfo copy, since canceled task work may run
without the submitting task's userspace execution context.
Keep the existing siginfo handling for normal waitid completion and
explicit cancellation. |
| In the Linux kernel, the following vulnerability has been resolved:
ipmi: ipmb: validate write message length
ipmb_write() read message fields before validating the length byte.
A zero or short write can read uninitialized stack bytes.
A length smaller than the SMBus header underflows the block write length.
Require a non-empty buffer and the minimum IPMB request length.
Also require the length byte plus payload before parsing the message. |
| In the Linux kernel, the following vulnerability has been resolved:
bridge: mrp: reject zero test interval to avoid OOM panic
br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied
interval value from netlink without validation. When interval is 0,
usecs_to_jiffies(0) yields 0, causing the delayed work
(br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule
itself with zero delay. This creates a tight loop on system_percpu_wq
that allocates and transmits MRP test frames at maximum rate, exhausting
all system memory and causing a kernel panic via OOM deadlock.
The same zero-interval issue applies to br_mrp_start_in_test_parse()
for interconnect test frames.
Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both
IFLA_BRIDGE_MRP_START_TEST_INTERVAL and
IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the
netlink attribute parsing layer before the value ever reaches the
workqueue scheduling code. This is consistent with how other bridge
subsystems (br_fdb, br_mst) enforce range constraints on netlink
attributes. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix WARNING "do not call blocking ops when !TASK_RUNNING"
wait_event_timeout() will set the state of the current
task to TASK_UNINTERRUPTIBLE, before doing the condition check. This
means that ksmbd_durable_scavenger_alive() will try to acquire the mutex
while already in a sleeping state. The scheduler warns us by giving
the following warning:
do not call blocking ops when !TASK_RUNNING; state=2 set at
[<0000000061515a6f>] prepare_to_wait_event+0x9f/0x6c0
WARNING: CPU: 2 PID: 4147 at kernel/sched/core.c:10099 __might_sleep+0x12f/0x160
mutex lock is not needed in ksmbd_durable_scavenger_alive(). |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: fnic: Use GFP_ATOMIC for VLAN alloc under spinlock
fnic_fcoe_process_vlan_resp() allocates a VLAN descriptor with
kzalloc_obj() (default GFP_KERNEL) while holding vlans_lock via
spin_lock_irqsave(). GFP_KERNEL may sleep, which is not allowed in this
atomic context and can trigger a sleeping-from-invalid-context warning
or deadlock.
Pass GFP_ATOMIC so the allocation is safe under the IRQ-safe spinlock. |
| In the Linux kernel, the following vulnerability has been resolved:
net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO
rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from
the probe path, which may sleep and is not timing-critical. When the
reset GPIO is provided by a sleeping controller such as an I2C I/O
expander, gpiod_set_value() warns:
WARNING: drivers/gpio/gpiolib.c:4030 at gpiod_set_value+0x44/0x80, CPU#1: kworker/u16:4/61
Hardware name: B&O MAP CA33 Rev f (UNKNOWN) (DT)
Workqueue: events_unbound deferred_probe_work_func
pc : gpiod_set_value+0x44/0x80
lr : rtl83xx_probe+0x1d8/0x3a0
Call trace:
gpiod_set_value+0x44/0x80 (P)
rtl83xx_probe+0x1d8/0x3a0
realtek_mdio_probe+0x24/0xa0
mdio_probe+0x38/0x78
really_probe+0xc4/0x3e0
__driver_probe_device+0x15c/0x1b8
driver_probe_device+0xb4/0x120
__device_attach_driver+0xb8/0x1a0
bus_for_each_drv+0x88/0xf0
__device_attach+0xa0/0x1d8
device_initial_probe+0x54/0x68
bus_probe_device+0x38/0xa0
deferred_probe_work_func+0xb8/0x120
process_one_work+0x184/0x4e8
worker_thread+0x188/0x308
kthread+0x130/0x150
ret_from_fork+0x10/0x20
Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can
be used without triggering the warning.
The reset GPIO has been driven with the non-sleeping gpiod_set_value()
since the driver was added in v4.19. The call has since been refactored
across several files - from realtek-smi.c / realtek-mdio.c into the common
rtl83xx.c module and then into the rtl83xx_reset_assert() and
rtl83xx_reset_deassert() helpers (both in v6.9). This patch therefore
applies as-is only to kernels that carry those helpers (v6.9+); older
stable kernels need the same gpiod_set_value_cansleep() conversion at the
corresponding open-coded call sites. |
| An issue was discovered in OpenStack Nova before 30.2.2, 31 before 31.2.1, and 32 before 32.1.1. By writing a malicious QCOW header to a root or ephemeral disk and then triggering a resize, a user may convince Nova's Flat image backend to call qemu-img without a format restriction, resulting in an unsafe image resize operation that could destroy data on the host system. Only compute nodes using the Flat image backend (usually configured with use_cow_images=False) are affected. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format
When dumping IB contents from a hung job, amdgpu_devcoredump_format()
acquired the VM root PD's reservation via amdgpu_vm_lock_by_pasid() and
then, for each IB, called amdgpu_bo_reserve() on the BO backing the IB.
Both reservations are reservation_ww_class_mutex objects and neither
used a ww_acquire_ctx, which trips lockdep:
WARNING: possible recursive locking detected
--------------------------------------------
kworker/u128:0 is trying to acquire lock:
ffff88838b16e1f0 (reservation_ww_class_mutex){+.+.}-{4:4},
at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu]
but task is already holding lock:
ffff8882f82681f0 (reservation_ww_class_mutex){+.+.}-{4:4},
at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu]
Possible unsafe locking scenario:
CPU0
----
lock(reservation_ww_class_mutex);
lock(reservation_ww_class_mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
Workqueue: events_unbound amdgpu_devcoredump_deferred_work [amdgpu]
Call Trace:
__ww_mutex_lock.constprop.0
ww_mutex_lock
amdgpu_bo_reserve
amdgpu_devcoredump_format+0x1594 [amdgpu]
amdgpu_devcoredump_deferred_work+0xea [amdgpu]
The two reservations are on different BOs in the captured trace, so the
splat is a lockdep-correctness warning, not an observed deadlock. It
becomes a real self-deadlock whenever the IB BO shares its dma_resv with
the root PD (the always-valid case, see amdgpu_vm_is_bo_always_valid()):
amdgpu_bo_reserve(abo) re-acquires the same ww_mutex without a ticket
and blocks forever. With amdgpu.gpu_recovery=0 the timeout handler
refires every ~2 s and each invocation produces this splat, drowning the
kernel ring buffer.
Now that amdgpu_vm_lock_by_pasid() takes a drm_exec context, move the IB
dumping into a separate helper that locks the root PD and every IB BO
together in a single drm_exec ticket. DRM_EXEC_IGNORE_DUPLICATES handles
IB BOs that share a dma_resv (e.g. always-valid BOs, or two IBs backed
by the same BO). Every lock is now a top-level acquire under one
ww_acquire_ctx, so the recursive ww_mutex condition is gone, and the
per-IB amdgpu_bo_reserve()/amdgpu_bo_unref() dance -- including a BO
refcount leak on the amdgpu_bo_reserve() failure path -- is removed.
(cherry picked from commit d6bf4242731219ee08ce54c365631e395486651e) |
| In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: bail out of setup if the controller is inaccessible
xhci_gen_setup() locates the operational registers using the capability
length read from the very first register:
xhci->op_regs = hcd->regs +
HC_LENGTH(readl(&xhci->cap_regs->hc_capbase));
If the controller is dead or has dropped off the bus, that read returns
~0, HC_LENGTH() truncates it to 0xff, and op_regs ends up 0xff bytes
past the page-aligned MMIO base, i.e. unaligned. The first access
through it, xhci_halt() -> xhci_handshake() reading op_regs->status, is
then an unaligned readl() on device memory. arm64 faults on unaligned
device accesses, so instead of xhci_handshake() catching the all-ones
value and returning -ENODEV, setup oopses:
xhci-pci-renesas 0005:08:00.0: Unable to change power state from D3cold to D0, device inaccessible
xhci-pci-renesas 0005:08:00.0: xHCI Host Controller
xhci-pci-renesas 0005:08:00.0: new USB bus registered, assigned bus number 1
Unable to handle kernel paging request at virtual address ffff80030a770103
ESR = 0x0000000096000021
FSC = 0x21: alignment fault
Internal error: Oops: 0000000096000021 [#1] SMP
pc : xhci_halt [xhci_hcd]
Call trace:
xhci_halt
xhci_gen_setup
xhci_pci_setup
usb_add_hcd
usb_hcd_pci_probe
xhci_pci_common_probe
xhci_pci_renesas_probe
This was hit with a Renesas uPD720201 that failed to power up ("Unable
to change power state from D3cold to D0, device inaccessible") yet still
reached the HCD probe path.
Read the capability register once, and if it reads back the all-ones
value (as xhci_handshake() and xhci_reset() already test for), abort
setup with -ENODEV before op_regs is derived from it. Reading it once
also avoids re-reading a register that may change under a concurrent
hot-removal. |
| In the Linux kernel, the following vulnerability has been resolved:
fuse: fix missing barrier when checking io-uring readiness
fuse_block_alloc() reads fch->initialized and then fch->io_uring.
fch->io_uring is set before fch->initialized, ordered by the smp_wmb()
in fuse_chan_set_intialized(), but fuse_block_alloc() has no matching
read barrier between the two loads.
This may lead a CPU to observe fch->initialized=1 but fch->io_uring=0,
and skip the check that blocks request allocation until the io-uring
queues are ready. This can reintroduce the lock-order inversion deadlock
that commit 3393ff964e0f prevents.
Add an smp_rmb() barrier to pair with the smp_wmb() in
fuse_chan_set_initialized() to prevent this. |
