| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.0.22 and 4.1.14 and 4.2.7 and 4.3.1, Atom exhaustion: toatom on global-parameter :name. resourceexists/2 (and the PUT/DELETE handlers) call rabbitdatacoercion:toatom/1 on the :name URL path segment. toatom/1 uses binarytoatom/2 (unsafe). The endpoint requires policymaker (not management, but below A user with the policymaker tag can crash the node by exhausting the atom table via repeated requests to /api/global-parameters/:name with unique :name Management plugin enabled policymaker tag ~1M HTTP. This issue is fixed in versions 4.0.22 and 4.1.14 and 4.2.7 and 4.3.1. |
| RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15, 4.0.20, 4.1.11, and 4.2.6, the Web STOMP WebSocket handler enforced neither max_frame_size nor login_timeout before authentication, allowing an unauthenticated client to keep a connection alive with a slow stream of small frames and accumulate unbounded pre-authentication state. The rabbitmq_web_stomp plugin must be enabled, and no authentication is required to reach the vulnerable path. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6. |
| RabbitMQ is a messaging and streaming broker. From 4.2.0 until 4.2.8 and 4.3.2, get_auth_mechanism/1 used term_to_binary/1 on the strict_auth_mechanism or preferred_auth_mechanism atom when clearing the corresponding cookie, producing a non-ASCII cookie name that violates RFC 6265 and can prevent the browser from deleting the preference. The issue is not directly exploitable for code execution or data exfiltration; its security relevance is limited to stale authentication-mechanism preferences persisting across logout and login cycles. This issue is fixed in versions 4.2.8 and 4.3.2. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix runtime PM leak in amdgpu_debugfs_test_ib_show()
amdgpu_debugfs_test_ib_show() resumes the device with
pm_runtime_get_sync() before taking the reset domain semaphore with
down_write_killable(). If the write lock acquisition is interrupted,
the function returns without calling pm_runtime_put_autosuspend(),
leaking the runtime PM reference acquired for the device and keeping
the GPU awake.
Drop the runtime PM reference on the interrupted down_write_killable()
error path before returning.
(cherry picked from commit ec30a576c2d4c0364549e6c04218f50704ef56c8) |
| In the Linux kernel, the following vulnerability has been resolved:
gpio: zynq: fix runtime PM leak on request error path
pm_runtime_get_sync() leaves the usage counter incremented even when it
fails, and zynq_gpio_request() returns the error without dropping it.
gpiolib does not call ->free() when ->request() fails, so zynq_gpio_free(),
which holds the only matching pm_runtime_put(), never runs. The reference
is leaked and the controller can no longer runtime-suspend, so its clock
stays enabled.
Switch to pm_runtime_resume_and_get(), which only increments the usage
counter on success. |
| In the Linux kernel, the following vulnerability has been resolved:
writeback: report a Tasks-RCU quiescent state per cgwb drain pass
cleanup_offline_cgwbs_workfn() drains a dying cgwb by calling
cleanup_offline_cgwb() until it returns false, with a cond_resched()
between passes. On a CONFIG_PREEMPTION kernel that cond_resched() does
nothing: _cond_resched() is a plain "return 0", and under PREEMPT_DYNAMIC
the full and lazy modes disable it. Since commit 7dadeaa6e851 ("sched:
Further restrict the preemption modes") those are the only two models on
the architectures with PREEMPT_LAZY support, arm64 and x86 among them, so
the drain loop never reports a Tasks-RCU quiescent state.
A worker draining a cgwb with millions of attached inodes runs for
minutes. On a 6.18 arm64 host in lazy mode the cgwb worker drained one
dying cgroup's writeback domain for over 11 minutes. A BPF program unlink
(bpf_trampoline_unlink_prog -> bpf_trampoline_update ->
unregister_ftrace_direct -> ftrace_shutdown -> synchronize_rcu_tasks())
waited on that grace period while holding the trampoline mutex, 42 tasks
queued behind it in D state, and the hung task detector fired at 614 s and
panicked the host. Any BPF or ftrace detach during a long drain inherits
the drain's length.
Fix this by calling cond_resched_tasks_rcu_qs() so we do not stall out
anybody who calls sycnrhonize_rcu_tasks(). We put this in a do { } while
loop because if we have many small cgroups cleanup_offline_cgwb() will
return false and we will never call cond_resched_tasks_rcu_qs(), creating
the same problem. |
| Out-of-bounds read in DNS Server allows an authorized attacker to disclose information over a network. |
| In the Linux kernel, the following vulnerability has been resolved:
net: arp: terminate device name before lookup
The ARP ioctl copies a user-provided struct arpreq into a stack object. Its
arp_dev field may contain IFNAMSIZ bytes without a NUL terminator.
Such input is passed to dev_get_by_name_rcu() or __dev_get_by_name(), where
strcmp() can read past the end of the stack object when a matching
alternative interface name exists.
Terminate the field before the lookup to prevent the out-of-bounds read. |
| Dell Container Storage Modules (CSM) versions prior to 1.18.0, contains an Improper Certificate Validation vulnerability in the proxy-server component. An unauthenticated adjacent network attacker could potentially exploit this vulnerability, leading to information exposure of storage backend administrator credentials. |
| IBM MQ could allow an authenticated attacker to cause a denial of service or potentially execute arbitrary code due to a heap buffer overflow when processing MQPUT operations with malformed message options. |
| The insights-runtime-extractor runs as a privileged DaemonSet (`hostPID: true`)
that scans container processes for runtime fingerprinting. When scanning a
container, the coordinator:
1. **fork()s** a child process
2. **setns()** into the target container's PID and mount namespaces
3. **fchdir()** back to an orphaned FD pointing at the extractor's own root
filesystem (where `/crio.sock` is hostPath-mounted)
4. Calls **only `seteuid(target_uid)`** — changing the effective UID but leaving
the **real UID and saved-set-UID at 0** and **retaining the permitted
capability set**
5. The `check_no_privileged_perms()` guard inspects only the Effective capability
set (so it passes), and is **skipped entirely when the target runs as uid 0**
6. The `VersionExecutable` fingerprint invokes `fpr_kind_executable` with
`process.command_line[0]` — the target's argv[0], read from
`/proc/<pid>/cmdline` and **fully controlled by the workload**
7. `fpr_kind_executable` calls `exec.Command(executable, "--version").Output()`
— executing the **workload's own binary** inside the workload's mount
namespace while **ruid=0 in the host user namespace**
The executed process can call `setuid(0)` to restore full root with
`CAP_SYS_ADMIN`, and inherits the orphaned cwd which resolves into the extractor
container's filesystem containing the host CRI-O socket.
## Affected Code
### 1. Insufficient privilege drop (Rust — extractor coordinator)
**File:** `extractor/src/insights_runtime_extractor.rs`
```rust
// Lines 139-146 — seteuid-only drop, guard skipped for root containers
join_process_namespaces(process.pid)?;
change_dir(current_dir);
switch_user(*process.uid)?;
if *process.uid != 0 {
perms::check_no_privileged_perms()
.expect("Must not have privileged permissions to run fingerprints");
}
fingerprint::run_fingerprints(&config, out_dir, &process);
```
```rust
// Lines 182-185 — only effective UID changed; ruid/suid stay 0
fn switch_user(uid: u32) -> Result<(), ScannerError> {
debug!("... Becoming user: {uid}");
seteuid(uid.into()).map_err(|e| ScannerError::Errno(e))
}
```
### 2. Execution of untrusted binary (Go — fingerprint)
**File:** `fingerprints/pkg/utils/file.go`
```go
// Lines 75-80 — executes a path taken verbatim from workload's argv[0]
func GetExecutableVersionOutput(executable string) (string, error) {
out, err := exec.Command(executable, "--version").Output()
if err != nil {
return "", err
}
return string(out), nil
}
```
### 3. Workload-controlled path forwarded (Rust — version_executable)
**File:** `version_executable.rs`
```rust
// Lines 29-34 — workload-controlled command_line[0] forwarded to fingerprint
return Some(vec![
fpr_kind_executable,
out_dir.to_string(),
String::from(&process.command_line[0]),
String::from(&version_executable.runtime_kind_name),
]);
```
## Attack Pattern
**Attacker:** Any tenant able to schedule a pod (unprivileged, any namespace)
**Victim:** The node running the insights-runtime-extractor DaemonSet
**Trigger:** Automatic — the DaemonSet scans all container processes on the node
**Attack sequence:**
1. Attacker creates a pod whose process name matches a configured
versioned-executable pattern (`node`, `python`, `python3`, `MainThread`,
or contains `java`)
2. The pod's main binary (at the path matching argv[0]) is a malicious
executable that calls `setuid(0)` to restore root
3. When the insights operator triggers a scan, the DaemonSet forks, enters the
attacker's mount namespace, and executes the attacker's binary with ruid=0
4. The attacker's code regains full root with `CAP_SYS_ADMIN` in the host user
namespace
5. The inherited cwd contains the host CRI-O socket → full node compromise |
| A denial-of-service issue was addressed with improved input validation. This issue is fixed in iOS 27 and iPadOS 27. A remote attacker may be able to cause a denial-of-service. |
| A use after free issue was addressed with improved memory management. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. An app may be able to cause unexpected system termination or corrupt kernel memory. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/client: fix restore of partially initialized client
I got a null-ptr-deref report when closing a DRM file descriptor:
WARNING: drivers/gpu/drm/drm_atomic.c:2031 at
__drm_atomic_helper_set_config+0x18e/0x1b0 [drm]
Call Trace:
drm_client_modeset_commit_atomic+0x16b/0x220 [drm]
drm_client_modeset_commit_locked+0x56/0x160 [drm]
drm_client_modeset_commit+0x21/0x40 [drm]
__drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0x7b/0x80
drm_fbdev_client_restore+0xe/0x20 [drm_client_lib]
drm_client_dev_restore+0x9f/0xc0 [drm]
drm_release+0xc5/0xe0 [drm]
The warning is followed by a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000008
RIP:
__drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0x41/0x80
[drm_kms_helper]
Call Trace:
drm_fbdev_client_restore+0xe/0x20 [drm_client_lib]
drm_client_dev_restore+0x9f/0xc0 [drm]
drm_release+0xc5/0xe0 [drm]
__fput+0xdc/0x2b0
__x64_sys_close+0x39/0x80
do_syscall_64+0x8d/0x460
entry_SYSCALL_64_after_hwframe+0x76/0x7e
drm_client_register() adds the DRM client to the device client list
before invoking the initial hotplug callback. If the hotplug callback
fails, the client remains registered.
For the fbdev client, a failure during drm_fb_helper_initial_config()
causes the partially initialized fbdev helper to be cleaned up.
drm_fb_helper_fini() releases fb_helper->info and leaves it NULL.
The fbdev client therefore remains registered even though there is no
fully initialized framebuffer device.
Later, when userspace closes the DRM file descriptor, drm_release()
can invoke the restore callbacks of registered DRM clients:
drm_release()
drm_client_dev_restore()
drm_fbdev_client_restore()
drm_fb_helper_restore_fbdev_mode_unlocked()
drm_fbdev_client_restore() currently restores the fbdev state
unconditionally. For a partially initialized fbdev client this can
submit an incomplete modeset state and subsequently access fbdev
state which has not been initialized, resulting in the warning and
NULL pointer dereference above.
drm_fbdev_client_unregister() already uses fb_helper->info to
distinguish a fully probed framebuffer device from a partially
initialized client.
Use the same condition in drm_fbdev_client_restore() and skip restore
if no framebuffer device has been successfully initialized. |
| In the Linux kernel, the following vulnerability has been resolved:
writeback: bound cleanup_offline_cgwb() rescans by rotating scanned inodes
cleanup_offline_cgwb() prepares at most WB_MAX_INODES_PER_ISW inodes
per call and is called again until the dying wb is drained, but every
call walks wb->b_attached and then wb->b_dirty_time from the same end.
Inodes already prepared (they stay on the list with I_WB_SWITCH set
until the switch worker runs) and inodes that cannot be switched
(I_FREEING, I_WILL_FREE, !SB_ACTIVE, DAX, already on the target wb)
stay where they are, so each pass rescans a growing run of them under
wb->list_lock and a full drain is quadratic in the number of inodes on
the list. With ~17M inodes attached to one dying cgwb we saw this end
in soft lockups, with CPUs reported stuck for 21-48s.
Walk both lists from the oldest end and move every scanned inode to
the newest end, so the next pass starts where the previous one stopped
and the drain becomes linear. b_attached is unordered, so nobody sees
the reorder there. b_dirty_time is ordered by dirtied_when, but the
oldest unscanned inode stays at the end move_expired_inodes() picks
from, sync takes the whole list regardless of order, and prepared
inodes leave the list as soon as the switch work runs and get a new
dirtied_time_when on the new wb anyway, so the only inodes left out of
order are the ones that can never switch (DAX), and only on the dying
wb. |
| Improper Validation of Specified Quantity in Input vulnerability in WP Desk Flexible Quantity – Measurement Price Calculator for WooCommerce flexible-quantity-measurement-price-calculator-for-woocommerce allows Input Data Manipulation.This issue affects Flexible Quantity – Measurement Price Calculator for WooCommerce: from n/a through 2.3.22. |
| The Salon Booking System WordPress plugin before 10.31.11 does not restrict which user account its salon staff roles may edit through the customers management screen, allowing users with the Salon Staff or Salon Worker role to reset any other user's role, including administrators, to a customer and to overwrite arbitrary profile fields on any account, leading to loss of administrative access and potential site lockout. |
| The Salon Booking System WordPress plugin before 10.31.11 does not validate a user-supplied image URL before fetching it server-side and writing the response to a publicly accessible location under an attacker-chosen filename, allowing users with the Salon Staff role or higher to force the server to read internal-only resources and disclose them, and to store a malicious SVG that runs arbitrary scripts in the site's origin for anyone who opens it. |
| The Salon Booking System WordPress plugin before 10.31.11 does not restrict one of its REST API endpoints to salon staff, allowing any authenticated user, such as a subscriber, to retrieve every discount coupon configured on the site, including coupons the administrator has chosen to hide from customers, together with their amounts, validity dates and usage limits. |
| Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Arraytics Booktics booktics allows SQL Injection.This issue affects Booktics: from n/a through 1.0.29. |
