Unauthenticated Bluetooth Low Energy connections to Creative Sound Blaster Katana are accepted without prior pairing, allowing an attacker within Bluetooth range to connect and potentially affect integrity while confidentiality and availability remain unaffected. The CVSS 4.3 score reflects adjacent access, low complexity, no privileges or user interaction, and only low integrity impact; physical proximity is the main limiting factor. No public exploit code or CISA KEV confirmation is present in the supplied data, and the sources do not specify the commands or data exposed after connection.
Authenticated users who can submit a configdrive to OpenStack Ironic can cause resource exhaustion by supplying highly compressed data that expands to a very large uncompressed size, reducing availability of the provisioning service. Ironic through 39.0.1 is affected, and the issue is scored 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L), so impact is limited to availability and requires provisioning-level access. No public exploit code or confirmed active exploitation was identified in the available data.
SMTP command injection in Zimbra Collaboration Suite 10.1.16 and 10.1.20 allows an authenticated, low-privileged account holder to smuggle attacker-chosen recipients, headers and body content into mail handled by the data-source testing feature. The attacker must hold valid credentials for an ordinary account that has account options enabled, then inject CR/LF sequences into the emailAddress field of a JSON SOAP request; after the preliminary POP3 or IMAP login succeeds, the injected SMTP commands are sent to the selected SMTP service, and delivery occurs only if that service accepts the pipelined transaction. Impact is limited to integrity (CVSS 4.3, C:N/I:L/A:N) with no confidentiality or availability effect and no victim interaction required; no public exploit was identified at time of analysis, and the vuln.today decision label is this_month rather than an emergency.
LangGraph CLI versions 0.4.15 through 0.4.31 disclose the short-lived LangSmith registry push token in verbose output: `langgraph deploy --verbose` builds the image locally, then runs `docker login --password-stdin` with the token on stdin, and the CLI's subprocess helper echoes command input when verbose is enabled. Anyone able to read the retained output before the token's maximum 12-hour lifetime expires can pull the deployment's images or push new images into that deployment's image repository, though the token alone cannot update a deployment to run a pushed image (that requires a LangSmith API key with access to the deployment). Deployments run without `--verbose` and remote image builds never print the token; no public exploit code was identified at time of analysis, and exploitation requires a specific chain of local Docker use, retained verbose logs, and retrieval within the token window.
Subsite administrators in WordPress Multisite deployments running Essential Addons for Elementor before 6.8.7 can alter the login-approval and login state of user accounts belonging to other sites on the network because the plugin checks only a site-level capability rather than verifying authority over the targeted account. The issue requires the login-approval feature to be in use and administrator access on at least one subsite; single-site WordPress installations are not affected. It is assessed as a low-priority authorization flaw, with no public exploit identified at time of analysis.
Sites running the Popup Builder WordPress plugin before version 4.4.6 expose a maintenance routine that trashes popup content and is reachable through unauthenticated requests, with no authorization check guarding it (CWE-862). Remote attackers can therefore move affected popups into the Trash and overwrite their stored preview data, an integrity-only impact with no confidentiality or availability loss and no code execution. Exploitation is rated high complexity because the trash routine's trigger conditions are not fully under the attacker's control, no public exploit has been identified at time of analysis, and CISA SSVC records no known exploitation with automatable set to no, so the current decision signal is to monitor rather than act urgently.
Out-of-bounds write in the Zephyr ADXL345 RTIO streaming path (drivers/sensor/adi/adxl345/adxl345_stream.c) affects builds from 4.0.0 through 4.4.2 that enable CONFIG_ADXL345_STREAM on a board with an interrupt-wired ADXL345. The completion callback clamps the reported read length to the buffer actually granted by rtio_sqe_rx_buf(), but then queues one 6-byte bus read per hardware FIFO entry at consecutive offsets bounded by the device-reported entry count, so a truncated allocation causes up to 186 bytes written past the end of the block-pool buffer; a companion defect that failed to reset fifo_total_bytes at batch start can carry a stale offset into the next batch. Exposure is strictly local with high attack complexity and low privileges (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L, score 3.6); the written data is accelerometer sample content at the allocation tail, so the realistic outcome is corruption of neighbouring RTIO consumers' buffers or a crash rather than a controllable primitive. No public exploit code has been identified at time of analysis, the issue is not in CISA KEV, and vendor fixes are merged on main and both release branches with a projected fixed release of 4.5.0.
Stored cross-site scripting in the Speed Optimizer WordPress plugin before 7.8.5 lets a high-privilege user, such as an administrator, inject script into plugin settings that is then written unescaped into the <head> of front-end pages. The flaw matters mainly in deployments where the unfiltered_html capability is stripped - classically a multisite network - so that a site admin who could not otherwise embed scripts can still persist one; a victim must load an affected front-end page for the payload to fire. Severity is low (CVSS 3.5, PR:H/UI:R): there is no unauthenticated path, no public exploit identified at time of analysis, no CISA KEV listing, and CISA SSVC records exploitation as none with partial technical impact, so this is a monitor-level item rather than an emergency.
Stored HTML injection in the Essential Addons for Elementor WordPress plugin (versions before 6.8.7) allows authenticated users with the author role or higher to place iframe and form elements into published pages, because some widgets pass their HTML tag setting into markup without validating it. Impact is limited: the injection is confined to iframe and form elements rather than arbitrary script execution, no public exploit code was identified at time of analysis, and CISA's SSVC assessment rates exploitation as none and technical impact as partial, giving a priority decision of monitor. The CVSS base score is 3.5, reflecting low confidentiality and integrity impact with no availability effect.
Denial of service in Python filelock 3.20.4 through 4.2.0 on Windows: ReadWriteLock and AsyncReadWriteLock hand the lock database path straight to sqlite3.connect, so SQLite acts on the `<database>-wal`, `<database>-journal` and `<database>-shm` side files that any local account able to create files in the database's directory can plant beside it. An undeletable, planted `-wal` makes every read_lock() and write_lock() fail at once with sqlite3.OperationalError: disk I/O error regardless of the timeout value, because that error is not converted into Timeout, and it persists until the planting account removes the file - a condition that applies in C:\Windows\Temp and C:\Users\Public, where users may create files but not delete other accounts'. The scored impact is availability only (CVSS 3.1 3.3, AV:L/AC:L/PR:L, C:N/I:N/A:L); a harder secondary variant can make SQLite treat a planted journal as hot, replay it and delete a file of the other account's choosing (assessed AC:H/I:L, 3.6), and while the GitHub advisory ships a maintainer reproducer that was run on a Windows 11 VM, no exploitation in the wild has been reported and the vuln.today decision label is monitor.
Fallow 2.68.0 through 3.33.1, when run on an untrusted repository, can be induced to read Jest `projects` entries (and, from 3.33.1, Vitest `test.projects` entries, Vitest inline-project `extends` paths, and symlinked script `--config` paths) that resolve outside the project root via absolute paths, `..` segments, dot-prefixed wildcard globs, or in-root symlinks to parent directories. The outside files are parsed as test-runner configuration only to credit dependencies, setup files, and JSX import sources, so the attacker's payoff is altered unused-dependency and unused-file findings rather than disclosure of file contents - nothing is printed or sent over the network. Exploitation requires a user, CI job, or agent to execute Fallow against the hostile repository (AV:L, UI:R, unauthenticated per the CVSS vector), and no public exploit code was identified at time of analysis; priority signals are consistent with low, non-urgent risk and monitoring.
DNS response spoofing in Twisted's twisted.names client and resolver (all versions through 26.4.0) arises because twisted.names.dns.DNSDatagramProtocol accepts a UDP DNS answer solely on a matching 16-bit transaction ID and never verifies that the datagram originated from the server the query was sent to. Attackers who can deliver a UDP packet to the resolver's listening port with the right transaction ID can inject a forged answer and redirect hostname resolution, enabling mail interception via spoofed MX/A records, server-side request forgery, or man-in-the-middle positioning; on-path attackers or those sharing a broadcast domain/NAT with the resolver or the real DNS server face essentially no barrier, while the standard client.Resolver's per-query random source-port rotation raises off-path effort to roughly 32 bits of combined entropy within the query timeout. Applications that directly construct and reuse one DNSDatagramProtocol instance across multiple queries are limited to the 16-bit transaction-ID space after the first query, which is the weakest case; the advisory includes a public PoC reference (not verified as working exploit code), there is no KEV listing or active-exploitation signal, and the assessed severity is low (CVSS 3.1, AV:A/AC:H) with a monitor priority.
The LiteSpeed Cache plugin for WordPress before 7.9.2 allows an authenticated Subscriber-level user to dismiss administrative notices that the plugin explicitly marks as non-dismissible, including a warning that sensitive files may be publicly accessible. The dismissal handler lacks a capability check and relies on a nonce that is not tied to the specific notice, so the weakness only materialises on sites in certain configurations - most notably those where low-privileged accounts such as Subscribers exist or can self-register. Impact is limited to suppressing the display of a warning; the flaw does not by itself expose files, grant data access, or allow code execution, and severity is low (CVSS 3.1, AC:H, I:L). No public exploit code has been identified at time of analysis, CISA SSVC records no exploitation, and the priority decision is monitor.
On Windows, the Python filelock library (3.22.0 through 4.2.0) reads, renames and deletes soft-lock marker files by path, so a second local account that holds an unanswered Level 1 oplock on a marker makes every `acquire()` wait inside the underlying file open; `timeout`, `blocking=False` and `cancel_check` are only consulted after that wait returns, and a `timeout=1` call was recorded returning `Timeout` after 10.02 s. A stale marker under the same oplock is never broken, so no process acquires the lock until the oplock holder answers or closes its handle; availability is the only impact, mutual exclusion is never broken and no other file is touched. Exploitation is narrow: it requires a Windows host, a second logged-on account granted read access to newly created files by the lock directory's inheritable ACL, and a marker with no open handle at the moment the oplock is requested, a state the attacker cannot force. CVSS 3.1 scores 2.5 (AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L); no CISA KEV entry or active exploitation is reported, and the advisory ships reproduction scripts rather than verified exploit code. Fixed in 4.2.1.
An authorization bypass in Chatwoot before 4.17.0 lets an authenticated agent bot use a foreign account's contact-inbox source_id against the conversations create endpoint to create or retrieve conversations and post messages to another account's contacts. Exploitation requires a valid agent bot API access token plus prior knowledge of a valid source_id belonging to a different account, so impact is bounded to cross-account conversation and message manipulation on multi-tenant or shared instances, with no availability impact. The vendor has released a fix in Chatwoot 4.17.0; no public exploit code, CISA KEV entry, or confirmed active exploitation was identified at time of analysis, and the aggregated priority decision is monitor.
Cross-site scripting in serialize-javascript 7.0.1 before 7.1.3 occurs when a serialized function's attacker-influenced source text ends in a bare `</script`, letting surrounding output and a later serialized value complete the tag and inject live markup such as an `img onerror` handler. The flaw only affects applications that serialize attacker-controlled function values via a spoofed `toString()` and embed the result inside an HTML `<script>` element; ordinary functions and non-function values are escaped correctly. The vendor fixed this in 7.1.3, no KEV listing or confirmed active exploitation is reported, the advisory's demonstration payload is not verified as working exploit code, and the decision label is monitor.
SSRF in Signal K Server's App Store icon fetcher allows anyone who can publish an npm package carrying Signal K keywords to make every server that browses the App Store issue HTTP requests to loopback addresses, hosts on the vessel network, and cloud metadata endpoints. Affected builds are 2.28.0-beta.2 through 2.33.0; because only responses with an image/* content type are stored and returned to the admin UI, retrievable data is limited to content that can pass as an image. The issue is vendor-confirmed and fixed in 2.34.0 (CVSS 4.0 score 2.3; independent CVSS 3.1 vector AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N), carries a monitor decision label, is not in CISA KEV, and while the advisory includes a reproduction, no verified working exploit code is confirmed.
Protocol-relative URL injection in i18next-http-backend before 4.0.3 lets an attacker who controls an i18next namespace value redirect translation fetches to an attacker-chosen origin when the loadPath/addPath template places {{ns}} directly after a leading slash. The per-value validation added for the earlier GHSA-xvq9-wjp8-hwqf fix rejects '//evil.example' but still permits a single leading '/', which the template's own '/' turns into '//evil.example/en.json' - a URL browsers resolve off-origin, yielding translation content injection and, where translations are rendered as HTML, cross-site scripting. Exploitation requires the non-default template, attacker-controlled namespace input (applications usually set namespaces in code), and a browser context; Node is not affected, the default '/locales/{{lng}}/{{ns}}.json' template is not affected, and the issue is not known to be exploited in the wild. A minimal proof-of-concept is published in the advisory and was re-verified against 4.0.2, and the release 4.0.3 contains the fix.
Cross-site scripting in serialize-javascript before 7.1.3 lets an attacker who controls the source text of a serialized function (in practice via a spoofed toString()) break out of an HTML <script> element and introduce live markup, but only in a narrow configuration: the function body must end exactly at a bare '</script' with no trailing delimiter character, the surrounding serialized output must then supply the delimiter (for example the newline emitted by the 'space' pretty-print option), and a later serialized value must supply the closing '>' plus injected markup. The assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N, a scope-changing low-impact injection that requires a victim to load the affected page; ordinary functions (which end in '}') and non-function values, including strings containing '</script', are escaped correctly and are not affected. There is no CISA KEV entry and no confirmed active exploitation; a public reproducer is documented in the upstream advisory, and the vendor-released fix is version 7.1.3.
Cross-site scripting in the PHP-based HospitalManagement project (gedelumbung) lets remote, unauthenticated attackers inject script through the contact form fields nama, email, alamat, telepon and pesan, which the kirim function in application/modules/web/controllers/contact.php renders without adequate output encoding. The payload only fires when a victim - realistically an operator or administrator reviewing submitted contact entries - later views the affected page (CVSS 4.0 UI:P; our assessed 3.1 vector AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N), so impact is confined to the low-integrity script execution in that browser context rather than server compromise. Severity is low (CVSS 4.0 base 2.1, rated E:P) and the priority label is monitor; there is no CISA KEV entry, but the vendor report states the exploit has been publicly disclosed and exploit maturity is scored Proof-of-Concept, so a public PoC reference exists that has not been independently verified as working exploit code.
File overwrite in VLC for Android before 3.7.2 lets a co-installed app with no permissions send a crafted VIEW intent to the exported StartActivity and have VLC write attacker-chosen content under an attacker-chosen name in the shared Download directory. The flaw is local-only and requires the attacker app to spoof the com.fsck.k9.attachmentprovider or gmail-ls authority; overwriting other apps' files additionally depends on VLC holding All files access, which is non-default. Impact is limited to integrity, no public exploit was identified at time of analysis, and the vendor fixed it in 3.7.2.
Crash of Qt-based client applications can be triggered by a malicious or compromised HTTP/2 server through a use-after-free flaw in the HTTP/2 client support of the Qt Network module's QNetworkAccessManager. Only applications that actually open an outbound HTTP/2 session to an attacker-controlled or compromised endpoint are exposed - the hostile server delivers the triggering traffic, and the client must initiate that connection - while authentication is not bypassed and no code execution, data disclosure, or integrity impact is described. All signals converge on LOW real-world priority: the vendor rates it CVSS 4.0 at 2.1, the independent assessment scores it CVSS 3.1 at 3.1 (AV:N/AC:H/PR:N/UI:R/A:L), no public exploit code is identified at time of analysis, there is no CISA KEV listing, and the priority decision is monitor.
OS command injection in the web management interface of the D-Link DAP1160L (hardware revision A1, firmware FW101WWb04) lets a remote attacker with a low-privilege authenticated session to the device's web UI inject shell metacharacters through the /htdocs/web/diagnostic.php endpoint and have them executed by the underlying operating system, yielding full confidentiality, integrity and availability impact (CVSS 3.1 base 8.8, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Exploitation requires network reachability to the management interface plus valid low-privileged credentials; it is not exploitable by anonymous attackers, and devices whose admin interface is confined to a trusted LAN or management VLAN are correspondingly less exposed. The flaw is not in CISA KEV, EPSS is low at 0.84% (58th percentile), and a public PoC reference exists in a GitHub writeup; it is not verified as working exploit code.
In the Linux kernel, the following vulnerability has been resolved: workqueue: Fix NULL current_pwq deref in chained work check current_wq_worker() only tells us that %current is a kworker. It does not guarantee that the worker is currently executing a work item, as worker->current_pwq is populated only while process_one_work() is running the work function. is_chained_work() can be reached while queueing on a draining or destroying workqueue. If a kworker outside work-item execution reaches that path, current_wq_worker() returns a worker but worker->current_pwq is NULL, and the chained-work test can fault before it emits the intended warning. Guard the chained-work test with worker->current_pwq. A kworker without current_pwq is not executing work on the target workqueue, so the helper should return false and let the draining/destroying warning fire.
In the Linux kernel, the following vulnerability has been resolved: KEYS: Fix add_key() race with keyring restriction __key_create_or_update() snapshots keyring->restrict_link before taking the destination keyring's semaphore. keyring_restrict() installs a restriction while holding that semaphore. This allows a writer to observe no restriction, wait for the keyring owner to install a reject-all restriction and return successfully, and then link a key using the stale NULL snapshot. The writer only needs write permission on the destination keyring. Move the restrict_link read after __key_link_lock() and __key_link_begin(). The read and the subsequent restriction check are then serialized with restriction installation by keyring->sem. The race was reproduced on v7.2.8 in 19 executions where restriction installation returned before the link completed. All 19 linked the key despite the reject-all restriction. With this change, 312 executions reached the same ordering and every add_key() call failed with -EPERM. The issue was found by manual concurrency analysis assisted by AI-based analysis and independently verified with a QEMU reproducer and kernel instrumentation.
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix IRQ injection with SIGP Stop and Store Status When __inject_sigp_stop() is called for a Stop and Store Status operation, if the vCPU is running, the interrupt is marked as pending and the status is stored by the thread performing the KVM_RUN IOCTL. If the vCPU is already stopped, the status is stored immediately. Storing the status means writing into userspace, which might fault, and __inject_sigp_stop() is called from do_inject_vcpu() which in turn is always called holding a spinlock, which is obviously an issue. Fix this by returning -EWOULDBLOCK from __inject_sigp_stop(), and adding a bool flag to indicate whether a store status is needed. The callers of do_inject_vcpu() are modified to pass the pointer to the bool flag; whenever a Store Status operation is needed, the callers can now perform it outside the spinlock. Opportunistically refactor kvm_s390_set_irq_state() to use scoped_guard() and __free(). [ Added Fixes tag while picking -- Claudio ]
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix self-redirect copied_seq double-counting When a BPF stream_verdict program redirects an skb back to the same socket (self-redirect with BPF_F_INGRESS), sk_psock_verdict_apply() calls tcp_eat_skb() which advances tcp_sk->copied_seq. However, the skb is then delivered to the socket's psock ingress queue and later read by tcp_bpf_recvmsg_parser(), which also advances copied_seq via the copied_from_self accounting path. This double-counting causes copied_seq to advance by 2x the actual data length, triggering: TCP recvmsg seq # bug 2: copied BF2E806, seq BF2E7FD, \ rcvnxt BF2E806, fl 0 WARNING: net/ipv4/tcp.c:2745 at tcp_recvmsg_locked+0x72b/0x2640 Call Trace: tcp_recvmsg+0x10a/0x500 sock_recvmsg+0x168/0x1d0 __sys_recvfrom+0x19a/0x2a0 __x64_sys_recvfrom+0xe4/0x1f0 do_syscall_64+0xf7/0x530 entry_SYSCALL_64_after_hwframe+0x77/0x7f cleanup rbuf bug: copied BF2E806 seq BF2E806 rcvnxt BF2E806 WARNING: net/ipv4/tcp.c:1609 at tcp_cleanup_rbuf+0xf2/0x1c0 Call Trace: tcp_recvmsg_locked+0x8d1/0x2640 tcp_recvmsg+0x10a/0x500 sock_recvmsg+0x168/0x1d0 __sys_recvfrom+0x19a/0x2a0 __x64_sys_recvfrom+0xe4/0x1f0 do_syscall_64+0xf7/0x530 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by converting self-redirect verdict to __SK_PASS at the beginning of sk_psock_verdict_apply(). This bypasses the __SK_REDIRECT case entirely (which calls sk_psock_eat_skb), letting the __SK_PASS path queue the skb to the psock ingress queue. The data is then read via tcp_bpf_recvmsg_parser(), which advances copied_seq exactly once through copied_from_self. Cross-socket redirects continue through __SK_REDIRECT with sk_psock_eat_skb() unchanged.
In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Add range checks for dec_output_info If the driver's dec_output_info contains invalid data the driver can write in invalid memory. Add a range check for that. This fixes this smatch error: drivers/media/platform/chips-media/wave5/wave5-vpuapi.c:588 wave5_vpu_dec_get_output_info() error: buffer overflow 'inst->frame_buf' 64 <= 127
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Unmask interrupts only when ACTIVE is true There is a small race window between intel_rps_boost() reading a stale ACTIVE state and queuing rps->work, where ACTIVE may be changed via asynchronous calls triggered by wakeref drop. This means that rps_work() could be triggered after the GT has been parked, so unmasking RPS PM interrupts would happen without holding PM wakelock. This sequence of events may be observed during live_rc6_ctx_wa() selftest: 1) live_rc6_ctx_wa() -> intel_engine_pm_put() -> wakeref_put() ASYNC1) wakeref_put() callback -> __engine_park() -> intel_gt_pm_put_async() -> intel_gt_pm_put_async_untracked() -> intel_wakeref_put_async() ASYNC2) wakeref_put_async() callback -> __gt_park() -> intel_rps_park() -> intel_rps_clear_active() [clear ACTIVE] WITH INTERRUPTS: -> rps_disable_interrupts() -> cancel_work_sync(rps->work) -> rps_reset_interrupts() [rps->pm_iir = 0] WITHOUT INTERRUPTS (TIMER mode): -> rps_stop_timer() -> cancel_work_sync(rps->work) 2) live_rc6_ctx_wa() -> intel_gt_wait_for_idle() -> intel_gt_retire_requests_timeout() -> dma_fence_wait_timeout() -> ops->wait() [i915_fence_wait()] -> i915_request_wait_timeout() -> intel_rps_boost() -> intel_rps_is_active() [check ACTIVE] [OPEN RACE WINDOW] -> queue_work(rps->work) -> retire_requests() -> i915_request_retire() -> intel_rps_dec_waiters() [from 1 to 0] If ASYNC1 and ASYNC2 would execute during [OPEN RACE WINDOW], then: 3) rps_work() executes from the workqueue and may satisfy "(!pm_iir && !client_boost)" test (in TIMER mode rps->pm_iir is zeroed by an earlier rps_work() call or never gets a new value after previous intel_rps_unpark() event), so it jumps to "out" label, bypassing intel_rps_is_active() guard and executes gen6_gt_pm_unmask_irq(); 4) GT is parked and runtime PM wakelock is dropped, so only a raw reference in __gt_park() -> intel_display_power_put_async() remains for 100ms, then the MMIO write in gen6_gt_pm_unmask_irq() detects missing wakelock via assert_rpm_wakelock_held() and emits "RPM wakelock ref not held during HW access" tainting kernel. Commit 3e7abf814193 ("drm/i915: Extract GT render power state management") dropped the "if (rps->interrupts_enabled)" guard that gen6_pm_rps_work() had around this unmask in i915_irq.c. INTEL_RPS_ACTIVE brackets the same window, since it is set in intel_rps_unpark() before rps_enable_interrupts() and rps_start_timer() and cleared in intel_rps_park() before rps_stop_timer() and rps_disable_interrupts(). Skip unmasking when RPS is no longer active (reaching unmask operation is independent of INTERRUPT mode). This does not prevent RPS operation from resuming on the next unpark. In interrupt mode, intel_rps_unpark() calls rps_enable_interrupts(), which enables and unmasks the PM interrupts. In timer mode, it calls rps_start_timer(), restarting periodic engine-busyness evaluation. The timer generates software RPS events and queues rps_work() directly, independently of PM interrupt delivery. Neither mode requires the late worker to unmask interrupts while the GT is parked (cherry picked from commit ca4a6deadad15b91ee083afe445fa6bdbfb68206)
In the Linux kernel, the following vulnerability has been resolved: fs: avoid repeated scans in evict_inodes() We observed hung tasks when users attempted to unmount a filesystem after its disk had been removed while still in use. During device removal, fs_bdev_mark_dead() calls evict_inodes() while holding s_umount. Each time evict_inodes() drops s_inode_list_lock to reschedule, it restarts the walk from the head of s_inodes. With many referenced inodes at the head of the list, these restarts repeatedly scan the same inodes without reclaiming them. This can keep s_umount held for a long time, blocking concurrent umount attempts and triggering hung-task reports. Keep the current inode, already marked I_FREEING, out of the disposal batch until s_inode_list_lock is reacquired. Resume the walk from this inode and dispose of it in a later batch or at the end of the walk. The zero-refcount and state checks under i_lock allow this walker to claim the inode by setting I_FREEING and removing it from the LRU. Other reclaimers skip the inode, leaving this walker responsible for eviction. Only evict() removes it from s_inodes, so keeping it out of the disposal batch ensures that it remains on the list while the lock is dropped. After reacquiring the lock, reading its current next pointer accounts for concurrent removal of following inodes. The existing inode lifetime rules prohibit acquiring a reference to an inode marked I_FREEING or I_WILL_FREE. __iget() requires its caller to hold i_lock and establish that taking a reference is valid. Inode lookup and igrab() check these flags under i_lock when acquiring a reference from zero. ihold() requires an existing reference, which would keep i_count nonzero and prevent this walker from claiming the inode. These rules already allow iput_final() and the inode shrinker to release i_lock after setting I_FREEING and before eviction completes. A temporary __iget() reference would also keep the inode on the list, but its release must preserve last-reference handling. Another user can acquire a reference, update lazy timestamps and drop its reference while the pin is held. If the pin becomes the last reference, dropping it with atomic_dec_and_test() and evicting directly bypasses iput()'s lazytime handling and can lose those timestamp updates. Releasing the pin with iput() preserves that handling, but does not guarantee eviction. fs_bdev_mark_dead() runs with SB_ACTIVE set, so iput() may retain the inode in cache, whereas evict_inodes() must evict eligible zero-reference inodes. The inode may also have been freed when iput() returns, so the walker cannot then use it to force eviction. Using I_FREEING preserves the existing eviction behavior without introducing an additional last-reference transition. The xfstests auto group passed on ext4 and XFS with known unrelated failures excluded. No new issues were observed, and the previously reproducible hung task no longer occurs with this patch.
In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: oss: Reject reads that cannot fit the next event snd_seq_oss_read() checks whether the next queued OSS sequencer event fits in the remaining userspace buffer before removing it from the read queue. The check is inverted. It currently stops when the event is smaller than the remaining buffer, so a normal 4-byte event is not copied for an 8-byte read buffer. Conversely, an 8-byte event can be copied for a smaller read count. Break only when the remaining userspace buffer is smaller than the next event, and report -EINVAL if no complete event has been copied. This prevents an undersized read from looking like end-of-file while leaving the event queued for a later read with a large enough buffer.
In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: unregister devlink on port registration failure cpsw_probe() registers devlink before registering the CPSW ports. If cpsw_register_ports() fails, the error path only unregisters the notifiers and then releases the lower level resources. It does not undo the successful cpsw_register_devlink() call, leaving the devlink instance and its parameters registered after probe has failed. Add a devlink cleanup label for the path where devlink registration has already succeeded, and use it when port registration fails.
In the Linux kernel, the following vulnerability has been resolved: btrfs: protect sb_write_pointer() with invalidate lock sb_write_pointer() reads the super block from the block device page cache using read_cache_page_gfp(). This has the same race with BLKBSZSET as the one fixed by commit 3f29d661e568 ("btrfs: sync read disk super and set block size"). Take the mapping invalidate lock around read_cache_page_gfp() to serialize the read against block size changes.
In the Linux kernel, the following vulnerability has been resolved: md/raid5: let stripe batch bm_seq comparison wrap-safe Once the 32-bit seq wraps, a newer bm_seq can look smaller than old, so .. covert to wrap-safe calculate way.
In the Linux kernel, the following vulnerability has been resolved: xen/gntalloc: validate grant count before allocation gntalloc_ioctl_alloc() allocates the grant-id array before checking whether the requested count fits within the global grant limit. Counts above that limit cannot succeed, so reject them before the user-controlled allocation reaches kcalloc(). Use a subtraction-based check while holding gref_mutex so adding the requested count cannot wrap. Also cast the count before advancing the per-file index so the page-size multiplication is performed in 64-bit arithmetic.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm/si: Don't schedule thermal work when queue isn't initialized When DPM is turned off with the amdgpu.dpm=0 module parameter, the thermal work queue isn't initialized so we shouldn't schedule any work on it. (cherry picked from commit bd018d36171a695952c6d391471c279c9e05c8b2)
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Keep the domain reference while processing hotplug We process hotplug events in a workqueue that may run after the domain has been removed by tb_domain_remove(). For example if user unloads the driver while at the same time plugging a device router we may have scheduled tb_handle_hotplug() to run. Avoid possible UAF in this case by taking the domain reference before scheduling the hotplug handler in tb_queue_hotplug().
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Validate SENSOR_UPDATE payload size SENSOR_UPDATE carries one or more sensor readings after the fixed notification header. The parser derives the expected reading count from the sensor description, but it did not verify that the received payload contains those entries before parsing them. Reject truncated update notifications before reading the variable array.
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Validate BASE_ERROR_EVENT payload size BASE_ERROR_EVENT carries a variable number of message reports, with the count encoded in error_status. The notification parser used that count without checking whether the received payload contained all reported entries. Reject truncated payloads before copying the report array.
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: validate deauth frame length before reason access ieee80211_rx_mgmt_deauth() reads the deauth reason code before checking that the fixed field is actually present in the received frame. Validate the deauth frame length first and only then read the reason code.
In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: reject short monitor TX frames In monitor mode, lbs_hard_start_xmit() casts skb->data to a radiotap TX header, skips that header, and then copies the 802.11 destination address from offset 4 in the remaining frame. The generic length check only rejects zero-length and oversized skbs, so a short monitor frame can be read past the end of the skb data. Require enough bytes for the radiotap TX header and the destination address field before using the monitor-mode header layout.
In the Linux kernel, the following vulnerability has been resolved: arm64: kprobes: Allow reentering kprobes while single-stepping A kprobe can be hit while another kprobe is in KPROBE_HIT_SS state. This can happen when tracing or perf code runs from the debug exception path while the first kprobe is preparing or executing its out-of-line single-step instruction. Currently arm64 treats a kprobe hit in KPROBE_HIT_SS as unrecoverable, the same as a hit in KPROBE_REENTER. This is too strict. A hit in KPROBE_HIT_SS is still a one-level reentry and can be handled by saving the current kprobe state and setting up single-step for the new probe, just like reentry from KPROBE_HIT_ACTIVE or KPROBE_HIT_SSDONE. The truly unrecoverable case is hitting another kprobe while already in KPROBE_REENTER, because the reentry save area has already been consumed. Move KPROBE_HIT_SS to the recoverable reentry cases and leave KPROBE_REENTER as the unrecoverable nested reentry case. This change also requires saving saved_irqflag in struct prev_kprobe. When a nested kprobe calls kprobes_save_local_irqflag(), it overwrites kcb->saved_irqflag with the currently masked DAIF value, losing the outer kprobe's original DAIF state. Without this fix, when the outer kprobe's single-step finishes, kprobes_restore_local_irqflag() applies the wrong DAIF mask and leaves interrupts permanently disabled. Extend struct prev_kprobe with a saved_irqflag field and save/restore it alongside kp and status. This ensures the outer kprobe's original interrupt state is preserved across reentry. This mirrors the x86 fix in commit 6a5022a56ac3 ("kprobes/x86: Allow to handle reentered kprobe on single-stepping").
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: reject undersized HWSIM_ATTR_TX_INFO hwsim_tx_info_frame_received_nl() casts the HWSIM_ATTR_TX_INFO payload to a struct hwsim_tx_rate * and unconditionally reads IEEE80211_TX_MAX_RATES entries (8 bytes) from it. The policy only bounds the attribute from above (NLA_BINARY .len is a maximum) and the op sets GENL_DONT_VALIDATE_STRICT, so a short or zero-length attribute is accepted and the loop reads past the payload. Require the exact length in the policy, so a malformed attribute is rejected before the handler runs.
In the Linux kernel, the following vulnerability has been resolved: drm/gma500: return errors from Oaktrail HDMI I2C reads xfer_read() waits for the HDMI I2C transaction to reach I2C_TRANSACTION_DONE, but it ignores both timeout and signal returns from wait_for_completion_interruptible_timeout(). If the interrupt never advances the transaction state, the loop can wait forever. Return -ETIMEDOUT when the completion wait expires, propagate interrupted waits, and make the I2C master_xfer callback return the first transfer error instead of reporting a successful message count.
In the Linux kernel, the following vulnerability has been resolved: ima: return error early if file xattr cannot be changed During early boot, the filesystem is read-only and any changes to xattrs are not allowed. This fails in case of ext4 because changing xattr starts an ext4 transaction which fails with the following warning. WARNING: fs/ext4/ext4_jbd2.c:75 at ext4_journal_check_start+0x63/0xa0 [ext4], CPU#1: systemd-sysroot/561 CPU: 1 UID: 0 PID: 561 Comm: systemd-sysroot Not tainted 6.19.12-1-default #1 PREEMPT(voluntary) openSUSE Tumbleweed c2dfc3c9d9f6f1233251c5d4410574fe82a348ee Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:ext4_journal_check_start+0x63/0xa0 [ext4] Call Trace: __ext4_journal_start_sb+0x3e/0x180 [ext4 6d025f3bc52c89a957b89a89d211fadf5e9434e1] ext4_xattr_set+0x104/0x150 [ext4 6d025f3bc52c89a957b89a89d211fadf5e9434e1] __vfs_setxattr+0x9a/0xd0 __vfs_setxattr_noperm+0x76/0x1f0 ima_appraise_measurement+0x23e/0xe40 ima_d_path+0x5a/0xd0 process_measurement+0xb29/0xc40 ? copy_from_kernel_nofault+0x21/0xe0 ? fscrypt_file_open+0xc0/0xe0 ? ext4_file_open+0x60/0x490 [ext4 6d025f3bc52c89a957b89a89d211fadf5e9434e1] ? bpf_prog_31efb7c56239148b_restrict_filesystems+0xab/0x126 ? __bpf_prog_exit+0x23/0xd0 ? __bpf_tramp_exit+0xd/0x50 ? bpf_trampoline_6442530367+0x9f/0xea ima_file_check+0x57/0x80 security_file_post_open+0x50/0xf0 path_openat+0x493/0x1650 do_filp_open+0xc7/0x170 Detect the state of the file early and return the error.
In the Linux kernel, the following vulnerability has been resolved: mmc: core: Add validation for host-provided max_segs The max_segs field is of type unsigned short, and if a host driver sets an excessively large value, it may be truncated to zero. This can cause mmc_alloc_sg() to call kmalloc_objs() with a zero size allocation request, which leads to undefined behavior. Under the SLUB allocator, kmalloc(0) returns a special pointer (ZERO_SIZE_PTR). The subsequent 'if (sg)' check will evaluate to true, and sg_init_table() will then attempt to access invalid memory, resulting in a crash: dwmmc_rockchip 2a310000.mmc: Successfully tuned phase to 133 mmc1: new UHS-I speed SDR104 SDHC card at address aaaa Unable to handle kernel paging request at virtual address 0000001ffffffff0 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000102c88000 [0000001ffffffff0] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 2 UID: 0 PID: 102 Comm: kworker/2:1 Not tainted 7.0.0-rc6-next-20260331-00013-g4d93c25963c5-dirty #80 PREEMPT Hardware name: Rockchip RK3576 EVB V10 Board (DT) Workqueue: events_freezable mmc_rescan pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : sg_init_table+0x2c/0x50 lr : sg_init_table+0x24/0x50 sp : ffff8000837db710 x29: ffff8000837db710 x28: 000000000000c000 x27: 0000000000000300 x26: 0000000000000000 x25: 0000000000000040 x24: ffff0000c46a0000 x23: 0000000000000000 x22: ffff0000c0c73c00 x21: 0000000000000010 x20: 0000000000000010 x19: 0000000000000000 x18: 000000000000002c x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 x14: 0000000000000400 x13: ffff8000837dc000 x12: 0000000000000000 x11: ffff0000c0c73ca0 x10: 0000000000000040 x9 : 459ec1f0abbdbb00 x8 : 0000001fffffffe0 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000035579 x4 : 0000000000000901 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000010 Call trace: sg_init_table+0x2c/0x50 (P) mmc_mq_init_request+0x64/0x90 blk_mq_alloc_map_and_rqs+0x3ac/0x480 blk_mq_alloc_set_map_and_rqs+0x98/0x1e0 blk_mq_alloc_tag_set+0x1c0/0x290 mmc_init_queue+0x120/0x370 mmc_blk_alloc_req+0x150/0x420 To prevent this, add a validation check in mmc_mq_init_request() to detect when sg_len (derived from max_segs) is zero. If sg_len is zero, we return an error and print an error message, allowing host driver developers to identify and fix incorrect max_segs configuration. This is a defensive measure that ensures the MMC core fails gracefully when host drivers provide invalid max_segs values, rather than crashing with a page fault.
In the Linux kernel, the following vulnerability has been resolved: net: bridge: remove stale rcu_barrier() in br_multicast_dev_del() This rcu_barrier() came from a time call_rcu() calls were used in net/bridge/br_multicast.c. Now kfree_rcu() is there, we can remove this problematic rcu_barrier() which causes extreme RTNL pressure in many syzbot reports. INFO: task syz-executor:77945 is blocked on a mutex likely owned by task kworker/u1024:5:36537. task:kworker/u1024:5 state:D stack:24616 pid:36537 tgid:36537 ppid:2 task_flags:0x4208060 flags:0x00080000 last_sleep:612797637337 Workqueue: netns cleanup_net Call Trace: <TASK> [<ffffffff81914eaa>] context_switch+0xf2a/0x1730 kernel/sched/core.c:6483 [<ffffffff81201143>] __schedule+0x1133/0x43a0 kernel/sched/core.c:8411 [<ffffffff8120446b>] __schedule_loop kernel/sched/core.c:8514 [inline] [<ffffffff8120446b>] schedule+0xab/0x260 kernel/sched/core.c:8529 [<ffffffff8121a093>] schedule_timeout+0xc3/0x2b0 kernel/time/sleep_timeout.c:75 [<ffffffff81205347>] do_wait_for_common kernel/sched/completion.c:100 [inline] [<ffffffff81205347>] __wait_for_common kernel/sched/completion.c:121 [inline] [<ffffffff81205347>] wait_for_common kernel/sched/completion.c:132 [inline] [<ffffffff81205347>] wait_for_completion+0x2c7/0x5d0 kernel/sched/completion.c:153 [<ffffffff81b8f27f>] rcu_barrier+0x49f/0x620 kernel/rcu/tree.c:3888 [<ffffffff860091b3>] br_multicast_dev_del+0x303/0x350 net/bridge/br_multicast.c:4459 [<ffffffff85fb5dbc>] br_dev_uninit+0x1c/0x40 net/bridge/br_device.c:157 [<ffffffff8568058c>] unregister_netdevice_many_notify+0x1c1c/0x2300 net/core/dev.c:12599 [<ffffffff8562be43>] ops_exit_rtnl_list net/core/net_namespace.c:187 [inline] [<ffffffff8562be43>] ops_undo_list+0x3d3/0x940 net/core/net_namespace.c:248
In the Linux kernel, the following vulnerability has been resolved: isofs: handle set_blocksize failures isofs uses buffer_heads, which don't handle block size > PAGE_SIZE well. Without this, mounting we will hit the BUG_ON(offset >= folio_size(folio)); in folio_set_bh on the first __bread_gfp call.
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't advertise VLPIs if no ITS is probed When accidentally setting “kvm-arm.vgic_v4_enable=1” on a system that has no MSI controller device tree node and GICv4, it results a panic as “gic_domain” is NULL and the kernel attempts to access it. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 Mem abort info: ESR = 0x0000000096000006 CPU: 1 UID: 0 PID: 295 Comm: lkvm-static Not tainted 7.1.0-rc4-ge3f15ad3970e #5 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 81402005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __irq_domain_instantiate+0x1d4/0x578 lr : __irq_domain_instantiate+0x1cc/0x578 Set vLPI support to false at init time if the host has no ITS, so it propagates properly to kvm_vgic_global_state.has_gicv4.
In the Linux kernel, the following vulnerability has been resolved: host1x: bus: Fix missing ops null check in error teardown In host1x_device_init(), the error teardown paths do not check client->ops before dereferencing it, unlike the forward init paths which correctly guard with 'client->ops &&'. This can result in a NULL pointer dereference if client->ops is NULL. Fix by adding the missing client->ops check in both the teardown and teardown_late labels.