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, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
accel/ivpu: Add bounds checks for firmware log indices

In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Add bounds checks for firmware log indices Add validation that read and write indices in the firmware log buffer are within valid bounds (< data_size) before using them. If out-of-bounds indices are encountered (from firmware), clamp them to safe values instead of proceeding with invalid offsets. This prevents potential out-of-bounds buffer access when firmware supplies invalid log indices.

Affected products

Linux
  • =<6.18.*
  • <6.12.94
  • =<*
  • <dd1311bcf0e62f0c515115f46a3813370f4a4bb1
  • =<7.0.*
  • =<6.12.*
  • ==6.13
  • <5961c703414048f46818be8bbb11075a9a63fb4e
  • <6.13
  • <8ec70c0dbdf04392a26e03e38798a373934177be
  • <535da9ad8420c3b686a642403d4147ff220255fd
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: nft_exthdr: fix register tracking for F_PRESENT flag

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.

Affected products

Linux
  • ==4.11
  • <772cecf198da732faebb5dcfc46d66a505be8495
  • <46fc15a044e9938e7ea77786fb37edd2cd74f031
  • =<6.1.*
  • <78069a6d8bc86c9e036eb82c2af4a19cc1871a53
  • <19748967d59c31d24d21d40b728570788310b237
  • <cd513e43b4b2bd1de39e2367bc4261c699a8652f
  • =<6.6.*
  • =<6.18.*
  • <8738b1b6d0e639ca1fc0f61516afd3557ac4ecc6
  • <4.11
  • =<5.15.*
  • =<6.12.*
  • =<7.0.*
  • <f08fb3d42fd3aad0b7a263da3ac3ebaf0845e265
  • =<*
  • =<5.10.*
  • <67b27434c43b68a97becda98c9f0c8cf6cba2134
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ALSA: timer: Fix UAF at snd_timer_user_params()

In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: Fix UAF at snd_timer_user_params() At releasing a timer object, e.g. when a userspace timer (CONFIG_SND_UTIMER) gets closed and snd_timer_free() is called, it tries to detach the timer instances and release the resources. However, it's still possible that other in-flight tasks are holding the timer instance where the to-be-deleted timer object is associated, and this may lead to racy accesses. Fortunately, most of ioctls dealing with the timer instance list already have the protection with register_mutex, and this also avoids such races. But, SNDRV_TIMER_IOCTL_PARAMS isn't protected, hence the concurrent ioctl may lead to use-after-free. This patch just adds the guard with register_mutex to protect snd_timer_user_params() for covering the code path as a quick workaround. It's no hot-path but rather a rarely issued ioctl, so the performance penalty doesn't matter.

Affected products

Linux
  • <6.1.176
  • =<6.6.*
  • <5.10.259
  • <306427adf9b97e29e5958cb9cf3096c6151fc9ff
  • <5.15.210
  • =<6.18.*
  • <e2331730175f74169046d2af8db1b47243df7c7a
  • <b2214914e461d0466548a52dfe4f4ee8ce362276
  • =<5.10.*
  • =<*
  • <6.12.94
  • =<6.1.*
  • <38034d04d4a75bbca01df2b313ced0bcd0fa3242
  • <6.6.143
  • <117743d62e1225e208568a3ffc2c07214f1347cb
  • <92ad2d7f80cad43b046f093e808e11fe919d304a
  • <3d39da65b5c422c5e5afb7d5651b0698d060a827
  • =<5.15.*
  • =<6.12.*
  • =<7.0.*
  • <053a401b592be424fea9d57c789f66cd5d8cec11
  • <7.0.13
  • <6.18.36
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Bluetooth: fix memory leak in error path of hci_alloc_dev()

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.

Affected products

Linux
  • <5.11
  • <6.1.176
  • =<6.6.*
  • <6.16
  • <bc2efe73c194a74839d7cf57b63880d97e21d309
  • <5.15.210
  • =<6.18.*
  • ==0e5c144c557df910ab64d9c25d06399a9a735e65
  • ==6.16
  • <c016118b9e51eeaf5bc93850d4c455a3b583c0aa
  • <0622e527a31d4b44737fed5c1a2ac1fc2cfb5184
  • =<*
  • <6.12.94
  • =<6.1.*
  • ==dd4becd3fd4102696e1c15e6d260a1712a2d8685
  • <ce4b4cac3c5749b6aa75e62e2991ae2263f2f889
  • <6.6.143
  • <5b7dfca6f852e6b9d809fd0263b5427cc9fb33fd
  • =<5.15.*
  • =<6.12.*
  • =<7.0.*
  • <37b3009bf5976e8ab77c8b9a9bc3bbd7ff49e37f
  • <f82799407a50af7bcacacf09cc9b279af8fe9b81
  • <6.16
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
USB: serial: io_ti: fix heap overflow in get_manuf_info()

In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]

Affected products

Linux
  • ==2.6.12
  • =<5.10.*
  • =<6.18.*
  • =<6.1.*
  • =<*
  • <e168db91442b94e64fa82a7dd297983d48ea5cc0
  • <b849f30d1a9e66aae6b715aaef66e427390cb081
  • =<6.6.*
  • =<5.15.*
  • =<6.12.*
  • =<7.0.*
  • <561edb021486e6723d841926aa4b48097da06190
  • <f96cf7bf9fbf15d7fcf0c91fec47ba8a010369ea
  • <183c1076eca43bbb3e7bdf597456f91d81c73e74
  • <cfd634f6dfd40c49a84f9bddc2867a80e2e2623a
  • <2.6.12
  • <d214d2341d4f9f447e36a7d012cdf6a6631a55f1
  • <d92f17af7097d10bdeddf26f66f34b354104b277
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
tee: shm: fix shm leak in register_shm_helper()

In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead.

Affected products

Linux
  • <26682f5efc276e3ad96d102019472bfbf03833b2
  • =<6.18.*
  • ==6.8
  • =<7.0.*
  • <6.8
  • =<6.12.*
  • <dbf779db927414f5b37c1f666013e9b48a88cfde
  • <c10c9c48b2903f41ed4c532043b0576e86228236
  • <4277759906b44d923a38c8f59f5576501b187b0d
  • =<*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ksmbd: fix NULL-deref of opinfo->conn in oplock/lease break notifiers

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix NULL-deref of opinfo->conn in oplock/lease break notifiers smb2_oplock_break_noti() and smb2_lease_break_noti() read opinfo->conn into a local with neither READ_ONCE() nor a NULL check. Both run from oplock_break() after opinfo_get_list() has dropped ci->m_lock, so a concurrent SMB2 LOGOFF (session_fd_check()) can set op->conn = NULL under ci->m_lock within that window. ksmbd_conn_r_count_inc(conn) then writes through NULL at offset 0xc4 -- a remotely triggerable oops. Guard both reads the way compare_guid_key() already does: read opinfo->conn with READ_ONCE() and return early if it is NULL, before allocating the work struct so nothing leaks. A NULL conn means the client is gone and the break is moot, so return 0; oplock_break() treats that as success and runs the normal teardown.

Affected products

Linux
  • =<6.18.*
  • ==6.9
  • <1ff58dcfcab434ebb51649da33774fbb8e1f7b67
  • <6.9
  • <e735dbd489e3ea02be78dba991056fe1138be51e
  • <75e33deda658c1ab3a9336cbdb1436536f9b3660
  • =<6.6.*
  • =<6.12.*
  • <6.6.143
  • =<7.0.*
  • <b003086d76968298f22e7cf62239833b5a3a06b1
  • <945a86b21b40fb17183f5b27461baa6f03e2467f
  • =<*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups

In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.

Affected products

Linux
  • =<6.18.*
  • <0b59d0946913a0df7d1a033013e259e9b6a76546
  • ==6.8
  • =<7.0.*
  • <6.8
  • =<6.12.*
  • <90b629269088a9fe24a02c032be9f08357f47873
  • <60ebeb23eaf3d7fd2e0551fe304309305e31d424
  • <ae7676952790f421c40918e2586a2c9f12a682b6
  • =<*
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-57455
4.0 MEDIUM
  • CVSS version (CVSS): 4.0
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): High (H)
  • Attack Requirement (AT): None (N)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): Active (A)
  • Vulnerable System Impact Confidentiality (VC): High (H)
  • Vulnerable System Impact Integrity (VI): High (H)
  • Vulnerable System Impact Availability (VA): High (H)
  • Subsequent System Impact Confidentiality (SC): None (N)
  • Subsequent System Impact Integrity (SI): None (N)
  • Subsequent System Impact Availability (SA): None (N)
  • Exploit Maturity (E): Unreported (U)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): High (H)
  • Modified Attack Requirement (MAT): None (N)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): Active (A)
  • Modified Vulnerable System Impact Confidentiality (MVC): High (H)
  • Modified Vulnerable System Impact Integrity (MVI): High (H)
  • Modified Vulnerable System Impact Availability (MVA): High (H)
  • Modified Subsequent System Impact Confidentiality (MSC): Negligible (N)
  • Modified Subsequent System Impact Integrity (MSI): Negligible (N)
  • Modified Subsequent System Impact Availability (MSA): Negligible (N)
  • Safety (S): Not Defined (X)
  • Automatable (AU): Not Defined (X)
  • Recovery (R): Not Defined (X)
  • Value Density (V): Not Defined (X)
  • Vulnerability Response Effort (RE): Not Defined (X)
  • Provider Urgency (U): Not Defined (X)
  • Confidentiality Req. (CR): Not Defined (X)
  • Integrity Req. (IR): Not Defined (X)
  • Availability Req. (AR): Not Defined (X)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Vim: Stack out-of-bounds write in `spell_soundfold_sofo()` via an over-length `soundfold()` argument

Vim is an open source, command line text editor. Prior to 9.2.0698, the single-byte branch of spell_soundfold_sofo() in src/spell.c translates a word through a spell file's SOFO (sound-folding) byte map into a caller-owned result buffer. Its copy loop advances the output index ri with no upper bound and terminates only on the input NUL, writing one byte per input byte into the MAXWLEN-element stack buffer the caller provides. A word longer than MAXWLEN, passed to soundfold() (or reached via sound-based spell suggestion) while a SOFO-based spell language is active, therefore writes past the end of that buffer. This is a stack out-of-bounds write that corrupts the call frame and crashes the editor. This vulnerability is fixed in 9.2.0698.

Affected products

vim
  • ==< 9.2.0698
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/vc4: fix krealloc() memory leak

In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().

Affected products

Linux
  • <e0ce103e89d61eef70edc1d1ae3bfd4c0aacbc2e
  • =<6.18.*
  • =<6.1.*
  • <c034aa0b1ba5f49cbdf8ef193d6ec714d74aac27
  • <4fc692dc6df5bc777cc1bcebf95179e28594875f
  • =<6.6.*
  • <4.8
  • =<5.15.*
  • =<6.12.*
  • =<7.0.*
  • <fd87d6966041e33ef7d2e5dc59f9a52b71c6ae5f
  • ==4.8
  • <5d563a5da8717629ae72f9eadf1e0e340bd1658b
  • <02f5e4db57c0cdd7bac89d503b301a093a0fa95c
  • <30165a09f76eaf34951c818eb5d9d6e4771d76f6
  • =<*