Information Disclosure

A permissions validation flaw across Apple's iOS, iPadOS, macOS, and visionOS could allow a local malicious app to delete arbitrary files, leading to data loss. The issue has a low exploitation probability (EPSS 0.16%) and no known active exploits or public exploit code. Patches are available in the respective OS updates.

UI spoofing in Apple Safari 26.5 and earlier allows attackers using cross-origin framing to misrepresent website identity. The vulnerability requires user interaction (visiting a malicious page) and could lead to phishing or deceptive actions. No active exploitation or public exploit code identified; patch is available.

Information disclosure in macOS and tvOS due to a race condition allows a malicious local app to read sensitive user data without authorization. Affected versions include macOS prior to Sonoma 14.8.8, Sequoia 15.7.8, and Tahoe 26.6, and tvOS prior to 26.6. No active exploitation or public exploit code has been identified, and EPSS indicates very low exploitation probability.

Information disclosure in macOS prior to 15.7.8, 14.8.8, and 26.6 allows a malicious app to leak sensitive user information. The vulnerability arises from improper removal of sensitive data, which Apple addressed in these updates. No active exploitation is known, and EPSS indicates a low probability of exploitation (0.16%).

A symlink handling vulnerability in macOS allows a malicious application to modify protected parts of the file system. Affected versions include macOS prior to Sequoia 15.7.8, Sonoma 14.8.8, and Tahoe 26.6. Exploitation requires user interaction (opening a malicious app), and no public exploit code or active exploitation has been identified.

A malicious app on macOS can read kernel memory due to insufficient validation. This information disclosure vulnerability is fixed in macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, and macOS Tahoe 26.6. No active exploitation or public exploit code has been identified, and the EPSS score is very low (0.16%).

A local denial-of-service vulnerability in Apple's operating systems allows a malicious app to cause unexpected system termination by triggering an out-of-bounds read. Fixes are available in version 26.6 for iOS, iPadOS, macOS, tvOS, visionOS, and watchOS; no active exploitation or public exploit has been identified, and EPSS indicates a low probability of exploitation.

Local information disclosure in Apple iOS/iPadOS 26.x, macOS Tahoe 26.x, macOS Sequoia 15.x, macOS Sonoma 14.x, tvOS 26.x, visionOS 26.x and watchOS 26.x lets an app installed and run by the user read sensitive user data because of insufficient access checks (CWE-200), a flaw Apple fixed in iOS 26.6, iPadOS 26.6, macOS Tahoe 26.6, macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, tvOS 26.6, visionOS 26.6 and watchOS 26.6. Exploitation requires the user to install and launch a malicious or malicious-behaving app on an unpatched device (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N, base 5.5); there is no remote or network-reachable path and no privilege escalation is needed, so the practical exposure is limited to confidentiality on devices where sideloaded or otherwise untrusted apps are allowed. There is no public exploit identified at time of analysis, CISA's SSVC decision framework records exploitation as none and technical impact as partial, and EPSS is only 0.17% (6th percentile), so every signal aligns with a genuine but low-priority issue that should be resolved by routine patch cycles rather than emergency response.

Kernel memory disclosure in macOS allows a local app to read uninitialized kernel memory, potentially exposing sensitive information. Apple has released patches in macOS Sonoma 14.8.8, Sequoia 15.7.8, and Tahoe 26.6. The vulnerability has a low EPSS score (0.17%) with no known active exploitation or public exploit code.

Physical access to a locked Apple device running vulnerable iOS or macOS allows an attacker to view sensitive user information due to an out-of-bounds read. The flaw is fixed in iOS 26.6, iPadOS 26.6, and multiple macOS versions. No public exploit or active exploitation has been reported.

Kernel memory disclosure in Apple iOS and iPadOS (fixed in 26.6), macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6, tvOS 26.6, visionOS 26.6 and watchOS 26.6 allows a locally running app to read kernel memory that should be inaccessible to it, undermining the isolation boundary between user-space apps and the kernel. The prerequisite is meaningful: an attacker must first get attacker-controlled code executing on the device (a malicious, sideloaded, or compromised app), and the flaw itself yields only disclosure - high confidentiality impact but no integrity or availability impact, so it is best characterized as one link in a larger privilege-escalation or jailbreak chain rather than a standalone compromise. Vendor patches are available for every affected platform; there is no remote or network attack vector, no public exploit code identified at time of analysis, no confirmed active exploitation (CISA SSVC exploitation: none), and EPSS is low at 0.17% (7th percentile), consistent with the moderate 5.5 severity and the local-only, code-execution-gated exploitation model.

Information disclosure in Apple iOS/iPadOS versions prior to 26.6 allows a locally installed app to access sensitive user data without proper permissions. Apple has released patches in iOS/iPadOS 26.6, macOS Tahoe 26.6, tvOS 26.6, and watchOS 26.6. No public exploit or active exploitation has been reported, and the EPSS score indicates a low likelihood of exploitation.

Bypass of iframe sandboxing policy in Apple Safari and all Apple operating systems through version 26.5 allows malicious web content to violate sandbox restrictions. Affected users include anyone running Safari on iOS, iPadOS, macOS Tahoe, tvOS, visionOS, or watchOS prior to version 26.6. An attacker can cause integrity violations, such as injecting or modifying content within sandboxed iframes, but requires user interaction (clicking a link or visiting a malicious page) and no public exploit or active exploitation has been identified at this time.

A malicious app can access sensitive user

iOS and iPadOS versions before 26.6 allow a malicious app to modify protected file system areas via a race condition. The vulnerability, tracked as CVE-2026-43811, requires local user interaction and has no known public exploit or active exploitation, with EPSS indicating very low real-world likelihood.

Information disclosure in macOS asset catalog processing allows local attackers to read process memory by enticing a user to open a malicious asset catalog. Affected versions prior to macOS Sequoia 15.7.8 and Sonoma 14.8.8 are vulnerable. No active exploitation or public exploit code exists; EPSS indicates low exploitation probability.

Protected user data exposure in Apple operating systems allows a malicious app with on-device access to read sensitive information through insufficient input sanitization. This CVE-2026-43714 affects iOS and iPadOS before 26.6, macOS Sequoia before 15.7.8, Sonoma before 14.8.8, Tahoe before 26.6, visionOS before 26.6, and watchOS before 26.6. No public exploit has been identified and the low EPSS score

Denial-of-service via type confusion in Apple ImageIO affects iOS, iPadOS, macOS, tvOS, visionOS, and watchOS. Processing a maliciously crafted image can crash an application, with no code execution. No active exploitation or public exploit is known; EPSS 0.17% indicates low likelihood of widespread attacks.

Cleartext transmission of sensitive data in Apple iOS 26.6 and earlier allows an app to access sensitive user data over the network. The issue is fixed by enforcing HTTPS in iOS and iPadOS 26.6, tvOS 26.6, visionOS 26.6, and watchOS 26.6. No public exploit has been identified and EPSS risk is low (0.16%).

Local information disclosure in macOS Tahoe and watchOS allows an installed app to access sensitive user data without proper authorization. The vulnerability requires user interaction and is fixed in macOS Tahoe 26.6 and watchOS 26.6. No active exploitation or public exploit has been reported, and EPSS probability is low at 0.15%.

Information disclosure in iOS and iPadOS versions before 26.6 allows a locally installed malicious application to access sensitive user data without proper authorization. Apple addressed the flaw in iOS 26.6 and iPadOS 26.6 with improved state management; no active exploitation or public proof-of-concept has been identified. The EPSS exploitation probability is low (0.14%), consistent with the local attack vector and required user interaction.

Sensitive user data can be accessed by unauthorized apps on macOS and watchOS due to an authorization flaw in state management. Apple released patches in macOS Sequoia 15.7.8, Sonoma 14.8.8, Tahoe 26.6, and watchOS 26.6. No public exploit or active exploitation is known; EPSS indicates a low likelihood of exploitation.

Sensitive kernel state leak in macOS allows a local application to read kernel memory. Apple fixed this in macOS Sequoia 15.7.8, Sonoma 14.8.8, and Tahoe 26.6 by improving redaction. The vulnerability has low exploitation probability (EPSS 0.16%) and is not known to be actively exploited.

Information disclosure in Apple Contacts across iOS, iPadOS, macOS, visionOS, and watchOS allows a local attacker to leak sensitive data by processing a maliciously crafted contact. Apple has released patches in iOS 26.6 and other updates. No public exploit is identified, and EPSS indicates

Sensitive information disclosure vulnerability in macOS via a race condition allows a local malicious application to access user data. Apple fixed the issue in macOS Sequoia 15.7.8, Sonoma 14.8.8, and Tahoe 26.6. No active exploitation or public proof-of-concept is known.

Information disclosure in Apple iOS, iPadOS, and macOS Tahoe allows a malicious app with local access to read a user's contacts database. The flaw is fixed in iOS 26.6, iPadOS 26.6, and macOS Tahoe 26.6. No public exploit or active exploitation has been reported, and the EPSS score (0.15%) indicates low exploitation likelihood.

In the Linux kernel, the following vulnerability has been resolved: net: psample: fix info leak in PSAMPLE_ATTR_DATA psample open codes nla_put() presumably to avoid wiping the data with 0s just to override it with packet data. This open coding is missing clearing the pad, however, each netlink attr is padded to 4B and data_len may not be divisible by 4B.

In the Linux kernel, the following vulnerability has been resolved: ipv6: ndisc: fix NULL deref in accept_untracked_na() accept_untracked_na() re-fetches the inet6_dev with __in6_dev_get(dev) and dereferences idev->cnf.accept_untracked_na without a NULL check, even though its only caller ndisc_recv_na() already fetched and NULL-checked idev for the same device. Both reads of dev->ip6_ptr run in the same RCU read-side critical section, but a concurrent addrconf_ifdown() can clear dev->ip6_ptr between them: lowering the MTU below IPV6_MIN_MTU calls addrconf_ifdown() without the synchronize_net() that orders the unregister path, so the re-fetch returns NULL and oopses: BUG: KASAN: null-ptr-deref in ndisc_recv_na (net/ipv6/ndisc.c:974) Read of size 4 at addr 0000000000000364 Call Trace: <IRQ> ndisc_recv_na (net/ipv6/ndisc.c:974) icmpv6_rcv (net/ipv6/icmp.c:1193) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479) ip6_input_finish (net/ipv6/ip6_input.c:534) ip6_input (net/ipv6/ip6_input.c:545) ip6_mc_input (net/ipv6/ip6_input.c:635) ipv6_rcv (net/ipv6/ip6_input.c:351) </IRQ> It is reachable by an unprivileged user via a network namespace. Pass the caller's already validated idev instead of re-fetching it; the idev stays alive for the whole RCU critical section, so it is safe even after dev->ip6_ptr has been cleared.

In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix null-ptr-deref in fib6_nh_mtu_change(). fib6_nh_mtu_change() re-fetches idev via __in6_dev_get(arg->dev) and dereferences idev->cnf.mtu6 without a NULL check. addrconf_ifdown() clears dev->ip6_ptr with RCU_INIT_POINTER() after rt6_disable_ip() has released tb6_lock, so the RA-driven MTU walk can observe a NULL idev and oops. The caller rt6_mtu_change_route() guards its own __in6_dev_get(), but this re-fetch is unguarded; nexthop-backed routes survive addrconf_ifdown()'s flush, so the walk still reaches it after ip6_ptr is nulled. Return 0 when idev is NULL, matching rt6_mtu_change_route() and the fib6_mtu() fix in commit 5ad509c1fdad ("ipv6: Fix null-ptr-deref in fib6_mtu()."). Oops: general protection fault, ... KASAN: null-ptr-deref in range [0x00000000000002a8-0x00000000000002af] RIP: 0010:fib6_nh_mtu_change+0x203/0x990 rt6_mtu_change_route+0x141/0x1d0 __fib6_clean_all+0xd0/0x160 rt6_mtu_change+0xb4/0x100 ndisc_router_discovery+0x24b5/0x2cb0 icmpv6_rcv+0x12e9/0x1710 ipv6_rcv+0x39b/0x410

In the Linux kernel, the following vulnerability has been resolved: bridge: cfm: reject invalid CCM interval at configuration time ccm_tx_work_expired() re-arms itself via queue_delayed_work() using the configured exp_interval converted by interval_to_us(). When exp_interval is BR_CFM_CCM_INTERVAL_NONE or out of range, interval_to_us() returns 0, causing the worker to fire immediately in a tight loop that allocates skbs until OOM. Fix this by validating exp_interval at configuration time: - Constrain IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL to the valid range [BR_CFM_CCM_INTERVAL_3_3_MS, BR_CFM_CCM_INTERVAL_10_MIN] in the netlink policy so userspace cannot set an invalid value. - Reject starting CCM TX in br_cfm_cc_ccm_tx() when exp_interval has not yet been configured (defaults to 0 from kzalloc).

Information disclosure in JFrog Artifactory allows authenticated users with read access to an ordinary repository to retrieve protected build environment secrets by manipulating repository parameters, exposing sensitive configuration data with high confidentiality impact. No integrity or availability impact is reported, and no active exploitation or public exploit code has been identified at this time. JFrog has published advisories but patch version details are not specified in the CVE record.

Audit log disclosure in Honeywell S35 Series cameras allows unauthenticated remote attackers to retrieve audit logs, potentially exposing sensitive operational information. Affected are all firmware versions up to HC5.26.1.14.20260207. No public exploit or active exploitation has been identified at the time of analysis, and the vulnerability is not listed in CISA KEV.

Devolutions Server versions 2026.2.4.0 through 2026.2.12.0 and 2026.1.23.0 and earlier contain an improper access control flaw in the NetBox synchronizer that allows an authenticated user with view-only permissions to retrieve a stored API token. No active exploitation or public exploit code has been reported; EPSS indicates a 0.13% probability of exploitation, making mass targeting unlikely. The vulnerability is rated Medium severity with a CVSS base score of 4.3.

Unauthenticated remote attackers can partially read and modify data in Apache Wicket versions 9.0.0 through 9.23.0 and 10.0.0 through 10.9.0 due to a protection mechanism that relies on insufficiently random values. The vulnerability is automatable with low attack complexity and no user interaction, though no active exploitation or public exploit code has been observed at this time. While the technical impact is limited to partial confidentiality and integrity compromise, the widespread enterprise use of Wicket makes it a moderate priority for patching.

Double free in HDF5 library allows a local attacker to cause a denial of service via a crafted file with an oversized chunk size. Processing the file with h5repack triggers an application abort, with no confidentiality or integrity impact. No active exploitation or public exploit code has been confirmed.

Heap-based buffer overflow in HDF5 through 2.1.1 enables attackers to crash applications and potentially corrupt data by providing a crafted HDF5 file. The flaw lies in the shared‑message list‑index deserializer (SOHM), allowing out‑of‑bounds heap reads and writes when a num_messages field exceeds the declared list_max. No active exploitation has been reported, but the issue is publicly documented and a proof‑of‑concept may exist in the linked issue.

Denial-of-service in Erlang OTP's epmd daemon due to improper handling of file descriptor exhaustion allows an unauthenticated remote attacker to terminate the daemon. The vulnerability arises from calling epmd_cleanup_exit() on EMFILE/ENFILE errors instead of recovering, and can lead to permanent service failure on Debian/Ubuntu systems using systemd. No active exploitation identified (SSVC exploitation none, EPSS 0.39%) and no public exploit code is known.

Information disclosure vulnerability in Ericsson Packet Core Controller (PCC) versions before 1.39 permits an attacker with high privileges on an adjacent network to enumerate system users through the configuration management interface. No evidence of active exploitation or public exploit code has been identified at this time, and the CVSS score of 4.8 (Medium) reflects the requirement for elevated privileges and adjacent access.

Information disclosure in Ericsson Packet Core Controller (PCC) prior to version 1.39 allows high-privileged attackers on adjacent networks to extract system secrets via error messages triggered by crafted Configuration Management commands. No public exploit or active exploitation has been identified at analysis time.

Information disclosure in Exclusive Addons Elementor versions up to 2.8.0 allows unauthenticated remote attackers to access sensitive data. The vulnerability is classified as CWE-497 exposure of sensitive information. No public exploit code or active exploitation has been reported at time of analysis.

Sensitive data exposure in MapPress Maps for WordPress <= 2.97.6 allows unauthenticated remote attackers to access potentially sensitive information through a vulnerable plugin endpoint. The flaw, assigned CWE-497, permits disclosure of internal data such as configuration details or API keys without any user interaction, facilitating further attacks. No public exploit or active exploitation has been reported at the time of analysis, but the low attack complexity elevates its practical risk.

Sensitive data exposure in the Yukassa for WooCommerce plugin allows authenticated subscribers to access sensitive payment information, potentially including transaction details or customer data. The vulnerability affects plugin versions up to 2.16.1. No public exploit or active exploitation has been identified at the time of analysis.

Out-of-bounds heap read in GNU Binutils linker when processing 32-bit XCOFF files allows local attackers to disclose heap memory and cause denial of service. Affects Red Hat Enterprise Linux 6 through 10, Hardened Images, and OpenShift Container Platform 4. No public exploit or active exploitation identified at time of analysis; EPSS data unavailable.

Local attackers with low privileges can trigger an out-of-bounds read in whisper.cpp 1.8.4-58 by supplying a very short audio sample to the log_mel_spectrogram function. This heap read overflow may leak sensitive information but does not allow code execution or system compromise. No public exploit or active exploitation has been reported.

Information disclosure vulnerability in HCL Connections 8.0 allows an authenticated low-privilege user to access sensitive data through a vulnerable endpoint, requiring user interaction. No public exploit or active exploitation has been identified, and the overall risk is low.

Low-severity information disclosure in HCL Connections allows authenticated users with low privileges to obtain sensitive information they are not entitled to, caused by improper error handling. Exploitation requires user interaction and does not affect integrity or availability. No active exploitation or public exploit code has been reported.

We are tasked with synthesizing data about CVE-2026-57916 into a comprehensive analysis. We must follow all rules strictly. First, gather data from the input: - CVE ID: CVE-2026-57916 - Description: proCertum SmartSign opens Certificate Practice Statement (CPS) URI without schema validation. An attacker can prepare arbitrary certificate with CPS URI pointing to a local executable file or any URL, sign a document with it, and send it to the victim. When the victim opens the document in the application, the specified file will be executed (or webpage will be opened). This issue was fixed in version 9.4.3.90. - CVSS Score: 4.6 - CVSS Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N - CWE: CWE-73 External Control of File Name or Path - Reported by: CERT-PL - CPE: cpe:2.3:a:asseco:procertum_smartsign:*:*:*:*:*:*:*:* - Tags: Information Disclosure, Procertum Smartsign (likely a typo, should be proCertum SmartSign) - References: - cert.pl/posts/2026/07/CVE-2026-57916 - pomoc.certum.pl/pl/oprogramowanie/procertum-smartsign/ Now, we have to synthesize. Note: There is no KEV status, no EPSS, no POC mention. So we'll use standard phrases. Let's construct each field. product_name: "proCertum SmartSign" - the specific product. Use 1-3 words. summary: Need to start with impact verb and product. "proCertum SmartSign allows arbitrary file execution via CPS URI due to missing schema validation." Possible summary: "proCertum SmartSign before 9.4.3.90 fails to validate the schema of Certificate Practice Statement (CPS) URIs, allowing a document recipient to be tricked into executing a local executable or opening a malicious webpage when viewing a specially crafted signed document. No authentication required; user interaction is needed to open the document." The attack vector is local? CVSS says AV:L, meaning local, but description suggests sending document to victim, so the execution occurs when victim opens it. The CVSS 4.0 has UI:A (Active), meaning

Integer overflow in the print_string_ptr() function of the cJSON library on 32-bit platforms causes a heap buffer overflow when processing crafted JSON strings with approximately 858,993,460 control characters. Applications using cJSON_PrintBuffered() with a pre-allocated buffer are vulnerable, potentially leading to remote code execution, information disclosure, or denial of service. No public exploit or active exploitation has been identified at the time of analysis.

Username enumeration and brute-force password attempt in Quiz and Survey Master WordPress plugin before 11.1.3 allows unauthenticated attackers to enumerate valid usernames and bypass brute-force protections via distinct responses on front-end credential checks. Publicly available exploit code exists, though no active exploitation has been reported. The medium-severity flaw, while not directly exposing passwords, facilitates credential-stuffing and further attacks against identified accounts.

Information disclosure in perwendel Spark (SparkJava) up to version 2.9.4 via symlink following in the staticFiles.externalLocation method allows remote attackers with low privileges to read arbitrary files from the server. Publicly available exploit code exists, but no active exploitation or CISA KEV listing has been confirmed. The project maintainer has not yet responded to the issue report.

Information disclosure in mf-yang openclaw-cn up to version 0.2.1 allows remote authenticated attackers with low privileges to leak sensitive data by supplying a crafted URL to the scheme handler. Public exploit code is available, though no active exploitation has been confirmed by CISA KEV.

Memory exhaustion in ImageMagick's magick CLI tool allows a local attacker to cause denial of service by repeatedly supplying malformed command-line arguments. Affects versions before 7.1.2-27. Vendor patch is available; no public exploit or active exploitation reported.

In the Linux kernel, the following vulnerability has been resolved: tty: serial: samsung: Remove redundant port lock acquisition in rx helpers Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions.

In the Linux kernel, the following vulnerability has been resolved: drm/hyperv: validate VMBus packet size in receive callback hyperv_receive_sub() reads msg->vid_hdr.type and dispatches into one of four message-type branches without knowing how many bytes the host wrote into hv->recv_buf. The completion path then runs memcpy(hv->init_buf, msg, VMBUS_MAX_PACKET_SIZE), so the consumer that wakes on wait_for_completion_timeout() can read up to 16 KiB of residue from a prior message as if it were the response payload. Pass bytes_recvd into hyperv_receive_sub() and reject any packet that does not cover the pipe + synthvid header. A single switch on msg->vid_hdr.type then computes the type-specific payload size: the three completion-driving types (SYNTHVID_VERSION_RESPONSE, SYNTHVID_RESOLUTION_RESPONSE, SYNTHVID_VRAM_LOCATION_ACK) fall through to a shared exit that requires that size before memcpy/complete, while SYNTHVID_FEATURE_CHANGE validates its own payload and returns before reading is_dirt_needed. Unknown types are dropped. SYNTHVID_RESOLUTION_RESPONSE is variable length: the host fills resolution_count entries, not the full SYNTHVID_MAX_RESOLUTION_COUNT array. Validate the fixed prefix first so resolution_count can be read, bound it against the array, then require only the count-sized array, so the shorter responses the host actually sends are accepted. Only run the sub-handler when vmbus_recvpacket() returned success. The memcpy length is bytes_recvd, which is bounded by VMBUS_MAX_PACKET_SIZE only on a successful receive; on -ENOBUFS vmbus_recvpacket() instead reports the required length, which can exceed hv->recv_buf, so copying bytes_recvd would read and write past the 16 KiB buffers. Gating on the success return keeps the copy bounded. The nonzero-return path is itself a malformed-message case and is now logged rather than silently skipped; channel recovery is not attempted. Rejected packets are reported via drm_err_ratelimited() rather than silently dropped, matching the CoCo-hardened pattern in hv_kvp_onchannelcallback().

In the Linux kernel, the following vulnerability has been resolved: ethtool: tsconfig: fix missing ethnl_ops_complete() tsconfig_prepare_data() calls ethnl_ops_begin(), we need to call ethnl_ops_complete() before returning the error.

In the Linux kernel, the following vulnerability has been resolved: xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit The struct pernet_operations docstring in include/net/net_namespace.h explicitly warns against blocking RCU primitives in .exit handlers: Exit methods using blocking RCU primitives, such as synchronize_rcu(), should be implemented via exit_batch. [...] Please, avoid synchronize_rcu() at all, where it's possible. Note that a combination of pre_exit() and exit() can be used, since a synchronize_rcu() is guaranteed between the calls. xfrm_policy_fini() violates this: it calls synchronize_rcu() before freeing the policy_bydst hash tables (so no RCU reader is mid- traversal at free time), but runs from xfrm_net_ops.exit -- once per namespace -- so a cleanup_net() of N namespaces pays N full RCU grace periods serially. Use the documented pre_exit/exit split. Move the policy flush (and the workqueue drains it depends on) into a new .pre_exit handler; xfrm_policy_fini() then runs in .exit and frees the hash tables after the synchronize_rcu_expedited() that cleanup_net() guarantees between the two phases. Providing O(1) RCU grace periods per batch instead of O(N). Observed on Linux 6.18 with a workload doing unshare(CLONE_NEWNET) at ~13/sec sustained: cleanup_net() and the netns_wq rescuer kthread both stuck in xfrm_policy_fini()'s synchronize_rcu(), >300k struct net accumulated in the cleanup queue, Percpu in /proc/meminfo climbed to 130+ GB on 256-CPU hosts, and memcg OOMs followed. setup_net and __put_net counts were balanced, ruling out a refcount leak.

In the Linux kernel, the following vulnerability has been resolved: pinctrl: meson: amlogic-a4: fix deadlock issue Accessing the pinconf-pins sysfs node may deadlock. pinconf_pins_show() holds pctldev->mutex, and the platform driver calls pinctrl_find_gpio_range_from_pin(), which tries to acquire the same mutex again, leading to a deadlock. Use pinctrl_find_gpio_range_from_pin_nolock() to fix this issue.

In the Linux kernel, the following vulnerability has been resolved: drm/xe/gsc: Fix double-free of managed BO in error path The error path in xe_gsc_init_post_hwconfig() explicitly frees a BO allocated with xe_managed_bo_create_pin_map() via xe_bo_unpin_map_no_vm(). Since the managed BO already has a devm cleanup action registered, this causes a double-free when devm unwinds during probe failure. Remove the explicit free and let devm handle it, consistent with all other xe_managed_bo_create_pin_map() callers. (cherry picked from commit 71d61e3e299a17139e47f980a4d6f425b2c59bf7)

In the Linux kernel, the following vulnerability has been resolved: userfaultfd: gate must_wait writability check on pte_present() userfaultfd_must_wait() and userfaultfd_huge_must_wait() read the PTE without taking the page table lock and then apply pte_write() / huge_pte_write() to it. Those accessors decode bits from the present encoding only; on a swap or migration entry they read the offset bits that happen to share the same position and return an undefined result. The intent of the check is "is this fault still WP-blocked?". A non-marker swap entry means the page is in transit -- the userfault context the original fault delivered against is no longer the same, and the swap-in or migration completion path will re-deliver a fresh fault if userspace still needs to handle it. Worst case under the current code the garbage write bit says "wait", and the thread stays asleep until a UFFDIO_WAKE that may never arrive. Gate the writability check on pte_present() so the lockless re-check only inspects present-PTE bits when the entry is actually present. The non-present, non-marker case returns "don't wait" and lets the fault path retry.

In the Linux kernel, the following vulnerability has been resolved: rust: block: fix GenDisk cleanup paths GenDiskBuilder::build() still has fallible work after __blk_mq_alloc_disk(), but its error path only recovers the foreign queue data. That leaks the temporary gendisk and request_queue until later teardown. If the caller moved the last Arc<TagSet<T>> into build(), the leaked queue can retain blk-mq state after the tag set is dropped. Fix the pre-registration failure path by dropping the temporary gendisk reference with put_disk() before recovering queue_data, so disk_release() can tear down the owned queue. Also pair GenDisk::drop() with put_disk() after del_gendisk(). Once a Rust GenDisk has been added with device_add_disk(), del_gendisk() only unregisters it; the final gendisk reference still has to be dropped to complete the release path.

In the Linux kernel, the following vulnerability has been resolved: bpf: Support for hardening against JIT spraying The BPF JIT allocator packs many small programs into larger executable allocations and reuses space within those allocations as programs are loaded and freed. When fresh code is written into space that a previous program occupied, an indirect jump into the new program can reuse a branch prediction left behind by the old one. Flush the indirect branch predictors before reusing JIT memory so that indirect jumps into a newly written program don't reuse predictions from an old program that occupied the same space. Introduce bpf_arch_pred_flush_enabled static key and bpf_arch_pred_flush static call for flushing the branch predictors on JIT memory reuse. Architectures that need a flush, can update it to a predictor flush function. By default, its a NOP and does not emit any CALL. Allocations larger than a pack are not covered by this flush. That is safe because cBPF programs (the unprivileged attack surface) are bounded well below a pack size. Issue a warning if this assumption is ever violated while the flush is active.

In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Enable IBPB flush on BPF JIT allocation Enable hardening against JIT spraying when Spectre-v2 mitigations are in use. Specifically, issue an IBPB flush on BPF JIT memory reuse. Skip enabling the IBPB flush if the BPF dispatcher is already using a retpoline sequence. This hardening applies only when BPF-JIT is in use. Guard the enabling under CONFIG_BPF_JIT so that bugs.c still builds with CONFIG_BPF_JIT=n.

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: correct drop logic for malformed AMPDU frames The previous commit aims to fix issue caused by malformed AMPDU frames. But the drop logic fails to deal with the first AMPDU packet paired with certain range of sequence number, and leads to unexpected packet drop. It is more likely to encounter this failure when there are busy traffic during rekey process and could lead to disconnection from the AP. Fix this by adding a initial state judgement and only reset status during pairwise rekey.

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: function: rndis: add length check for header Add a length check for the rndis header in rndis_rm_hdr, to ensure that MessageType, MessageLength, DataOffset, and DataLength fields are present before they are accessed.

In the Linux kernel, the following vulnerability has been resolved: iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error kxsd9_write_raw() takes a runtime PM reference with pm_runtime_get_sync() but returns -EINVAL directly when a scale with a non-zero integer part is requested, skipping the matching pm_runtime_put_autosuspend(). This leaks a runtime PM usage-counter reference on every such write, after which the device can no longer autosuspend. Set the error code and fall through to the existing put instead of returning early.

In the Linux kernel, the following vulnerability has been resolved: iio: adc: lpc32xx: Initialize completion before requesting IRQ In the report from Jaeyoung Chung: "lpc32xx_adc_probe() in drivers/iio/adc/lpc32xx_adc.c registers its interrupt handler with devm_request_irq() before it initializes st->completion with init_completion(). If an interrupt arrives after devm_request_irq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic. The probe path, in lpc32xx_adc_probe(): iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */ ... retval = devm_request_irq(&pdev->dev, irq, lpc32xx_adc_isr, 0, LPC32XXAD_NAME, st); /* register handler */ ... init_completion(&st->completion); /* initialize completion */ lpc32xx_adc_isr() calls complete(): complete(&st->completion); If the device raises an interrupt before init_completion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed task_list in swake_up_locked(). The zeroed task_list makes list_empty() return false, so swake_up_locked() dereferences a NULL list entry, triggering a KASAN wild-memory-access." Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving init_completion() above devm_request_irq().

In the Linux kernel, the following vulnerability has been resolved: iio: adc: ti-ads1119: fix PM reference leak in buffer preenable ads1119_triggered_buffer_preenable() resumes the device with pm_runtime_resume_and_get() before starting a conversion. If i2c_smbus_write_byte() fails, the function returns the error directly and leaves the runtime PM usage counter elevated. The matching postdisable callback is not called when preenable fails, so the reference is leaked and the device may remain runtime-active indefinitely. Store the I2C transfer result in ret and drop the runtime PM reference on failure before returning the error.

In the Linux kernel, the following vulnerability has been resolved: iio: buffer: hw-consumer: free scan_mask on buffer release The scan_mask lifetime changed in commit 9a2e1233d38c ("iio: buffer: hw-consumer: remove redundant scan_mask flexible array"). Before that change, the scan mask storage was embedded in struct hw_consumer_buffer, so iio_hw_buf_release() could free the whole allocation with a single kfree(hw_buf). That commit moved the scan mask to a separate bitmap_zalloc() allocation stored in buffer.scan_mask, but left iio_hw_buf_release() unchanged. Free the scan mask in iio_hw_buf_release() before freeing the buffer wrapper.

In the Linux kernel, the following vulnerability has been resolved: iio: chemical: scd30: Cleanup initializations and fix sign-extension bug Include linux/bitfield.h for FIELD_GET(). Create new macros for bit manipulation in combination with manual bit manipulation being replaced with FIELD_GET(). The current variable declaration and initializations are barely readable and use comma separations across multiple lines. Refactor the initializations so that mantissa and exp have separate declarations and sign gets initialized later. In addition (and due to the nature of the cleanup), fix a sign-extension bug where, float32 would get bitwise anded with ~BIT(31) (which is 0xFFFFFFFF7FFFFFFF) which corrupted the exponent.

In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: fix runtime PM leak on read error gp2ap002_read_raw() calls pm_runtime_get_sync() before reading the lux value, but if gp2ap002_get_lux() fails, it returns directly. This skips the pm_runtime_put_autosuspend() call at the "out" label, permanently leaking a runtime PM reference and preventing the device from autosuspending. Replace the direct return with a "goto out" to ensure the reference is properly dropped on the error path.

In the Linux kernel, the following vulnerability has been resolved: iio: pressure: mpl115: fix runtime PM leak on read error mpl115_read_raw() takes a runtime PM reference with pm_runtime_get_sync() before reading the processed pressure or raw temperature, but on the read error path it returns without calling pm_runtime_put_autosuspend(). Each failed read therefore leaks a runtime PM reference and prevents the device from autosuspending. Drop the reference before checking the return value so both the success and error paths are balanced.

In the Linux kernel, the following vulnerability has been resolved: iio: temperature: tmp006: use devm_iio_trigger_register tmp006_probe() allocates the DRDY trigger with devm_iio_trigger_alloc() but registers it with plain iio_trigger_register(). The driver has no .remove() callback, so on module unload the trigger stays in the global trigger list while its memory is freed by devm, leaving a dangling entry. Switch to devm_iio_trigger_register() so the registration is undone in the same devm scope as the allocation.

In the Linux kernel, the following vulnerability has been resolved: ALSA: usx2y: us144mkii: fix work UAF on disconnect tascam_disconnect() cancels capture_work and midi_in_work before usb_kill_anchored_urbs() kills the capture/MIDI-in URBs. Those URBs self-resubmit, and their completion handlers reschedule the work. A URB that completes in the small window between cancel_work_sync() and usb_kill_anchored_urbs() therefore re-arms the work after its only cancel. Nothing cancels it again before snd_card_free() frees the card-private tascam structure, so the work handler then runs on freed memory. Kill the anchored URBs before cancelling the work; once the work is cancelled no remaining URB can complete to re-arm it.

In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire: isight: bound the sample count to the packet payload isight_packet() takes the frame count from the device iso packet and checks it only against the device claimed iso length. count = be32_to_cpu(payload->sample_count); if (likely(count <= (length - 16) / 4)) isight_samples(isight, payload->samples, count); length is the iso header data_length. It can be up to 0xffff. So the gate allows a count up to about 16379. isight_samples() then copies count frames out of payload->samples into the PCM DMA buffer. payload->samples holds only 2 * MAX_FRAMES_PER_PACKET values. The device multiplexes two samples per frame. A count past MAX_FRAMES_PER_PACKET reads past the payload. A count past the buffer size writes past runtime->dma_area. The smallest PCM buffer is larger than MAX_FRAMES_PER_PACKET. Bounding the count to MAX_FRAMES_PER_PACKET keeps both the read and the write in range. A malicious or faulty Apple iSight on the FireWire bus reaches this during a normal capture. Add the MAX_FRAMES_PER_PACKET bound to the gate.

In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix uninitialised heap leak in snd_seq_event_dup() snd_seq_event_dup() copies an incoming event into a pool cell and, in the UMP-enabled build, clears the trailing cell->ump.raw.extra word that the memcpy() did not cover. The guard deciding whether to clear it compares the copied size against sizeof(cell->event): memcpy(&cell->ump, event, size); if (size < sizeof(cell->event)) cell->ump.raw.extra = 0; For a legacy (non-UMP) event, size == sizeof(struct snd_seq_event) == sizeof(cell->event), so the condition is false and the extra word keeps stale data. The cell pool is allocated with kvmalloc() (not zeroed) and cells are reused via a free list, so that word holds uninitialised heap or leftover event data. When such a cell is delivered to a UMP client (client->midi_version > 0) that set SNDRV_SEQ_FILTER_NO_CONVERT -- so the legacy event reaches it unconverted -- snd_seq_read() reads it out as the larger struct snd_seq_ump_event and copies the stale word to user space, a 4-byte kernel heap infoleak to an unprivileged /dev/snd/seq client. Compare against sizeof(cell->ump) instead, so the trailing word is zeroed for every event shorter than the UMP cell.

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: avoid kobject path lookup in DualSense match The DualSense jack-detection input handler verifies that a matching input device belongs to the same physical controller by building kobject path strings for both the input device and the USB audio device, then comparing the path prefix. This was observed when a weak physical connection caused the controller to rapidly disconnect and reconnect. During that repeated hotplug, snd_dualsense_ih_match() can run while the controller's USB device is being disconnected. kobject_get_path() walks ancestor kobjects and dereferences their names; if the USB device kobject name is no longer valid, this can fault in strlen(): RIP: 0010:strlen+0x10/0x30 Call Trace: kobject_get_path+0x34/0x150 snd_dualsense_ih_match+0x49/0xd0 [snd_usb_audio] input_register_device+0x566/0x6a0 ps_probe+0xb89/0x1590 [hid_playstation] The same ownership check can be done without building kobject path strings. The input device is parented below the HID device, USB interface and USB device, so walking the input device parent chain and comparing against the mixer USB device preserves the check without dereferencing kobject names during disconnect.

In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Latch disable_idle_d3 per device When disable_idle_d3 was introduced in vfio-pci, it directly manipulated the device power state with pci_set_power_state(). There were no refcounts to maintain or balanced operations, we could unconditionally bring the device to D0 and conditionally move it to D3hot. Therefore the module parameter was made writable. Later, in commit c61302aa48f7 ("vfio/pci: Move module parameters to vfio_pci.c"), as part of the vfio-pci-core split, the writable aspect of the module parameter was nullified. The parameter value could still be changed through sysfs, but the vfio-pci driver latched the values into vfio-pci-core globals at module init. Loading the vfio-pci module, or unloading and reloading, with non-default or different values could change the globals relative to existing devices bound to vfio-pci variant drivers. Runtime PM was introduced in commit 7ab5e10eda02 ("vfio/pci: Move the unused device into low power state with runtime PM"), which marks the point where power states became refcounted. PM get and put operations need to be balanced, but the same module operations noted above can change the global variables relative to those devices already bound to vfio-pci variant drivers. This introduces a window where PM operations can now become unbalanced. To resolve this with a narrow footprint for stable backports, the disable_idle_d3 flag is latched into the vfio_pci_core_device at the time of initialization, such that the device always operates with a consistent value. NB. vfio_pci_dev_set_try_reset() now unconditionally raises the runtime PM usage count around bus reset to account for disable_idle_d3 becoming a per-device rather than global flag. When this flag is set, the additional get/put pair is harmless and allows continued use of the shared vfio_pci_dev_set_pm_runtime_get() helper.

In the Linux kernel, the following vulnerability has been resolved: vfio: Remove device debugfs before releasing devres VFIO device debugfs files created with debugfs_create_devm_seqfile() store a devres allocated debugfs_devm_entry as inode private data. vfio_unregister_group_dev() currently calls vfio_device_del() before vfio_device_debugfs_exit(), but device_del() releases devres. This can leave debugfs entries visible with stale inode private data while unregister waits for userspace references to drain. Remove the per-device debugfs tree before vfio_device_del(). The debugfs view is diagnostic only, so losing it at the start of unregister is preferable to preserving entries whose backing storage may already have been released. Complete the teardown by clearing the per-device debugfs root after removal. This matches the global debugfs root cleanup and prevents future users from mistaking a removed dentry for a live debugfs tree during the remainder of unregister.

In the Linux kernel, the following vulnerability has been resolved: vfio/mlx5: Fix racy bitfields and tighten struct layout Bitfield operations are not atomic, they use a read-modify-write pattern, therefore we should be careful not to pack bitfields that can be concurrently updated into the same storage unit. This split takes a binary approach: flags that are only modified pre/post open/close remain bitfields, flags modified from user action, including actions that reach across to another device (ex. reset) use dedicated storage units. Note mlx5_vhca_page_tracker.status is relocated to fill the alignment hole this split exposes. Bitfield justifications: migrate_cap: written only in mlx5vf_cmd_set_migratable() at probe chunk_mode: written only in mlx5vf_cmd_set_migratable() at probe mig_state_cap: written only in mlx5vf_cmd_set_migratable() at probe Dedicated storage units: mdev_detach: written in the VF attach/detach event notifier mlx5fv_vf_event() at runtime log_active: written in mlx5vf_start_page_tracker()/ mlx5vf_stop_page_tracker() during runtime dirty tracking deferred_reset: written in mlx5vf_state_mutex_unlock()/ mlx5vf_pci_aer_reset_done() during runtime reset handling is_err: set by tracker error handling and dirty-log polling at runtime object_changed: set by tracker event handling and cleared by dirty-log polling at runtime

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free on registration failure Make sure to release the sibling interfaces in case controller registration fails to avoid use-after-free and double-free when they are eventually disconnected. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free on marvell probe failure Make sure to stop any TX URBs submitted during Marvell OOB wakeup configuration on later probe failures to avoid use-after-free in the completion callback. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths.

In the Linux kernel, the following vulnerability has been resolved: rust_binder: clear freeze listener on node removal Generally userspace is supposed to explicitly clear freeze listeners before they drop the refcount on the node ref to zero, but there's nothing forcing that. Currently, in this scenario the freeze listener remains in the freeze_listeners rbtree and in the remote node's freeze listener list, even though the ref for which the listener is registered is gone. This could potentially lead to a memory leak due to a refcount cycle. Thus, remove the freeze listener in this scenario.

In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix sleep in atomic context in xhci_free_streams() When a USB device with active stream endpoints is disconnected, xhci_free_streams() is called from the hub_event workqueue to free the stream resources. It calls xhci_free_stream_info() while holding xhci->lock with irqs disabled. xhci_free_stream_info() invokes xhci_free_stream_ctx(), which calls dma_free_coherent() for large stream context arrays. dma_free_coherent() can sleep (e.g. via vunmap), triggering a BUG when called from atomic context. Call trace: dma_free_attrs+0x174/0x220 xhci_free_stream_info+0xd0/0x11c xhci_free_streams+0x278/0x37c usb_free_streams+0x98/0xc0 usb_unbind_interface+0x1b8/0x2f8 device_release_driver_internal+0x1d4/0x2cc device_release_driver+0x18/0x28 bus_remove_device+0x160/0x1a4 device_del+0x1ec/0x350 usb_disable_device+0x98/0x214 usb_disconnect+0xf0/0x35c hub_event+0xab4/0x19ec process_one_work+0x278/0x63c Fix this by saving the stream_info pointers and clearing the ep references under the lock, then calling xhci_free_stream_info() outside the lock where sleeping is allowed.

In the Linux kernel, the following vulnerability has been resolved: xhci: sideband: fix ring sg table pages leak xhci_ring_to_sgtable() allocates a temporary pages array and uses it to build the returned sg_table with sg_alloc_table_from_pages(). The error paths free the pages array, but the success path returns the sg_table without freeing it. This leaks the temporary array every time a sideband client gets an endpoint or event ring buffer. Free the pages array after sg_alloc_table_from_pages() succeeds. The returned sg_table has its own scatterlist entries and does not depend on the temporary array after construction.

In the Linux kernel, the following vulnerability has been resolved: PCI: altera: Fix resource leaks on probe failure The chained IRQ handler is set during probe, but is only removed during the driver remove(). If pci_host_probe() fails, the handler and INTx IRQ domain remain set even though the devm-managed host bridge storage containing struct altera_pcie will be released, leaving the handler with a stale data pointer. Interrupts are also enabled before pci_host_probe() is called. If probe fails after that point, the controller interrupt source should be disabled before the chained handler and INTx domain are removed. So set the chained handler only after the INTx domain has been created. Disable controller interrupts during IRQ teardown, and tear the IRQ setup down if pci_host_probe() fails. [mani: commit log]

In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Fix IRQ domain leak when port fails to enable When mtk_pcie_enable_port() fails, mtk_pcie_port_free() removes the port from pcie->ports and frees the port structure. However, the IRQ domains set up earlier by mtk_pcie_init_irq_domain() are never freed. Fix this by refactoring mtk_pcie_irq_teardown() into a per-port helper, mtk_pcie_irq_teardown_port(), and calling it from mtk_pcie_setup() when mtk_pcie_enable_port() fails. Since the IRQ teardown must only happen in the probe error path (during resume, child devices may have active MSI mappings and the NOIRQ context prohibits sleeping locks), mtk_pcie_enable_port() is changed to return an error code so callers can distinguish the two paths and act accordingly. This issue was reported by Sashiko while reviewing the EcoNet EN7528 SoC support series.

In the Linux kernel, the following vulnerability has been resolved: mm/damon/ops-common: handle extreme intervals in damon_hot_score() Fix three issues in damon_hot_score() that comes from wrong handling of extreme (zero or too high) monitoring intervals user setup. When the user sets sampling interval zero, damon_max_nr_accesses(), which is called from damon_hot_score(), causes a divide-by-zero. Needless to say, it is a problem. When the user sets the aggregation interval zero, the function returns zero. It is wrong, since the real maximum nr_acceses in the setup should be one. Worse yet, it can cause another divide-by-zero from its caller, damon_hot_score(), since it uses damon_max_nr_accesses() return value as a denominator. When the user sets the aggregation interval very high, damon_hot_score() could return a value out of [0, DAMOS_MAX_SCORE] range. Since the return value is used as an index to the regions_score_histogram array, which is DAMOS_MAX_SCORE+1 size, it causes out of bounds array access. The issues can be relatively easily reproduced like below. The sysfs write permission is required, though. # ./damo start --damos_action lru_prio --damos_quota_space 100M \ --damos_quota_interval 1s # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/monitoring_attrs/intervals/sample_us # echo 0 > contexts/0/monitoring_attrs/intervals/aggr_us # echo commit > state # dmesg [...] [ 131.329762] Oops: divide error: 0000 [#1] SMP NOPTI [...] [ 131.336089] RIP: 0010:damon_hot_score+0x27/0xd0 [...] Fix the divide-by-zero intervals problems by explicitly handling the zero intervals in damon_max_nr_accesses(). Fix the out-of-bound array access by applying [0, DAMOS_MAX_SCORE] bounds before returning from damon_hot_score(). The issue was discovered [1] by Sashiko.

In the Linux kernel, the following vulnerability has been resolved: USB: chaoskey: Fix slab-use-after-free in chaoskey_release() The chaoskey driver has a use-after-free bug in its release routine. If the user closes the device file after the USB device has been unplugged, a debugging log statement will try to access the usb_interface structure after it has been deallocated: BUG: KASAN: slab-use-after-free in dev_driver_string (drivers/base/core.c:2406) Read of size 8 at addr ffff888168e8a0b8 by task chaoskey_raw_re/10106 Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) dev_driver_string (drivers/base/core.c:2406) __dynamic_dev_dbg (lib/dynamic_debug.c:906) chaoskey_release (drivers/usb/misc/chaoskey.c:323) __fput (fs/file_table.c:510) fput_close_sync (fs/file_table.c:615) __x64_sys_close (fs/open.c:1507 fs/open.c:1492 fs/open.c:1492) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The driver's last reference to the interface structure is dropped in the chaoskey_free() routine, so the code must not use the interface -- even in a debugging statement -- after that routine returns. (Exception: If we know that another reference is held by someone else, such as the device core while the disconnect routine runs, there's no problem. Thanks to Johan Hovold for pointing this out.) Since the bad access is part of an unimportant debugging statement, we can fix the problem simply by removing the whole statement.

In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: run gadget disconnect from sleepable suspend context dwc3_gadget_suspend() takes dwc->lock with IRQs disabled and then calls dwc3_disconnect_gadget(). For async callbacks that helper only uses plain spin_unlock()/spin_lock(), so the gadget ->disconnect() callback still runs with IRQs disabled and any sleepable callback trips Lockdep. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the dwc3_gadget_suspend() -> dwc3_disconnect_gadget() -> gadget_driver->disconnect() chain, and Lockdep reported: BUG: sleeping function called from invalid context gadget_disconnect+0x21/0x39 [vuln_msv] dwc3_gadget_suspend.constprop.0+0x2b/0x42 [vuln_msv] Keep the disconnect callback selection in one common helper, but add a sleepable suspend-side wrapper which snapshots the callback under dwc->lock and then runs it after spin_unlock_irqrestore(). The regular event path still uses the existing spin_unlock()/spin_lock() window.

Uninitialized stack memory use in the Linux kernel HFS and HFS+ filesystem drivers allows a local user to crash the kernel by mounting a crafted filesystem image. Two early-exit paths in `hfs_bnode_read()` - an invalid offset check and a corrected-to-zero length - skip the buffer write, while downstream callers such as `hfs_bnode_read_u16()` and `hfs_bnode_read_u8()` consume the uninitialized stack buffer unconditionally, producing KMSAN uninit-value reports and risking kernel panics. Patches are available across multiple stable kernel branches; no public exploit exists and EPSS is very low at 0.22%.