A missing permission check in Jenkins Git Parameter Plugin 462.vdcf3df2ed2ca_ and earlier allows attackers with Item/Read permission to obtain information about the SCM repository used by a job, such as branch names, tag names, and revision metadata.
A missing permission check in Jenkins GitHub Branch Source Plugin 1967.1969.v205fd594c821 and earlier allows attackers with Overall/Read permission to obtain the URLs of GitHub Enterprise servers configured in the global plugin configuration.
Cross-Site Request Forgery in the MP Customize Login Page WordPress plugin (all versions ≤ 1.0) enables unauthenticated remote attackers to overwrite login page settings - background, logo URL, image dimensions, button colors, and login message - by tricking a logged-in administrator into submitting a crafted request. The root cause is a doubly defective nonce implementation in enter_mpclp_login_options(): the check is logically inverted (blocking valid nonces while passing invalid ones) and the required action parameter is omitted from wp_verify_nonce(), rendering the entire check dead code. Compounding this, the settings handler is registered on the init hook without any capability gate, so no privilege level is required from the attacker. No public exploit has been identified at time of analysis, and active exploitation has not been confirmed by CISA KEV.
Jenkins FitNesse Plugin 1.36 and earlier stores passwords unencrypted in job config.xml files on the Jenkins controller, where they can be viewed by users with Extended Read permission or access to the Jenkins controller file system.
A missing permission check in Jenkins MCP Server Plugin 0.177.v629fdb_2557fe and earlier allows attackers with Item/Read permission to read the Pipeline replay scripts of jobs they can access.
Private repository metadata in Gogs 0.14.3 and earlier leaks to any authenticated user due to a boolean inversion in the Watch API access control check. An authenticated attacker who watches a private repository they are not authorized to view will receive commit messages, branch names, issue titles, and PR details via their dashboard activity feed - and full issue and comment content via email if notifications are enabled. No public exploit has been identified at time of analysis, though the single-line boolean fix published in the upstream commit makes the flaw trivial to reproduce by any authenticated user who reads the commit diff.
Missing authorization checks in Jenkins Contrast Continuous Application Security Plugin 3.11 and earlier allow any authenticated Jenkins user with the low-privilege Overall/Read permission to enumerate the names of configured Contrast metadata via a network-accessible endpoint. The vulnerability is classified CWE-862 (Missing Authorization) and has an EPSS score of 0.15% (4th percentile), indicating negligible real-world exploitation activity. No public exploit code and no CISA KEV listing have been identified, making this a low-urgency but real information-disclosure concern for multi-tenant Jenkins environments with untrusted users.
Missing authorization in Jenkins Contrast Continuous Application Security Plugin 3.11 and earlier permits any authenticated Jenkins user holding the minimal Overall/Read permission to invoke a connection test endpoint with fully attacker-controlled URL, username, API key, and service key. This enables the Jenkins server to make arbitrary outbound HTTP connections - a Server-Side Request Forgery (SSRF)-class impact - without the elevated privileges that should guard such functionality. No public exploit has been identified at time of analysis and EPSS sits at the 4th percentile, indicating low current exploitation probability despite network reachability.
Cross-Site Request Forgery in the Blue Captcha WordPress plugin (versions ≤ 2.0.1) allows unauthenticated attackers to trigger destructive administrative operations - including plugin uninstall, audit log deletion, Hall of Shame wipe, and arbitrary IP blocklist manipulation - by tricking a logged-in administrator into clicking a crafted link. The root cause is a complete absence of nonce validation (`wp_verify_nonce`, `check_admin_referer`, `check_ajax_referer`) across all admin handler entry points, confirmed by Wordfence with direct source code references. No public exploit has been identified at time of analysis, and no patched version has been confirmed.
Cross-Site Request Forgery in the MotorDesk WordPress plugin (all versions ≤ 1.1.2) allows unauthenticated remote attackers to overwrite critical plugin configuration settings by tricking a logged-in administrator into clicking a crafted link. The vulnerable function motordesk_admin_home in motordesk_admin.php lacks proper WordPress nonce validation, meaning the server accepts state-changing POST requests without confirming the administrator intentionally submitted them. No public exploit code has been identified at time of analysis; the CVSS 4.3 Medium score accurately reflects the social-engineering dependency, though the custom template directory path setting warrants secondary scrutiny for potential path traversal chaining.
Cross-Site Request Forgery in the Bulk SEO Image WordPress plugin (versions ≤ 1.1) enables unauthenticated attackers to bulk-overwrite every image ALT-text attribute across all published posts and pages on a target site by tricking an authenticated administrator into visiting a malicious page. The plugin's core handler BulkSeoImage() dispatches to launchbulk() and BulkSeoImageGo() whenever a POST request includes the 'bulkseoimage' parameter, with no wp_nonce_field() emitted in the form and no check_admin_referer() or wp_verify_nonce() call gating execution - confirmed by direct source code review at the plugin's Trac repository. No public exploit has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Jenkins Job Configuration History Plugin version 1356.ve360da_6c523a_ and earlier exposes encrypted secret values to any Jenkins user holding Extended Read permission by failing to apply Jenkins' standard secret redaction when rendering historical job and agent configurations. Encrypted credential values that Jenkins would normally mask are displayed in full within the plugin's history view, potentially enabling offline analysis of those values. No public exploit or active exploitation has been identified; SSVC rates this as non-automatable with partial technical impact.
Cross-site request forgery in the Jenkins Pipeline: Groovy Plugin (versions up to and including 4331.v9d06ed4658ff) enables authenticated low-privilege users to instantiate arbitrary Java types related to job or system configuration by exploiting the unprotected Pipeline Snippet Generator endpoint. The attacker can reach types outside the normally permitted set of Pipeline steps, potentially influencing configuration objects that should be off-limits at their privilege level. No public exploit code has been identified at time of analysis, and CISA SSVC rates exploitation as none with non-automatable delivery.
Same-origin policy bypass in Google Chrome's DeviceBoundSessionCredentials (DBSC) feature affects all Chrome versions prior to 149.0.7827.197, allowing a remote attacker to read limited cross-origin data via a crafted HTML page. The flaw stems from incorrect origin validation (CWE-346) in the DBSC implementation, a relatively new anti-session-hijacking subsystem. SSVC assessment confirms no exploitation at time of analysis, and no public exploit code has been identified; the CVSS score of 4.3 Medium reflects meaningful but bounded confidentiality impact contingent on user interaction.
A cross-site request forgery (CSRF) vulnerability in Jenkins Priority Sorter Plugin 936.v2c01c6b_84449 and earlier allows attackers to overwrite the global job priority configuration.
Cross-Site Request Forgery in the Book a Room Event Calendar WordPress plugin (all versions through 1.9) allows unauthenticated remote attackers to overwrite sensitive plugin configuration - including external database host, credentials, encryption key, and registration URL - by tricking an authenticated administrator into visiting a malicious page. The vulnerability stems from a complete absence of WordPress nonce mechanisms (no wp_nonce_field(), check_admin_referer(), or wp_verify_nonce()) in both the settings form and its handler, meaning any browser-submitted POST during an active admin session is honored unconditionally. No public exploit has been identified at time of analysis, and the plugin is a niche product, limiting real-world blast radius despite the sensitive nature of the overwriteable fields.
Flowise versions 3.0.13 and earlier silently fall back to a hardcoded AES-256-CBC encryption key derived from the publicly known literal 'Secre$t' when TOKEN_HASH_SECRET is not configured, exposing the user and workspace IDs encoded in the 'meta' field of every JWT token issued by an unconfigured deployment. An authenticated user or network-positioned attacker who obtains any valid JWT can decrypt this metadata using the default key - now disclosed in the GHSA advisory and source code - and re-encrypt manipulated identifiers to probe downstream access controls. JWT signature validation is handled independently, so this does not constitute standalone token forgery, but identifier disclosure and metadata manipulation create a realistic stepping stone toward privilege escalation or unauthorized workspace access in multi-tenant deployments. No active exploitation is confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis; vendor-released patch Flowise 3.1.0 is available.
Unvalidated `ot_`-prefixed argument injection in OliveTin allows any authenticated user with action-trigger access to bypass input filtering, inject arbitrary environment variables into action execution contexts, and pollute Go template rendering data. All OliveTin versions prior to commit `ebffd9f040f7` (Go pseudo-version `< 0.0.0-20260531214440-ebffd9f040f7`) are affected. While direct standalone RCE is not confirmed, a public proof-of-concept exists in GHSA-prj9-97mp-mwh2 and secondary command injection is achievable wherever triggered action scripts consume `OT_`-prefixed environment variables in shell-unsafe ways.
Credential ID enumeration in Jenkins Gitee Plugin 1288.v18b_deb_c9069b_ and earlier allows authenticated attackers holding only global Item/Configure permission to bypass the intended per-job permission boundary and list credential IDs stored in Jenkins. The root cause is an incorrect permission check (CWE-862) that conflates global and job-scoped authorization, leaking credential identifiers without requiring job-level rights. No public exploit code exists and SSVC rates exploitation status as none; however, enumerated credential IDs can serve as reconnaissance for chained attacks targeting those credentials.
Site isolation bypass in Google Chrome's Navigation component allows an attacker who has already compromised the renderer process to escape Chrome's cross-origin containment boundary via a crafted HTML page, affecting all Chrome versions prior to 149.0.7827.197. The vulnerability stems from insufficient input validation (CWE-20) in the Navigation subsystem, which fails to properly enforce site isolation when navigations are initiated from a compromised renderer. No public exploit code has been identified and CISA SSVC confirms no known active exploitation at time of analysis, though the prerequisite of renderer compromise makes this a meaningful second-stage escalation primitive.
A missing permission check in Jenkins Zowe zDevOps Plugin 1.1.3.50.ve350c9b_450b_1 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.
A cross-site request forgery (CSRF) vulnerability in Jenkins Zowe zDevOps Plugin 1.1.3.50.ve350c9b_450b_1 and earlier allows attackers to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.
DNS rebinding bypasses Ghost CMS's private-IP validation for outbound HTTP requests, enabling server-side request forgery (SSRF) against internal network resources. Versions 6.0.9 through 6.21.0 are affected; the root cause is a TOCTOU race (CWE-367) between Ghost's allowlist check and the actual TCP connection, which a DNS-rebinding attacker exploits by switching DNS records between check-time and connect-time. No public exploit code identified and not listed in CISA KEV, but the scope-changed CVSS rating (S:C) reflects that successful exploitation escapes Ghost's network boundary into adjacent internal infrastructure.
LDAP injection in Jenkins Active Directory Plugin 2.41.1 and earlier allows unauthenticated remote attackers to enumerate Active Directory entries and authenticate as any directory user they can identify via wildcard matching, provided they already know that user's password. The vulnerability is confined to the Windows native ADSI authentication path, limiting exposure to Jenkins instances running on Windows with ADSI configured. No public exploit code or active exploitation has been identified; SSVC rates it non-automatable with partial technical impact.
Insufficient OAuth token revocation in Rocket.Chat allows deactivated user accounts to maintain persistent, unauthorized access to the platform. Affected versions prior to 8.5.0, 8.4.2, 8.3.4, 8.2.4, 8.1.5, 8.0.6, 7.13.8, and 7.10.12 fail to invalidate bearer or refresh tokens upon account deactivation, meaning a deactivated user can continue accessing resources with an existing bearer token or mint entirely new bearer tokens from a retained refresh token. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV; however, the post-deactivation access window is unbounded unless tokens naturally expire.
Insufficient session expiration in Rocket.Chat allows users administratively deactivated via the users.deactivateIdle mechanism to continue accessing authenticated REST API endpoints using previously-issued login tokens that were never invalidated. All Rocket.Chat deployments across the 7.x and 8.x release branches prior to the fixed versions are affected. No public exploit has been identified and the CVSS 4.0 score of 2.3 reflects genuinely low real-world risk given high attack complexity, limited impact, and the requirement for a specific idle-deactivation administrative workflow.
Insufficient session expiration in Apache Shiro's RememberMe feature allows a stolen cookie to be replayed indefinitely, bypassing the configured cookie age restriction. All shiro-web deployments from version 1.2.4 through the entire 2.x line and the 3.0.0-alpha-1 pre-release are affected whenever RememberMe is enabled. An attacker who intercepts a victim's RememberMe cookie - through network interception, XSS, or similar means - can reuse it without time limit, effectively maintaining persistent unauthorized access to the victim's session even after the configured expiration has elapsed. No public exploit code or CISA KEV listing has been identified at time of analysis.
Path traversal in Jellyfin prior to 10.11.10 enables an attacker who can place a crafted MKV file in a victim's Jellyfin library to redirect the server's MKV attachment extraction routine to arbitrary absolute filesystem paths on the host. The flaw originates in .NET's Path.Combine behavior: Jellyfin passes the unsanitized MKV filename tag directly into Path.Combine(attachmentFolder, fileName), and .NET silently ignores the base path when the second argument is rooted, enabling full path override. Exploitation is triggered automatically whenever any Jellyfin client plays the affected file with subtitle burning enabled, which is the default behavior. No public exploit has been identified at time of analysis, and the CVSS 4.0 score of 1.7 reflects high complexity and low integrity-only impact.
Stored XSS in the AWS API key store component of Thinkst Applied Research Canarytokens allows a low-privileged attacker who knows a token's random identifier to inject persistent malicious scripts that execute in a victim's browser when they view the affected token page. Exploitation is constrained by high attack complexity (AC:H), a prerequisite attack requirement (knowledge of a random identifier), low-privilege authentication, and active user interaction - reflected in an extremely low CVSS 4.0 base score of 1.1. No active exploitation is confirmed; however, the CVSS 4.0 vector includes E:P, indicating proof-of-concept exploit code exists.
In the Linux kernel, the following vulnerability has been resolved: efi/capsule-loader: fix incorrect sizeof in phys array reallocation The krealloc() call for cap_info->phys in __efi_capsule_setup_info() uses sizeof(phys_addr_t *) instead of sizeof(phys_addr_t), which might be causing an undersized allocation. The allocation is also inconsistent with the initial array allocation in efi_capsule_open() that allocates one entry with sizeof(phys_addr_t), and the efi_capsule_write() function that stores phys_addr_t values (not pointers) via page_to_phys(). On 64-bit systems where sizeof(phys_addr_t) == sizeof(phys_addr_t *), this goes unnoticed. On 32-bit systems with PAE where phys_addr_t is 64-bit but pointers are 32-bit, this allocates half the required space, which might lead to a heap buffer overflow when storing physical addresses. This is similar to the bug fixed in commit fccfa646ef36 ("efi/capsule-loader: fix incorrect allocation size") which fixed the same issue at the initial allocation site.
In the Linux kernel, the following vulnerability has been resolved: dm cache metadata: fix memory leak on metadata abort retry When failing to acquire the root_lock in dm_cache_metadata_abort because the block_manager is read-only, the temporary block_manager created outside the root_lock is not properly released, causing a memory leak. Reproduce steps: This can be reproduced by reloading a new table while the metadata is read-only. While the second call to dm_cache_metadata_abort is caused by lack of support for table preload in dm-cache, mentioned in commit 9b1cc9f251af ("dm cache: share cache-metadata object across inactive and active DM tables"), it exposes the memory leak in dm_cache_metadata_abort when the function is called multiple times. Specifically, dm-cache fails to sync the new cache object's mode during preresume, creating the reproducer condition. This issue could also occur through concurrent metadata_operation_failed calls due to races in cache mode updates, but the table preload scenario below provides a reliable reproducer. 1. Create a cache device with some faulty trailing metadata blocks dmsetup create cmeta <<EOF 0 200 linear /dev/sdc 0 200 7992 error EOF dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 131072 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 1 writethrough smq 0" 2. Suspend and resume the cache to start a new metadata transaction and trigger metadata io errors on the next metadata commit. dmsetup suspend cache dmsetup resume cache 3. Write to the cache device to update metadata fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \ --randrepeat=0 --direct=1 --size 64k 4. Preload the same table dmsetup reload cache --table "$(dmsetup table cache)" 5. Resume the new table. This triggers the memory leak. dmsetup suspend cache dmsetup resume cache kmemleak logs: <snip> unreferenced object 0xffff8880080c2010 (size 16): comm "dmsetup", pid 132, jiffies 4294982580 hex dump (first 16 bytes): 00 38 b9 07 80 88 ff ff 6a 6b 6b 6b 6b 6b 6b a5 ... backtrace (crc 3118f31c): kmemleak_alloc+0x28/0x40 __kmalloc_cache_noprof+0x3d9/0x510 dm_block_manager_create+0x51/0x140 dm_cache_metadata_abort+0x85/0x320 metadata_operation_failed+0x103/0x1e0 cache_preresume+0xacd/0xe70 dm_table_resume_targets+0xd3/0x320 __dm_resume+0x1b/0xf0 dm_resume+0x127/0x170 <snip>
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix write hang in passthrough mode The invalidate_remove() function has incomplete logic for handling write hit bios after cache invalidation. It sets up the remapping for the overwrite_bio but then drops it immediately without submission, causing write operations to hang. Fix by adding a new invalidate_committed() continuation that submits the remapped writes to the cache origin after metadata commit completes, while using the overwrite_endio hook to ensure proper completion sequencing. This maintains existing coherency. Also improve error handling in invalidate_complete() to preserve the original error status instead of using bio_io_error() unconditionally.
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: fix mismatch between power and frequency During DPU runtime suspend, calling dev_pm_opp_set_rate(dev, 0) drops the MMCX rail to MIN_SVS while the core clock frequency remains at its original (highest) rate. When runtime resume re-enables the clock, this may result in a mismatch between the rail voltage and the clock rate. For example, in the DPU bind path, the sequence could be: cpu0: dev_sync_state -> rpmhpd_sync_state cpu1: dpu_kms_hw_init timeline 0 ------------------------------------------------> t After rpmhpd_sync_state, the voltage performance is no longer guaranteed to stay at the highest level. During dpu_kms_hw_init, calling dev_pm_opp_set_rate(dev, 0) drops the voltage, causing the MMCX rail to fall to MIN_SVS while the core clock is still at its maximum frequency. When the power is re-enabled, only the clock is enabled, leading to a situation where the MMCX rail is at MIN_SVS but the core clock is at its highest rate. In this state, the rail cannot sustain the clock rate, which may cause instability or system crash. Remove the call to dev_pm_opp_set_rate(dev, 0) from dpu_runtime_suspend to ensure the correct vote is restored when DPU resumes. Patchwork: https://patchwork.freedesktop.org/patch/710077/
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock between reflink and transaction commit when using flushoncommit When using the flushoncommit mount option, we can have a deadlock between a transaction commit and a reflink operation that copied an inline extent to an offset beyond the current i_size of the destination node. The deadlock happens like this: 1) Task A clones an inline extent from inode X to an offset of inode Y that is beyond Y's current i_size. This means we copied the inline extent's data to a folio of inode Y that is beyond its EOF, using a call to copy_inline_to_page(); 2) Task B starts a transaction commit and calls btrfs_start_delalloc_flush() to flush delalloc; 3) The delalloc flushing sees the new dirty folio of inode Y and when it attempts to flush it, it ends up at extent_writepage() and sees that the offset of the folio is beyond the i_size of inode Y, so it attempts to invalidate the folio by calling folio_invalidate(), which ends up at btrfs' folio invalidate callback - btrfs_invalidate_folio(). There it tries to lock the folio's range in inode Y's extent io tree, but it blocks since it's currently locked by task A - during a reflink we lock the inodes and the source and destination ranges after flushing all delalloc and waiting for ordered extent completion - after that we don't expect to have dirty folios in the ranges, the exception is if we have to copy an inline extent's data (because the destination offset is not zero); 4) Task A then attempts to start a transaction to update the inode item, and then it's blocked since the current transaction is in the TRANS_STATE_COMMIT_START state. Therefore task A has to wait for the current transaction to become unblocked (its state >= TRANS_STATE_UNBLOCKED). So task A is waiting for the transaction commit done by task B, and the later waiting on the extent lock of inode Y that is currently held by task A. Syzbot recently reported this with the following stack traces: INFO: task kworker/u8:7:1053 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:7 state:D stack:23520 pid:1053 tgid:1053 ppid:2 task_flags:0x4208060 flags:0x00080000 Workqueue: writeback wb_workfn (flush-btrfs-46) Call Trace: <TASK> context_switch kernel/sched/core.c:5298 [inline] __schedule+0x1553/0x5240 kernel/sched/core.c:6911 __schedule_loop kernel/sched/core.c:6993 [inline] schedule+0x164/0x360 kernel/sched/core.c:7008 wait_extent_bit fs/btrfs/extent-io-tree.c:811 [inline] btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:1914 btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline] btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c:7704 extent_writepage fs/btrfs/extent_io.c:1852 [inline] extent_write_cache_pages fs/btrfs/extent_io.c:2580 [inline] btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c:2713 do_writepages+0x32e/0x550 mm/page-writeback.c:2554 __writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750 writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c:2042 wb_writeback+0x456/0xb70 fs/fs-writeback.c:2227 wb_do_writeback fs/fs-writeback.c:2374 [inline] wb_workfn+0x41a/0xf60 fs/fs-writeback.c:2414 process_one_work kernel/workqueue.c:3276 [inline] process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359 worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> INFO: task syz.4.64:6910 blocked for more than 143 seconds. Not tainted syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz.4.64 state:D stack:22752 pid:6910 tgid: ---truncated---
In the Linux kernel, the following vulnerability has been resolved: bpf: test_run: Fix the null pointer dereference issue in bpf_lwt_xmit_push_encap The bpf_lwt_xmit_push_encap helper needs to access skb_dst(skb)->dev to calculate the needed headroom: err = skb_cow_head(skb, len + LL_RESERVED_SPACE(skb_dst(skb)->dev)); But skb->_skb_refdst may not be initialized when the skb is set up by bpf_prog_test_run_skb function. Executing bpf_lwt_push_ip_encap function in this scenario will trigger null pointer dereference, causing a kernel crash as Yinhao reported: [ 105.186365] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 105.186382] #PF: supervisor read access in kernel mode [ 105.186388] #PF: error_code(0x0000) - not-present page [ 105.186393] PGD 121d3d067 P4D 121d3d067 PUD 106c83067 PMD 0 [ 105.186404] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 105.186412] CPU: 3 PID: 3250 Comm: poc Kdump: loaded Not tainted 6.19.0-rc5 #1 [ 105.186423] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 105.186427] RIP: 0010:bpf_lwt_push_ip_encap+0x1eb/0x520 [ 105.186443] Code: 0f 84 de 01 00 00 0f b7 4a 04 66 85 c9 0f 85 47 01 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8b 73 58 48 83 e6 fe <48> 8b 36 0f b7 be ec 00 00 00 0f b7 b6 e6 00 00 00 01 fe 83 e6 f0 [ 105.186449] RSP: 0018:ffffbb0e0387bc50 EFLAGS: 00010246 [ 105.186455] RAX: 000000000000004e RBX: ffff94c74e036500 RCX: ffff94c74874da00 [ 105.186460] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff94c74e036500 [ 105.186463] RBP: 0000000000000001 R08: 0000000000000002 R09: 0000000000000000 [ 105.186467] R10: ffffbb0e0387bd50 R11: 0000000000000000 R12: ffffbb0e0387bc98 [ 105.186471] R13: 0000000000000014 R14: 0000000000000000 R15: 0000000000000002 [ 105.186484] FS: 00007f166aa4d680(0000) GS:ffff94c8b7780000(0000) knlGS:0000000000000000 [ 105.186490] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 105.186494] CR2: 0000000000000000 CR3: 000000015eade001 CR4: 0000000000770ee0 [ 105.186499] PKRU: 55555554 [ 105.186502] Call Trace: [ 105.186507] <TASK> [ 105.186513] bpf_lwt_xmit_push_encap+0x2b/0x40 [ 105.186522] bpf_prog_a75eaad51e517912+0x41/0x49 [ 105.186536] ? kvm_clock_get_cycles+0x18/0x30 [ 105.186547] ? ktime_get+0x3c/0xa0 [ 105.186554] bpf_test_run+0x195/0x320 [ 105.186563] ? bpf_test_run+0x10f/0x320 [ 105.186579] bpf_prog_test_run_skb+0x2f5/0x4f0 [ 105.186590] __sys_bpf+0x69c/0xa40 [ 105.186603] __x64_sys_bpf+0x1e/0x30 [ 105.186611] do_syscall_64+0x59/0x110 [ 105.186620] entry_SYSCALL_64_after_hwframe+0x76/0xe0 [ 105.186649] RIP: 0033:0x7f166a97455d Temporarily add the setting of skb->_skb_refdst before bpf_test_run to resolve the issue.
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix error pointer dereference The function brcmf_chip_add_core() can return an error pointer and is not checked. Add checks for error pointer. Detected by Smatch: drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1010 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1013 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1016 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1019 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1022 brcmf_chip_recognition() error: 'core' dereferencing possible ERR_PTR() [add missing wifi: prefix]
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix null-deref with concurrent writes in passthrough mode In passthrough mode, when dm-cache starts to invalidate a cache entry and bio prison cell lock fails due to concurrent write to the same cached block, mg->cell remains NULL. The error path in invalidate_complete() attempts to unlock and free the cell unconditionally, causing a NULL pointer dereference: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 UID: 0 PID: 134 Comm: fio Not tainted 6.19.0-rc7 #3 PREEMPT RIP: 0010:dm_cell_unlock_v2+0x3f/0x210 <snip> Call Trace: invalidate_complete+0xef/0x430 map_bio+0x130f/0x1a10 cache_map+0x320/0x6b0 __map_bio+0x458/0x510 dm_submit_bio+0x40e/0x16d0 __submit_bio+0x419/0x870 <snip> Reproduce steps: 1. Create a cache device dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Promote the first data block into cache fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the first cached block concurrently fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \ --randrepeat=0 --direct=1 --numjobs=2 --size 64k Fix by checking if mg->cell is valid before attempting to unlock it.
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix dirty mapping checking in passthrough mode switching As mentioned in commit 9b1cc9f251af ("dm cache: share cache-metadata object across inactive and active DM tables"), dm-cache assumed table reload occurs after suspension, while LVM's table preload breaks this assumption. The dirty mapping check for passthrough mode was designed around this assumption and is performed during table creation, causing the check to fail with preload while metadata updates are ongoing. This risks loading dirty mappings into passthrough mode, resulting in data loss. Reproduce steps: 1. Create a writeback cache with zero migration_threshold to produce dirty mappings dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writeback smq \ 2 migration_threshold 0" 2. Preload a table in passthrough mode dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" 3. Write to the first cache block to make it dirty fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 4. Resume the inactive table. Now it's possible to load the dirty block into passthrough mode. dmsetup resume cache Fix by moving the checks to the preresume phase to support table preloading. Also remove the unused function dm_cache_metadata_all_clean.
In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of "old" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 ("net: sched: protect filter_chain list with filter_chain_lock mutex") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the "old" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \ > -A 4.3.2.1 -B 1.2.3.4 -t udp "dp=1234" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: <TASK> tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 </TASK> irq event stamp: 1045778 hardirqs last enabled at (1045784): [<ffffffff864ec042>] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [<ffffffff864ec027>] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [<ffffffff874d48c7>] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [<ffffffff874fe8f8>] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip "old-style" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw "old-style" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error When hci_register_dev() fails in hci_uart_register_dev() HCI_UART_PROTO_INIT is not cleared before calling hu->proto->close(hu) and setting hu->hdev to NULL. This means incoming UART data will reach the protocol-specific recv handler in hci_uart_tty_receive() after resources are freed. Clear HCI_UART_PROTO_INIT with a write lock before calling hu->proto->close() and setting hu->hdev to NULL. The write lock ensures all active readers have completed and no new reader can enter the protocol recv path before resources are freed. This allows the protocol-specific recv functions to remove the "HCI_UART_REGISTERED" guard without risking a null pointer dereference if hci_register_dev() fails.
In the Linux kernel, the following vulnerability has been resolved: ASoC: sti: use managed regmap_field allocations The regmap_field objects allocated at player init are never freed and may leak resources if the driver is removed. Switch to devm_regmap_field_alloc() to automatically limit the lifetime of the allocations the lifetime of the device.
In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: qdsp6: topology: check widget type before accessing data Check widget type before accessing the private data, as this could a virtual widget which is no associated with a dsp graph, container and module. Accessing witout check could lead to incorrect memory access.
In the Linux kernel, the following vulnerability has been resolved: gfs2: prevent NULL pointer dereference during unmount When flushing out outstanding glock work during an unmount, gfs2_log_flush() can be called when sdp->sd_jdesc has already been deallocated and sdp->sd_jdesc is NULL. Commit 35264909e9d1 ("gfs2: Fix NULL pointer dereference in gfs2_log_flush") added a check for that to gfs2_log_flush() itself, but it missed the sdp->sd_jdesc dereference in gfs2_log_release(). Fix that.
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix use-after-free bugs in mt7915_mac_dump_work() When the mt7915 pci chip is detaching, the mt7915_crash_data is released in mt7915_coredump_unregister(). However, the work item dump_work may still be running or pending, leading to UAF bugs when the already freed crash_data is dereferenced again in mt7915_mac_dump_work(). The race condition can occur as follows: CPU 0 (removal path) | CPU 1 (workqueue) mt7915_pci_remove() | mt7915_sys_recovery_set() mt7915_unregister_device() | mt7915_reset() mt7915_coredump_unregister() | queue_work() vfree(dev->coredump.crash_data) | mt7915_mac_dump_work() | crash_data-> // UAF Fix this by ensuring dump_work is properly canceled before the crash_data is deallocated. Add cancel_work_sync() in mt7915_unregister_device() to synchronize with any pending or executing dump work.
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix use-after-free bugs in mt7996_mac_dump_work() When the mt7996 pci chip is detaching, the mt7996_crash_data is released in mt7996_coredump_unregister(). However, the work item dump_work may still be running or pending, leading to UAF bugs when the already freed crash_data is dereferenced again in mt7996_mac_dump_work(). The race condition can occur as follows: CPU 0 (removal path) | CPU 1 (workqueue) mt7996_pci_remove() | mt7996_sys_recovery_set() mt7996_unregister_device() | mt7996_reset() mt7996_coredump_unregister() | queue_work() vfree(dev->coredump.crash_data) | mt7996_mac_dump_work() | crash_data-> // UAF Fix this by ensuring dump_work is properly canceled before the crash_data is deallocated. Add cancel_work_sync() in mt7996_unregister_device() to synchronize with any pending or executing dump work.
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cadence: cdns-mhdp8546-core: Set the mhdp connector earlier in atomic_enable() In case if we get errors in cdns_mhdp_link_up() or cdns_mhdp_reg_read() in atomic_enable, we will go to cdns_mhdp_modeset_retry_fn() and will hit NULL pointer while trying to access the mutex. We need the connector to be set before that. Unlike in legacy cases with flag !DRM_BRIDGE_ATTACH_NO_CONNECTOR, we do not have connector initialised in bridge_attach(), so add the mhdp->connector_ptr in device structure to handle both cases with DRM_BRIDGE_ATTACH_NO_CONNECTOR and !DRM_BRIDGE_ATTACH_NO_CONNECTOR, set it in atomic_enable() earlier to avoid possible NULL pointer dereference in recovery paths like modeset_retry_fn() with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set.
In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished irq_prepare_bcn_tasklet The irq_prepare_bcn_tasklet is initialized in rtl_pci_init() and scheduled when RTL_IMR_BCNINT interrupt is triggered by hardware. But it is never killed in rtl_pci_deinit(). When the rtlwifi card probe fails or is being detached, the ieee80211_hw is deallocated. However, irq_prepare_bcn_tasklet may still be running or pending, leading to use-after-free when the freed ieee80211_hw is accessed in _rtl_pci_prepare_bcn_tasklet(). Similar to irq_tasklet, add tasklet_kill() in rtl_pci_deinit() to ensure that irq_prepare_bcn_tasklet is properly terminated before the ieee80211_hw is released. The issue was identified through static analysis.
In the Linux kernel, the following vulnerability has been resolved: net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf sixpack_receive_buf() does not properly skip bytes with TTY error flags. The while loop iterates through the flags buffer but never advances the data pointer (cp), and passes the original count (including error bytes) to sixpack_decode(). This causes sixpack_decode() to process bytes that should have been skipped due to TTY errors. The TTY layer does not guarantee that cp[i] holds a meaningful value when fp[i] is set, so passing those positions to sixpack_decode() results in KMSAN reporting an uninit-value read. Fix this by processing bytes one at a time, advancing cp on each iteration, and only passing valid (non-error) bytes to sixpack_decode(). This matches the pattern used by slip_receive_buf() and mkiss_receive_buf() for the same purpose.
In the Linux kernel, the following vulnerability has been resolved: bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb bpf_prog_test_run_skb() calls eth_type_trans() first and then uses skb->protocol to initialize sk family and address fields for the test run. For IPv4 and IPv6 packets, it may access ip_hdr(skb) or ipv6_hdr(skb) even when the provided test input only contains an Ethernet header. Reject the input earlier if the Ethernet frame carries IPv4/IPv6 EtherType but the L3 header is too short. Fold the IPv4/IPv6 header length checks into the existing protocol switch and return -EINVAL before accessing the network headers.
In the Linux kernel, the following vulnerability has been resolved: powerpc/pgtable-frag: Fix bad page state in pte_frag_destroy powerpc uses pt_frag_refcount as a reference counter for tracking it's pte and pmd page table fragments. For PTE table, in case of Hash with 64K pagesize, we have 16 fragments of 4K size in one 64K page. Patch series [1] "mm: free retracted page table by RCU" added pte_free_defer() to defer the freeing of PTE tables when retract_page_tables() is called for madvise MADV_COLLAPSE on shmem range. [1]: https://lore.kernel.org/all/7cd843a9-aa80-14f-5eb2-33427363c20@google.com/ pte_free_defer() sets the active flag on the corresponding fragment's folio & calls pte_fragment_free(), which reduces the pt_frag_refcount. When pt_frag_refcount reaches 0 (no active fragment using the folio), it checks if the folio active flag is set, if set, it calls call_rcu to free the folio, it the active flag is unset then it calls pte_free_now(). Now, this can lead to following problem in a corner case... [ 265.351553][ T183] BUG: Bad page state in process a.out pfn:20d62 [ 265.353555][ T183] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x20d62 [ 265.355457][ T183] flags: 0x3ffff800000100(active|node=0|zone=0|lastcpupid=0x7ffff) [ 265.358719][ T183] raw: 003ffff800000100 0000000000000000 5deadbeef0000122 0000000000000000 [ 265.360177][ T183] raw: 0000000000000000 c0000000119caf58 00000000ffffffff 0000000000000000 [ 265.361438][ T183] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set [ 265.362572][ T183] Modules linked in: [ 265.364622][ T183] CPU: 0 UID: 0 PID: 183 Comm: a.out Not tainted 6.18.0-rc3-00141-g1ddeaaace7ff-dirty #53 VOLUNTARY [ 265.364785][ T183] Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) 0x801200 0xf000006 of:SLOF,git-ee03ae pSeries [ 265.364908][ T183] Call Trace: [ 265.364955][ T183] [c000000011e6f7c0] [c000000001cfaa18] dump_stack_lvl+0x130/0x148 (unreliable) [ 265.365202][ T183] [c000000011e6f7f0] [c000000000794758] bad_page+0xb4/0x1c8 [ 265.365384][ T183] [c000000011e6f890] [c00000000079c020] __free_frozen_pages+0x838/0xd08 [ 265.365554][ T183] [c000000011e6f980] [c0000000000a70ac] pte_frag_destroy+0x298/0x310 [ 265.365729][ T183] [c000000011e6fa30] [c0000000000aa764] arch_exit_mmap+0x34/0x218 [ 265.365912][ T183] [c000000011e6fa80] [c000000000751698] exit_mmap+0xb8/0x820 [ 265.366080][ T183] [c000000011e6fc30] [c0000000001b1258] __mmput+0x98/0x300 [ 265.366244][ T183] [c000000011e6fc80] [c0000000001c81f8] do_exit+0x470/0x1508 [ 265.366421][ T183] [c000000011e6fd70] [c0000000001c95e4] do_group_exit+0x88/0x148 [ 265.366602][ T183] [c000000011e6fdc0] [c0000000001c96ec] pid_child_should_wake+0x0/0x178 [ 265.366780][ T183] [c000000011e6fdf0] [c00000000003a270] system_call_exception+0x1b0/0x4e0 [ 265.366958][ T183] [c000000011e6fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec The bad page state error occurs when such a folio gets freed (with active flag set), from do_exit() path in parallel. ... this can happen when the pte fragment was allocated from this folio, but when all the fragments get freed, the pte_frag_refcount still had some unused fragments. Now, if this process exits, with such folio as it's cached pte_frag in mm->context, then during pte_frag_destroy(), we simply call pagetable_dtor() and pagetable_free(), meaning it doesn't clear the active flag. This, can lead to the above bug. Since we are anyway in do_exit() path, then if the refcount is 0, then I guess it should be ok to simply clear the folio active flag before calling pagetable_dtor() & pagetable_free().