Nixpkgs security tracker

Login with GitHub

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 4 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
smb: client: fix double-free in SMB2_open() replay

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix double-free in SMB2_open() replay A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_open_init() fails before the next send, cleanup retains the previous buffer type and frees that response again. Reset response bookkeeping before each attempt to prevent the stale free.

Affected products

Linux
  • <ff2d30927bc3bf3c629f0768d2068096e64ef5ce
  • <6.8
  • =<6.18.*
  • =<6.12.*
  • <6.6.145
  • =<7.1.*
  • <14498ff5ce0f272ce0ef988721413e06b7038972
  • <b55e182f2324bc6a604c21a47aa6c448f719a532
  • =<*
  • ==6.8
  • <3196b5192f246df4272072f61a2f4a3e9967f55d
  • =<6.6.*
  • <02bc2896bdc3e29362d6e40d404006944a159c25
Dismissed
(max. allowed matches exceeded)
created 4 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
mm: page_ext: add count limit to page_ext_iter_next to prevent invalid PFN access

In the Linux kernel, the following vulnerability has been resolved: mm: page_ext: add count limit to page_ext_iter_next to prevent invalid PFN access The page_ext iteration API does not validate if the PFN still belongs to a valid section while advancing the iterator. When dynamically adding memory in the hotplug path, it can lead to a NULL pointer dereference during page_ext_lookup at the boundary of the last valid section when iterator count equals __pgcount. The for_each_page_ext() macro calls page_ext_iter_next() as its loop increment. for_each_page_ext() does a "__page_ext = page_ext_iter_next(&__iter)" at the end. This causes page_ext_iter_next() to increment iter->index past __pgcount and call page_ext_lookup(start_pfn + __pgcount). During memory hotplug (online), the PFN at start_pfn + __pgcount may belong to a section that has not yet been initialized, causing page_ext_lookup() to trigger a NULL pointer dereference. [ 14.555124][ T846] Call trace: [ 14.555125][ T846] lookup_page_ext+0x6c/0x108 (P) [ 14.555127][ T846] page_ext_lookup+0x30/0x3c [ 14.555129][ T846] __reset_page_owner+0x11c/0x260 [ 14.571201][ T846] __free_pages_ok+0x5e8/0x8e0 [ 14.571204][ T846] __free_pages_core+0x78/0xf0 [ 14.571206][ T846] generic_online_page+0x14/0x24 [ 14.597782][ T846] online_pages+0x178/0x30c [ 14.597784][ T846] memory_block_change_state+0x284/0x32c [ 14.597787][ T846] memory_subsys_online+0x4c/0x64 [ 14.597789][ T846] device_online+0x88/0xb0 [ 14.597791][ T846] online_memory_block+0x30/0x40 [ 14.597793][ T846] walk_memory_blocks+0xac/0xe8 [ 14.597794][ T846] add_memory_resource+0x280/0x298 [ 14.656161][ T846] add_memory+0x60/0x98 Move the iteration boundary enforcement inside the iterator functions, so callers cannot inadvertently access beyond the requested range.

Affected products

Linux
  • <6.15
  • =<6.18.*
  • <377b1cd6bbcf327338cd951cc2fd74bc75540235
  • ==6.15
  • =<7.1.*
  • =<*
  • <8dcaa0f87a88d720d13106f3a306c6b61d189d86
  • <ffd017237cfe99e6e5602ab14179b0e6878a0840
Dismissed
(max. allowed matches exceeded)
created 4 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
hfs/hfsplus: zero-initialize buffer in hfs_bnode_read

In the Linux kernel, the following vulnerability has been resolved: hfs/hfsplus: zero-initialize buffer in hfs_bnode_read hfs_bnode_read() can return early without writing to the output buffer when is_bnode_offset_valid() fails or when check_and_correct_requested_ length() corrects the length to zero. Callers such as hfs_bnode_read_ u16() and hfs_bnode_read_u8() pass stack-allocated buffers and use the result unconditionally, leading to KMSAN uninit-value reports. Rather than initializing at each individual call site, zero the buffer at the start of hfs_bnode_read() before any validation checks. This ensures all callers in both hfs and hfsplus get a deterministic zero value regardless of which early-return path is taken.

Affected products

Linux
  • <5.10.261
  • <d5b45bad75cd2730b8452aed4d3b20a2b2a12576
  • ==6.17
  • <6.16
  • <0b189b2204f1a2612dc68f8d139fb5b80539e710
  • =<7.1.*
  • =<6.1.*
  • =<5.15.*
  • =<5.10.*
  • <d2afc7ecee476f9251dd87444f7fb6a424410922
  • <5.15.212
  • <6.12.96
  • <6.17
  • <34684a04777358b2b40ac729e54c8e45359e46b3
  • <6.17
  • ==fc7f732984ec91f30be3e574e0644066d07f2b78
  • <16ca053c2be5f4f3044dccf7fc19237dc820d394
  • <6.6.145
  • ==e7d2dc2421e821e4045775e6dc226378328de6f6
  • <f3461b84a4865d9b5e70fbb71da72ae044a3bcd2
  • =<6.6.*
  • <5.5
  • ==eec522fd0d28106b14a59ab2d658605febe4a3bb
  • <8f72fd25a57a457866350359ddd27a43caa62c95
  • <6.1.178
  • =<6.18.*
  • =<6.12.*
  • <d67aadee19ffdf3cc8520c5a4f4d5b2916d30baf
  • =<*
Dismissed
(max. allowed matches exceeded)
created 4 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ksmbd: use opener credentials for ADS I/O

In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for ADS I/O Alternate data streams are stored as xattrs. Unlike regular file I/O, their read and write paths therefore call VFS xattr helpers which recheck inode permissions and LSM policy using the current task credentials. Run ADS I/O with the credentials captured when the SMB handle was opened.

Affected products

Linux
  • <52a56cf53ec834c44ac1b4d16d585f26613ee5ce
  • =<6.18.*
  • <a8f5d39971bbad9340d49cd41b0e2da9452a649d
  • <6.12.96
  • <baa5e094886fffa7e6272edcb5e08be5ce28262c
  • =<6.12.*
  • =<7.1.*
  • =<*
  • <7.1.4
  • <2b4592cea214683de0f2ce6f8c22c097fb0ea1ab
  • <6.18.39
Dismissed
(max. allowed matches exceeded)
created 4 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
smb: client: reject overlapping data areas in SMB2 responses

In the Linux kernel, the following vulnerability has been resolved: smb: client: reject overlapping data areas in SMB2 responses Commit 53b7c271f06b ("smb: client: restrict implied bcc[0] exemption to responses without data area") restricted the implied bcc[0] length exception to responses without a data area. However, the overlap handling in __smb2_calc_size() clears data_length, which can make an invalid response appear to have no data area and so qualify for the exception. Track data area overlap separately and reject such responses before applying the length compatibility exceptions.

Affected products

Linux
  • <5.16
  • ==7.2-rc3
  • <8986c932905ea508d66da421eb2eb6e676ace1fe
  • <4a9d2657d3e05f6ed09c148cb127b4e58702275f
  • <fdafa1e68dc75045b7b617e6e7d2854950804d83
  • <5.11
  • <57cba95f0e97c6f6e45e6731da30aff091bd7460
  • ==8d0bbc78046d264bbf6a574ea6f9072258a43e35
  • ==b6a381c01e2ac98a48e32ac0f2a45bbadd9e26b0
  • =<*
  • <36bfa52459e45c0d5b668de2f1c91f6dc5c67775
  • <445ece263131780dee273d727a4d6f11934feec7
  • <7.2-rc3
Dismissed
(max. allowed matches exceeded)
created 4 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers

In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers Syzbot reported a hung task in nilfs_transaction_begin() where multiple tasks performing chmod() on a nilfs2 mount blocked for over 143 seconds waiting to acquire ns_segctor_sem for read: INFO: task syz.0.17:5918 blocked for more than 143 seconds. Call Trace: schedule+0x164/0x360 rwsem_down_read_slowpath+0x6d9/0x940 down_read+0x99/0x2e0 nilfs_transaction_begin+0x364/0x710 fs/nilfs2/segment.c:221 nilfs_setattr+0x124/0x2c0 fs/nilfs2/inode.c:921 notify_change+0xc1a/0xf40 chmod_common+0x273/0x4a0 do_fchmodat+0x12d/0x230 The writer holding ns_segctor_sem was a concurrent NILFS_IOCTL_CLEAN_SEGMENTS caller, stuck inside printk while emitting per-element warnings from nilfs_sufile_updatev(): __nilfs_msg+0x373/0x450 fs/nilfs2/super.c:78 nilfs_sufile_updatev+0x21c/0x6d0 fs/nilfs2/sufile.c:186 nilfs_sufile_freev fs/nilfs2/sufile.h:93 [inline] nilfs_free_segments fs/nilfs2/segment.c:1140 [inline] nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1261 [inline] nilfs_segctor_do_construct+0x1f55/0x76c0 nilfs_clean_segments+0x3bd/0xa50 nilfs_ioctl_clean_segments fs/nilfs2/ioctl.c:922 [inline] nilfs_ioctl+0x261f/0x2780 The root cause is that user-supplied segment numbers are not validated before nilfs_clean_segments() begins doing work; the range check on each segnum is performed deep inside the call chain by nilfs_sufile_updatev(), which emits a nilfs_warn() per invalid entry while still holding the segctor lock and the sufile mi_sem. Under load (repeated invocations across multiple mounts saturating the global printk path), the cumulative printk latency keeps ns_segctor_sem held long enough to trip the hung_task watchdog, blocking concurrent operations such as chmod() that need ns_segctor_sem for read. Fix by validating the contents of kbufs[4] in nilfs_clean_segments() immediately after acquiring ns_segctor_sem via nilfs_transaction_lock(). Holding ns_segctor_sem serializes the check against nilfs_ioctl_resize(), which can modify ns_nsegments, so the validation uses a consistent value. Out-of-range segment numbers are rejected with -EINVAL before any segment-cleaning work begins, so the bad entries never reach the per-element diagnostic path inside nilfs_sufile_updatev().

Affected products

Linux
  • =<5.10.*
  • =<6.18.*
  • <39607452b1400c7bf748f15122df4d058b768c5b
  • <2.6.31
  • <286f77d002a337735c0846d7480a82d9cda2aa31
  • ==2.6.31
  • =<5.15.*
  • =<6.12.*
  • <3ed388ec3b8922383d1e2d4432d7bd4cbbf8364e
  • <876c98e0fc65f071680c03c2e2ee3ef7ff9ca078
  • <0e7a690fe435f8d5ea3feb7c1d8d73ba7e8b8aa9
  • =<6.1.*
  • =<7.1.*
  • =<6.6.*
  • <0789f0a6710713254a08f3a7d2ecbb6d1cbcf0aa
  • =<*
  • <223463c488b0554212a94de971ea538eb2805fc7
  • <d26aef771b4f6923da9f89d6d5b70d8def5853de
Dismissed
(max. allowed matches exceeded)
created 4 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Bluetooth: L2CAP: validate option length before reading conf opt value

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: validate option length before reading conf opt value l2cap_get_conf_opt() derives the option length from the attacker-controlled opt->len field and immediately dereferences opt->val (as u8, get_unaligned_le16() or get_unaligned_le32(), or a raw pointer for the default case) before any caller has confirmed that opt->len bytes are present in the buffer. The callers (l2cap_parse_conf_req(), l2cap_parse_conf_rsp() and l2cap_conf_rfc_get()) only detect a malformed option afterwards, once the running length has gone negative, by which point the out-of-bounds read has already executed. An existing post-hoc length check keeps the garbage value from being consumed, so this is not a data leak in the current control flow. It is still a validate-after-use ordering bug: up to 4 bytes are read past the end of the buffer before it is known to contain them, and it is fragile to future changes in the callers. Fix it at the source. Pass the end of the buffer into l2cap_get_conf_opt() and refuse to touch opt->val unless the full option (header + value) fits. Each caller computes an end pointer once before the loop and checks the return value directly instead of inferring the error from a negative length.

Affected products

Linux
  • ==99665dcf6ff803351b5e658f3a929cb498561e36
  • ==2b59d36f22622c92c0b06aee7571f0a86a217188
  • <3.19
  • ==a556547bae00528f24b42786b41a14047db14b84
  • <7d871e969b941ce25653f7716203a0ea4d07ad4b
  • ==ac7c597c465eb09391e40febbe088bdad601080b
  • <3.17
  • ==78c2887130f1a7d1883195732be1b6cdab667487
  • =<7.1.*
  • =<6.1.*
  • ==ade4560e4fea198866e033fe1c02f063d6d7db2e
  • =<5.15.*
  • =<5.10.*
  • <4.20
  • <f70d4aa88068096f35d73e3a05eff33c0a16b9cd
  • <4.5
  • <98d93c226bdfaa79bbdd86981921d7f106374225
  • <4.15
  • <4.10
  • <5.1
  • <73abbaf91aa33da87c008fb62c148ade561bb606
  • =<6.6.*
  • <5.1
  • <cca81b4bc672604a84f6d224a55cc77ec7dee619
  • <687617555cedfb74c9e3cb85d759b908dcb17856
  • =<6.18.*
  • =<6.12.*
  • <996d3da39899aceb8f4910911a3f19a45a7d9d1b
  • ==15d6538a0d6e0f6de5116081a948cba7cc3e1d3d
  • ==5.1
  • =<*
  • <6b47bdaacfd0045687880177e0987055d8f4765a
Dismissed
(max. allowed matches exceeded)
created 4 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
crypto: ccp - Do not initialize SNP for SEV ioctls

In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Do not initialize SNP for SEV ioctls Sashiko notes: > if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this code path via /dev/sev ioctls (e.g., > SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN > execution for an active VM trigger a general protection fault and crash the > host? sev_move_to_init_state() is called for ioctls requiring only SEV firmware: SEV_PEK_GEN, SEV_PDH_GEN, SEV_PEK_CSR, SEV_PEK_CERT_IMPORT, and SEV_PDH_CERT_EXPORT. After the firmware command, it does SEV_SHUTDOWN on the SEV firmware. Since these commands do not require SNP to be initialized, skip it by calling __sev_platform_init_locked() which only initializes the SEV firmware. This way SNP is not Initialized at all, and HSAVE_PA is not cleared. The previous code saved any SEV initialization firmware error to init_args.error and then threw it away and hardcoded the return value of INVALID_PLATFORM_STATE regardless of the real firmware error. This patch changes it to surface the underlying error, which is hopefully both more useful and doesn't cause any problems. Note that it is still safe to call __sev_firmware_shutdown() directly: it calls __sev_snp_shutdown_locked(), which skips SNP shutdown if SNP was not initialized.

Affected products

Linux
  • <fb1758e74b8061aacfbce7bbb7a7cc650537e167
  • =<6.18.*
  • <6.12.96
  • ==6.16
  • =<6.12.*
  • <5181e88da99c3d1d41e25db3472a62b8d4b42cdd
  • =<7.1.*
  • =<*
  • <9e983d0a74a6a2348e4ce61647ec8a4dfbe198ac
  • <6.16
  • <d51207735e7c224cf591fa260c557a451a69a5cf
Dismissed
(max. allowed matches exceeded)
created 4 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ALSA: ymfpci: check snd_ctl_new1() return value

In the Linux kernel, the following vulnerability has been resolved: ALSA: ymfpci: check snd_ctl_new1() return value snd_ctl_new1() can return NULL when memory allocation fails. snd_ymfpci_create_spdif_controls() does not check the return value before dereferencing kctl->id.device, which can lead to a NULL pointer dereference. Add NULL checks after snd_ctl_new1() calls and return -ENOMEM if any fails.

Affected products

Linux
  • <02f33c2062c75e28abc7ad58ce86451cf3140455
  • <e64d170346d00b580c0043de3e5ccb3e331c47d4
  • <f6538a318947b627710b08a268bc80a48c23bde7
  • <6.1.178
  • =<6.18.*
  • <91095474eea29b95c9a8bceb9b501a2702b6c55f
  • ==6.4
  • =<6.12.*
  • <6.4
  • <6.4
  • ==cf671d2462d9af50c328bcc185d2c7b9726f8093
  • =<6.1.*
  • =<7.1.*
  • =<6.6.*
  • =<*
  • <d7c71dfd4b80f0eacac2c157a8a3a4c6e8b2e0d1
  • <18ec7d7785be7a4ee8ea11e355122282caad4267
Dismissed
(max. allowed matches exceeded)
created 4 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler The OTG branch of composite_setup() falls back to the first configuration when none is selected: if (cdev->config) config = cdev->config; else config = list_first_entry(&cdev->configs, struct usb_configuration, list); if (!config) goto done; ... memcpy(req->buf, config->descriptors[0], value); list_first_entry() never returns NULL. On an empty list it returns container_of() of the list head. So the "if (!config)" check is dead. When cdev->configs is empty, config points at the head inside struct usb_composite_dev. config->descriptors[0] reads whatever sits at that offset. The memcpy copies up to w_length bytes of it into the response buffer. cdev->configs can be empty in two cases. One is a teardown race on gadget unbind with a control transfer in flight. The other is a driver that sets is_otg before it adds a config. A reproducer that holds cdev->configs empty triggers a KASAN fault in this branch. Use list_first_entry_or_null() so the existing check does its job.

Affected products

Linux
  • <4.3
  • <91b3ecd34b60f950c50c560974945b6596a6f207
  • <56add2b9b2e89ec61c0761165d758f73004fdfdf
  • <fcb21bf747640c9d6bd1eda9da85420f076d59c1
  • <f8f680609c2b3ab795ffcd6f21585b6dfc46d395
  • <2454264b2ab4cf0055c0bfd39e79f830452bd0db
  • ==4.3
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <d3e72cfef2e38bd588055739a8100d14f9773b17
  • =<6.1.*
  • =<*
  • =<6.6.*
  • =<5.15.*
  • <01feaf024f29618d5ffa7ab0fd858e0579dcbf7b
  • =<5.10.*
  • <8ac463fe6c0f85bdb1ce8c30e8c9e060802e4483