Nixpkgs security tracker

Login with GitHub
⚠️ You are using a production deployment that is still only suitable for demo purposes. Any work done in this might be wiped later without notice.

Dismissed suggestions

These automatic suggestions were dismissed after initial triaging.

to select a suggestion for revision.

View:
Compact
Detailed
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
arm64: Reserve an extra page for early kernel mapping

In the Linux kernel, the following vulnerability has been resolved: arm64: Reserve an extra page for early kernel mapping The final part of [data, end) segment may overflow into the next page of init_pg_end[1] which is the gap page before early_init_stack[2]: [1] crash_arm64_v9.0.1> vtop ffffffed00601000 VIRTUAL PHYSICAL ffffffed00601000 83401000 PAGE DIRECTORY: ffffffecffd62000 PGD: ffffffecffd62da0 => 10000000833fb003 PMD: ffffff80033fb018 => 10000000833fe003 PTE: ffffff80033fe008 => 68000083401f03 PAGE: 83401000 PTE PHYSICAL FLAGS 68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN) PAGE PHYSICAL MAPPING INDEX CNT FLAGS fffffffec00d0040 83401000 0 0 1 4000 reserved [2] ffffffed002c8000 (r) __pi__data ffffffed0054e000 (d) __pi___bss_start ffffffed005f5000 (b) __pi_init_pg_dir ffffffed005fe000 (b) __pi_init_pg_end ffffffed005ff000 (B) early_init_stack ffffffed00608000 (b) __pi__end For 4K pages, the early kernel mapping may use 2MB block entries but the kernel segments are only 64KB aligned. Segment boundaries that fall within a 2MB block therefore require a PTE table so that different attributes can be applied on either side of the boundary. KERNEL_SEGMENT_COUNT still correctly counts the five permanent kernel VMAs registered by declare_kernel_vmas(). However, since commit 5973a62efa34 ("arm64: map [_text, _stext) virtual address range non-executable+read-only"), the early mapper also maps [_text, _stext) separately from [_stext, _etext). This adds one more early-only split and can require one more page-table page than the existing EARLY_SEGMENT_EXTRA_PAGES allowance reserves. Increase the 4K-page early mapping allowance by one page to cover that additional split. [catalin.marinas@arm.com: rewrote part of the commit log] [catalin.marinas@arm.com: expanded the code comment]

Affected products

Linux
  • ==88025faf2aa08c7468d68d8cb31a53b55aae6ee0
  • <4d8e74ad4585672489da6145b3328d415f50db82
  • =<*
  • <6.12.91
  • <dcb89deed40ba55ff7020061712fdabf098cc2cc
  • =<7.0.*
  • <6.18
  • =<6.18.*
  • <6.18
  • =<6.12.*
  • <a4ff33053da0a34b14abb5c96dc5a48379e26fce
  • <9fe9e3acaa14921b0cf0d6cc2de5b562499bf721
  • ==6.18
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: mt76: mt7921: Place upper limit on station AID

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: Place upper limit on station AID Any station configured with an AID over 20 causes a firmware crash. This situation occurred in our testing using an AP interface on 7922 hardware, with a modified hostapd, sourced from Mediatek's OpenWRT feeds. In stock hostapd, station AIDs begin counting at 1, and this configuration is prevented with an upper limit on associated stations. However, the modified hostapd began allocation at 65, which caused the firmware to crash. This fix does not allow these AIDs to work, but will prevent the firmware crash. This crash was only seen on IFTYPE_AP interfaces, and the fix does not appear to have an effect on IFTYPE_STATION behavior.

Affected products

Linux
  • =<*
  • <4d0bf21e3e20619d51d06c0c36207aabab8b712c
  • <5.12
  • =<7.0.*
  • =<6.18.*
  • <6dbe70f9ef14d8ac1c24bf19fd9510978a3ab952
  • <35835ff71e6e618155578b8e3905597edd5f601c
  • <1a4b802afe15c5b33b2dcb37a594aba2fa215d52
  • =<6.12.*
  • ==5.12
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
f2fs: protect extension_list reading with sb_lock in f2fs_sbi_show()

In the Linux kernel, the following vulnerability has been resolved: f2fs: protect extension_list reading with sb_lock in f2fs_sbi_show() In f2fs_sbi_show(), the extension_list, extension_count and hot_ext_count are read without holding sbi->sb_lock. If a concurrent sysfs store modifies the extension list via f2fs_update_extension_list(), the show path may read inconsistent count and array contents, potentially leading to out-of-bounds access or displaying stale data. Fix this by holding sb_lock around the entire extension list read and format operation.

Affected products

Linux
  • <4b3a1bf4c2ffd4c9595d900ead78c9035894a025
  • <cea15f66b7b68b2c50943a6660e0692c6635e4eb
  • <d0e877810baf613b018fd9747440b9d4d9db1428
  • =<6.6.*
  • =<*
  • <5909bedbed38c558bee7cb6758ceedf9bc3a9194
  • =<7.0.*
  • =<6.18.*
  • <ea3ab43a1f3cf2c7cecd75c8be1ee99a5e94a92e
  • <d3ff0c121bbaef026df6248ab7ef6f0b068b0647
  • ==4.17
  • =<6.1.*
  • =<6.12.*
  • <4.17
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_tx_check_aggr()

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_tx_check_aggr() Move the NULL check for 'sta' before dereferencing it to prevent a possible crash.

Affected products

Linux
  • <93d0694fb56de4628a921244d7f100c28acd2def
  • <6.11
  • =<*
  • ==6.11
  • <83ae3a18ba957257b4c406273d2da2caeea2b439
  • =<7.0.*
  • =<6.18.*
  • <28ed0b61f67386c0ba1213227d350005000240fd
  • <b0332428a8d4cf93752eda9e2b0d5585525e689f
  • =<6.12.*
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2025-11919
9.6 CRITICAL
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Changed (C)
  • Confidentiality (C): High (H)
  • Integrity (I): High (H)
  • Availability (A): None (N)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Changed (C)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): None (N)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Unprotected temporary directories in Wolfram Cloud may result in privilege escalation

The default JVM can access files and directories under `/tmp/` including the `$TemporaryDirectory` of other users on the same cloud instance (`/tmp/UserTemporaryFiles/`). The `-init` file for the the JVM initialization exists in the vulnerable directory during the startup of the JVM. An attacker with access to the shared `/tmp/` space can preemptively create or replace `.jar` files or directories (via the `-init` file) that the victim JVM will resolve first in its classpath. By strategically placing a malicious version of a commonly used library (e.g., `commons-io`) in a location that is included in the classpath before the legitimate version, an attacker can cause the JVM to load the malicious class during startup, thereby executing the attacker's code.

Affected products

Cloud
  • ==14.2
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty()

In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty() nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped. However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering the WARN_ON(ret == -ENOENT). Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the beginning of each iteration. [ryusuke: slightly modified the commit message and comments for accuracy]

Affected products

Linux
  • <65e07964b4b2daf9a54e686cf0fa72d74a9648a8
  • <9472d37799a0b9ff9b99639f35961ac2f0b3c9be
  • <e0a0c4903cbba351f0f5b5d104960d3a5b23202f
  • <94094e70fe292c9566502772d4d4d6d6a99204b1
  • ==2.6.30
  • <2.6.30
  • =<6.6.*
  • <e5ff0ba4b6983cdbcc826efc201e7179ece5d46f
  • =<*
  • =<7.0.*
  • =<6.18.*
  • <be3e5d10643d3be1cbac9d9939f220a99253f980
  • =<5.15.*
  • =<5.10.*
  • =<6.12.*
  • <b88f905d4449b70da6bda547be546e365e44352e
  • =<6.1.*
  • <4525658002be3ad310b16bf8db48c8adb6a55d32
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind

In the Linux kernel, the following vulnerability has been resolved: net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind syzbot reported a kernel BUG triggered from pn_socket_sendmsg() via pn_socket_autobind(): kernel BUG at net/phonet/socket.c:213! RIP: 0010:pn_socket_autobind net/phonet/socket.c:213 [inline] RIP: 0010:pn_socket_sendmsg+0x240/0x250 net/phonet/socket.c:421 Call Trace: sock_sendmsg_nosec+0x112/0x150 net/socket.c:797 __sock_sendmsg net/socket.c:812 [inline] __sys_sendto+0x402/0x590 net/socket.c:2280 ... pn_socket_autobind() calls pn_socket_bind() with port 0 and, on -EINVAL, assumes the socket was already bound and asserts that the port is non-zero: err = pn_socket_bind(sock, ..., sizeof(struct sockaddr_pn)); if (err != -EINVAL) return err; BUG_ON(!pn_port(pn_sk(sock->sk)->sobject)); return 0; /* socket was already bound */ However pn_socket_bind() also returns -EINVAL when sk->sk_state is not TCP_CLOSE, even when the socket has never been bound and pn_port() is still 0. In that case the BUG_ON() fires and panics the kernel from a user-triggerable path. Treat the "bind returned -EINVAL but pn_port() is still 0" case as a regular error and propagate -EINVAL to the caller instead of crashing. Existing callers already translate a non-zero return from pn_socket_autobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here only changes behaviour from panic to a normal errno.

Affected products

Linux
  • <5b0c911bcdbd982f7748d11c0b39ec5808eae2de
  • =<*
  • <6db58ee730bf434d1afca91b91826e26688856ed
  • <2.6.28
  • =<7.0.*
  • ==2.6.28
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-57319
7.1 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): Required (R)
  • Scope (S): Changed (C)
  • Confidentiality (C): Low (L)
  • Integrity (I): Low (L)
  • Availability (A): Low (L)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): Required (R)
  • Modified Confidentiality (MC): Low (L)
  • Modified Scope (MS): Changed (C)
  • Modified Integrity (MI): Low (L)
  • Modified Availability (MA): Low (L)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
WordPress FOX plugin <= 1.4.8 - Cross Site Scripting (XSS) vulnerability

Unauthenticated Cross Site Scripting (XSS) in FOX <= 1.4.8 versions.

Affected products

woocommerce-currency-switcher
  • =<1.4.8
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
scsi: sg: Resolve soft lockup issue when opening /dev/sgX

In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Resolve soft lockup issue when opening /dev/sgX The parameter def_reserved_size defines the default buffer size reserved for each Sg_fd and should be restricted to a range between 0 and 1,048,576 (see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although the function sg_proc_write_dressz enforces this limit, it is possible to bypass it by directly modifying the module parameter as shown below, which then causes a soft lockup: echo -1 > /sys/module/sg/parameters/def_reserved_size exec 4<> /dev/sg0 watchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537] Modules loaded: CPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134, PREEMPT disabled Hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version 1.16.1-2.fc37 dated 04/01/2014 ... Call Trace: sg_build_reserve+0x5c/0xa0 sg_add_sfp+0x168/0x270 sg_open+0x16e/0x340 chrdev_open+0xbe/0x230 do_dentry_open+0x175/0x480 vfs_open+0x34/0xf0 do_open+0x265/0x3d0 path_openat+0x110/0x290 do_filp_open+0xc3/0x170 do_sys_openat2+0x71/0xe0 __x64_sys_openat+0x6d/0xa0 do_syscall_64+0x62/0x310 entry_SYSCALL_64_after_hwframe+0x76/0x7e The fix is to use module_param_cb to validate and reject invalid values assigned to def_reserved_size.

Affected products

Linux
  • =<6.6.*
  • =<*
  • <9676ca7b1ef31a3a65b3e61e7ce3b54ce7364202
  • <2.6.19
  • <d06a310b45e153872033dd0cf19d5a2279121099
  • <fe671d3c84ffb1b763d590c25195755adeaadaba
  • =<7.0.*
  • =<6.12.*
  • =<6.18.*
  • =<5.15.*
  • <c5f4a211e82d04ccc1809311322c47023bbe66e2
  • <1afd963fcd963db0dc5d47df6dfcf010c9c4647e
  • ==2.6.19
  • =<5.10.*
  • <feade299e932967de27519338d41de348fb5b061
  • <3d74e0654ac908c65a8f20373091826fe43b1363
  • =<6.1.*
  • <c47ccfb3d80dfed522ca06a5954ac97488d78c5a
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
padata: Put CPU offline callback in ONLINE section to allow failure

In the Linux kernel, the following vulnerability has been resolved: padata: Put CPU offline callback in ONLINE section to allow failure syzbot reported the following warning: DEAD callback error for CPU1 WARNING: kernel/cpu.c:1463 at _cpu_down+0x759/0x1020 kernel/cpu.c:1463, CPU#0: syz.0.1960/14614 at commit 4ae12d8bd9a8 ("Merge tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux") which tglx traced to padata_cpu_dead() given it's the only sub-CPUHP_TEARDOWN_CPU callback that returns an error. Failure isn't allowed in hotplug states before CPUHP_TEARDOWN_CPU so move the CPU offline callback to the ONLINE section where failure is possible.

Affected products

Linux
  • =<6.6.*
  • =<*
  • =<7.0.*
  • =<6.18.*
  • <a6d44f477000c6352de6b05e9e276e62083e5fbf
  • =<6.12.*
  • <5.5
  • <65dae8b34f0810f3fa9f77c4c63650cd20820693
  • <c8c4a2972f83c8b68ff03b43cecdb898939ff851
  • ==0685dfa0a2ff7635c0b64f7b7f0fafbf1c3e0c14
  • <5.6
  • =<6.1.*
  • <3e6c08dd97dcd22a00aee469e0adfa819071d80e
  • ==5.6
  • <9afe53f14a2aae8c4beb30e5ea51641a34f1a3d3
  • <4.20
  • ==3f4d3d010477365ee1aefedc3ad52563740b777e
  • ==2b1207801c393a5e9af2fbac2dd8b0377d8ae63a
  • <5a9f29a3e076b637d2234093e57989cf755ded5b
  • <5.6