net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket

In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.

posix-cpu-timers: Prevent UAF caused by non-leader exec() race

In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete() exec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type); de_thread() switch_leader(); release_task(old_leader) __exit_signal(old_leader) sighand = lock(old_leader, sighand); posix_cpu_timers*_exit(); sighand = lock_task_sighand(p) unhash_task(old_leader); sh = lock(p, sighand) old_leader->sighand = NULL; unlock(sighand); (p->sighand == NULL) unlock(sh) return NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is "harmless" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) __exit_signal(p) posix_cpu_timers*_exit(p); unhash_task(p); p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; if (!sighand) return NULL; lock(sighand); if (!sh) WARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e ("posix-cpu-timers: workaround to suppress the problems with mt exec") added a temporary workaround for that in 2010 which surv ---truncated---

Apache HTTP Server: mod_http2: heap corruption and RCE in assign_headers

Concurrent Execution using Shared Resource with Improper Synchronization vulnerability in Apache HTTP Server's mod_http2 in assign_headers() can lead to RCE. This issue affects Apache HTTP Server: from 2.4.55 through 2.4.70. Affected releases of mod_h2 from GitHub: from 2.0.8 through 2.0.42.

KVM: x86: Check for invalid/obsolete root *after* making MMU pages available

In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a "stale" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is "fine", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, "KVM: MMU: ignore zapped root pagetables"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.

chromium-browser: chromium-browser: Information disclosure via race condition in Extensions

Race condition in Extensions in Google Chrome on on Mac prior to 157.0.8103.78 allowed a remote attacker who had compromised the renderer process to obtain sensitive information via crafted network traffic. (Chromium security severity: High)

envd: Host file disclosure through requirements path traversal and TOCTOU

envd provides reproducible development environments for humans and agents. In versions starting with 0.3.38 and before 1.3.6, insufficient containment of host-side requirements-file reads in  install.python_packages(requirements=...)  could allow access to files outside the build context. An attacker able to influence build input could cause file contents interpreted as dependency entries to appear in debug logs or build-step metadata, subject to the envd process’s permissions. Exploitation in version 1.3.5 additionally requires concurrent modification of relevant filesystem paths. This issue is fixed in version 1.3.6.

SeaDoc converter 2.0.4 before 2.0.11 and 3.0.0 before 3.0.8 Path Traversal RCE via confluence-to-wiki

Seafile SeaDoc converter 2.0.4 before 2.0.11 and 3.0.0 before 3.0.8 contains an absolute path traversal vulnerability that allows unauthenticated attackers holding a public share token to execute code. Attackers supply an absolute filename to /api/v1/confluence-to-wiki/ to extract a ZIP from download_url into the Python library path, then trigger the module's import via a file-convert request.

rails-html-sanitizer: Possible XSS via shared scrubber state in concurrent calls

rails-html-sanitizer is responsible for sanitizing HTML fragments in Rails applications. Before 1.7.2, the HTML4 and HTML5 variants of Rails::HTML::SafeListSanitizer reuse one Rails::HTML::PermitScrubber across calls and mutate its tags and attributes without synchronization. In a multithreaded process, concurrent sanitize calls using different tags: or attributes: options can interleave and cause one call to use the other call's allowlist. If a permissive call admits a script element or event-handler attribute, output expected to be sanitized under a stricter policy can retain it and cause cross-site scripting when rendered. Applications that are single-threaded, use one identical allowlist everywhere, or provide a separate scrubber: are not affected. This issue is fixed in version 1.7.2.

Divide By Zero in dlib

Divide By Zero vulnerability in davisking dlib allows remote attackers to cause a denial of service via a crafted file. .This issue affects dlib: before <19.24.7.

Local Information Disclosure via Double Fetch TOCTOU in Android tipc_virtio_dev

In handle_rx_msg of tipc_virtio_dev, there is a possible Double Fetch TOCTOU due to Double Fetch. This could lead to local information disclosure with execution privileges needed. User interaction is for exploitation.

In _vqueue_get_avail_buf_locked of trusty/kernel/lib/trusty/vqueue.c, there is a possible Double-read / TOCTOU due to a race condition. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation.

CCC Attestation SIG attested-tls-poc through commit 731ca82 TOCTOU via Handshake-Only Attestation

CCC Attestation SIG attested-tls-poc through commit 731ca82 contains a time-of-check time-of-use vulnerability because Evidence is appraised only once during the TLS handshake, without post-handshake re-attestation. Attackers with local access to the attesting endpoint can alter workload code, data, configuration, or attached devices like GPUs while peers keep trusting the original Evidence.

In port_shutdown of ipc.c, there is a possible Use After Free due to a race condition. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation.

xen-blkback: Avoid UAF when reading I/O statistics

In the Linux kernel, the following vulnerability has been resolved: xen-blkback: Avoid UAF when reading I/O statistics Reading I/O statistics via sysfs concurrently with tearing down a frontend device might result in UAF or a NULL dereference, as the reading of the statistics data is not synchronized with freeing the data. Use a rwlock for synchronizing. This is XSA-528 / CVE-2026-100082

xen-netback: defer xenvif_mcast_addr_list_free()

In the Linux kernel, the following vulnerability has been resolved: xen-netback: defer xenvif_mcast_addr_list_free() In order for the function to legitimately avoid locking/RCU, it needs to run after all TX/RX processing has finished/stopped: Lookups happen from xenvif_start_xmit(), while adds/removes happen from xenvif_tx_action() (called out of xenvif_poll()). Move the call out of xenvif_disconnect_data() (the call to the function from connect()'s error path doesn't require any cleaning up there), and put it past the synchronization point in backend_disconnect(). This is XSA-527 / CVE-2026-100081.

Busybox: divide-by-zero in the volume_id fat prober via a zero sectors_per_cluster value

A flaw was found in BusyBox. The volume identification component fails to properly validate cluster parameters when analyzing specially formatted FAT filesystems. An attacker able to present a crafted storage device or disk image can trigger a divide-by-zero condition when partition scanning utilities inspect the volume. This issue causes the probing utilities to crash unexpectedly, resulting in a Denial of Service (DoS) that can disrupt device discovery and system boot operations.

WordPress WooCommerce plugin 11.0.0-11.2.2 - Race Condition vulnerability

Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in Automattic WooCommerce woocommerce allows Leveraging Race Conditions.This issue affects WooCommerce: from 11.0.0 through 11.2.2.

TOCTOU Race Condition in TÜBİTAK BİLGEM's Pardus Package Installer

Time-of-check time-of-use (TOCTOU) race condition vulnerability in TÜBİTAK BİLGEM Yazılım Teknolojileri Araştırma Enstitüsü Pardus Package Installer allows Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions. This issue affects Pardus Package Installer: from 0.7.0 before 0.7.1.

Apache Storm Worker Launcher: Local Privilege Escalation to Root via Container Command Files Chowned to the Tenant

Description When launching a Docker or OCI worker, the setuid-root `worker-launcher` first changes ownership of the entire worker directory to the untrusted topology user, and only afterwards reads and acts on the command file that the supervisor wrote into that same directory. The file is opened without `O_NOFOLLOW` and without re-verifying its owner, so between the ownership change and the read the tenant can replace its contents. For the Docker path the parsed command is executed with real uid 0, and the command sanitiser is not a privilege boundary: it admits `-v` with an arbitrary source, `--device`, `--cap-add`, `--security-opt`, `--user` and `--net`, and copies positional arguments through verbatim. A rewritten file therefore yields an attacker-authored, root-equivalent container invocation with the host filesystem available. For the OCI path the same rewrite window applies, and mount validation is structural only, with no source or destination allow-list, so arbitrary host paths can be bind-mounted read-write into the container. The `username` field of the command file is likewise attacker-settable and is checked only against non-root and minimum-uid rules, permitting execution as another tenant's uid. Mitigation Upgrade to 3.1.0, where the command file is validated before the ownership change and re-verified on open, and where mount sources and destinations are constrained by configuration. Users who cannot upgrade immediately should disable Docker and OCI worker isolation, or restrict topology submission on affected supervisors to trusted principals. Note that the launcher must be rebuilt and reinstalled after upgrading. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

Apache Storm Worker Launcher: Local Privilege Escalation to Root via a Time-of-Check Race in the Worker Launcher

Description The setuid-root `worker-launcher` binary adjusts ownership and permissions of worker directories by walking the tree with FTS and calling `lchown` and `chmod` on each entry's full pathname while running with an effective uid of 0. Both syscalls re-resolve the path at the time of the call, after FTS has classified the entry, and the trees being walked are owned and writable by the untrusted topology user. A tenant running code on a supervisor node could therefore replace an intermediate directory component with a symbolic link between classification and the privileged operation, redirecting the root-owned `lchown` or `chmod` at an arbitrary file on the host. The operation is repeatable at will, since crashing a worker forces a relaunch and blob updates re-run the walk, so a failed attempt costs the attacker nothing. This crosses the boundary that `supervisor.run.worker.as.user` and container isolation are intended to enforce. It is the same defect class as the Hadoop container-executor issues from which this code derives. Mitigation Upgrade to 3.1.0, where the privileged walk operates on file descriptors it has already stat'd rather than on pathnames re-resolved at call time. Users who cannot upgrade immediately should not run untrusted topology code on supervisors configured with `supervisor.run.worker.as.user`, since the launcher is the boundary being crossed. Note that the launcher must be rebuilt and reinstalled after upgrading; replacing the Java artifacts alone is not sufficient. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.