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 3 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
HID: appleir: fix UAF on pending key_up_timer in remove()

In the Linux kernel, the following vulnerability has been resolved: HID: appleir: fix UAF on pending key_up_timer in remove() appleir_remove() runs hid_hw_stop() before timer_delete_sync(). hid_hw_stop() synchronously unregisters the HID input device via hid_disconnect() -> hidinput_disconnect() -> input_unregister_device(), which drops the last reference and frees the underlying input_dev when no userspace handle holds it open. key_up_tick() reads appleir->input_dev and calls input_report_key() / input_sync() on it. The timer is armed from appleir_raw_event() with a HZ/8 (~125 ms) timeout on every keydown and key-repeat report. If a key was pressed shortly before the device is disconnected, the timer can fire after hid_hw_stop() has freed input_dev but before the teardown drains it. A simple reorder is not sufficient. Putting the timer drain first still leaves a window where a USB URB completion (raw_event) running during hid_hw_stop() can call mod_timer() and re-arm the timer, which then fires after hidinput_disconnect() has freed input_dev. The same URB-completion window also lets raw_event() reach key_up(), key_down() and battery_flat() directly, all of which dereference appleir->input_dev. Introduce a 'removing' flag on struct appleir, gated by the existing spinlock. appleir_remove() sets the flag under the lock and then shuts down the timer with timer_shutdown_sync(), which both drains any in-flight callback and permanently disables further mod_timer() calls. appleir_raw_event() and key_up_tick() bail out early if the flag is set, so no path can arm or run the timer, or dereference appleir->input_dev, after remove() has started tearing down. The keyrepeat and flatbattery branches of appleir_raw_event() previously called into the input layer without holding the spinlock; take it now so the flag check is well-defined. This incidentally closes a pre-existing read-side race on appleir->current_key in the keyrepeat branch. This bug is structurally a sibling of commit 4db2af929279 ("HID: appletb-kbd: fix UAF in inactivity-timer cleanup path") and has been present since the driver was introduced.

Affected products

Linux
  • <37a52c61d4f78153c38ae1f7491dfcc8ac828dcf
  • =<6.18.*
  • ==3.10
  • <05e3decc55d1deca9410e0eb36466651fcbe57a5
  • <75fe87e19d8aff81eb2c64d15d244ab8da4de945
  • <3755f6e25776b8b12ddf062f9b573f05090e4034
  • <89ef67359672bf4cd6921524e39f61648fe38c0f
  • =<5.15.*
  • =<7.1.*
  • =<6.12.*
  • =<6.1.*
  • =<*
  • <b363d964ca829c1761c9f04188dfa28f90b0f2d4
  • <6b0838e86da88b1d3bff86f19761ff25af73eaca
  • =<6.6.*
  • <3.10
  • =<5.10.*
  • <3d30a0bb0e79621ae921b487835c56198adfafa3
Dismissed
(max. allowed matches exceeded)
created 3 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
xfs: fix exchmaps reservation limit check

In the Linux kernel, the following vulnerability has been resolved: xfs: fix exchmaps reservation limit check xfs_exchmaps_estimate_overhead() adds the bmbt and rmapbt overhead to a local resblks variable, but the final UINT_MAX check still tests req->resblks. That is the reservation value from before the overhead was added. The computed value is stored back in req->resblks and later passed to xfs_trans_alloc(), whose block reservation argument is unsigned int. Check the computed reservation so the existing limit applies to the value that will be used.

Affected products

Linux
  • <6.10
  • =<6.18.*
  • <c597c8580d50127fc1221b5a5b653a94d49e23e3
  • <4707344b0d36d1012c8a1716e20167cd3afdd5f1
  • =<6.12.*
  • <a62ef2d13d6e7270dd5e88c6082bf2d0edcd5112
  • =<7.1.*
  • =<*
  • <0a5213bbff62b51c7d4999ac8c7e11ea57d00d45
  • ==6.10
Dismissed
(max. allowed matches exceeded)
created 3 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ALSA: ice1712: check snd_ctl_new1() return value

In the Linux kernel, the following vulnerability has been resolved: ALSA: ice1712: check snd_ctl_new1() return value snd_ctl_new1() can return NULL when memory allocation fails. The ice1712 driver calls snd_ctl_new1() without checking the return value before dereferencing the pointer in multiple places (ice1712.c, ice1724.c, aureon.c), which can lead to NULL pointer dereferences. Add NULL checks after snd_ctl_new1() calls and return -ENOMEM if any fails.

Affected products

Linux
  • ==286e17a1c3baeb1b1cd36b63ee16e8a6e63d558e
  • <6.1.178
  • <57d59be545b309d4bb54ac472b15d1e67f254d95
  • <69bf1dfa3215524c4ae255bb9dce0770875abbeb
  • <2b929b91b0f3bc6de8a844370049cd99ee8e31ff
  • =<6.18.*
  • ==6.4
  • =<6.12.*
  • <38a7cc46370a57122fb29c4bfe48a851c0c64459
  • =<7.1.*
  • <6.4
  • =<6.1.*
  • <d34ad480b8896d2b486e2cf29ce1790326cad205
  • =<6.6.*
  • =<*
  • <71b87108ad93d433cdb20704a8dc8852304cf2c2
  • <6.4
Dismissed
(max. allowed matches exceeded)
created 3 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
smb: client: mask server-provided mode to 07777 in modefromsid

In the Linux kernel, the following vulnerability has been resolved: smb: client: mask server-provided mode to 07777 in modefromsid When modefromsid is active, parse_dacl() applies the server-provided sub_auth[2] value from the NFS mode SID to cf_mode without masking to 07777. Apply the correct masking, same as in the read path.

Affected products

Linux
  • <f80add1bfb3425100a325b14f19648e75669a954
  • <e3d9c7160d483fc8f9e225aafad8ecbbc43f3151
  • <08c600b7e1818539ba5efee4cdb06215c245ca78
  • <5f6f2241034f189c69d4d0b5f8fe24a0c25b0c14
  • =<6.18.*
  • ==5.4
  • <ee2216dbdf0c677e89bb43e03247dba590ed00ef
  • <b84e002e0df26bbc6cbd3ca01b8212601fe0ae7d
  • <c6c484a7d5bff6b929a86d7ed5130f29834c6a0d
  • =<6.12.*
  • =<7.1.*
  • =<6.1.*
  • =<*
  • =<6.6.*
  • <f511807feee7cb29b61bdfa86472c7e9e2e5df94
  • <5.4
  • =<5.15.*
  • =<5.10.*
Dismissed
(max. allowed matches exceeded)
created 3 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
i2c: core: fix adapter deregistration race

In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter deregistration race Adapters can be looked up by their id using i2c_get_adapter() which takes a reference to the embedded struct device. Remove the adapter from the IDR before tearing it down during deregistration (and on registration failure) to make sure its resources are not accessed after having been freed (e.g. the device name).

Affected products

Linux
  • <11dfa37bf544cc806f21742ca2fd2d841bd7032e
  • <d39282f552dd6c35b9b84b4af78f1198c24f3373
  • =<6.18.*
  • <2.6.31
  • <b6d2af6fe9c1f5ec0484536753c979cbd40a8ac3
  • ==2.6.31
  • =<6.12.*
  • <bb234487a447a99315add1b46aa57b72e163e1eb
  • <35dbd1f1f603401155cbd3a180bb18e3a3b675b8
  • =<7.1.*
  • =<6.1.*
  • =<*
  • =<6.6.*
  • =<5.15.*
  • <9882a9bd74db08e7bae5821a7050627ae92d3380
  • <b1a58ed9eab146b36f41a55db8f5d7ce9fdedf3f
Dismissed
(max. allowed matches exceeded)
created 3 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
iio: event: Fix event FIFO reset race

In the Linux kernel, the following vulnerability has been resolved: iio: event: Fix event FIFO reset race `iio_event_getfd()` creates the event file descriptor with `anon_inode_getfd()`, which allocates a new fd, creates the anonymous file and installs it in the process fd table before returning to the caller. The IIO code resets the event FIFO after `anon_inode_getfd()` has returned, but before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace. But since fd tables are shared between threads, another thread can guess the newly allocated fd number and issue a `read()` on it as soon as the fd has been installed. This means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in parallel with the `kfifo_reset_out()` in `iio_event_getfd()`. The kfifo documentation says that `kfifo_reset_out()` is only safe when it is called from the reader thread and there is only one concurrent reader. Otherwise it is dangerous and must be handled in the same way as `kfifo_reset()`. If that happens, `kfifo_to_user()` can advance the FIFO `out` index based on state from before the reset, after the reset has already moved the `out` index to the current `in` index. That can leave the FIFO with an `out` index past the `in` index. A later `read()` can then see an underflowed FIFO length and copy more data than the event FIFO buffer contains. This can result in an out-of-bounds read and leak adjacent kernel memory to userspace. Move the FIFO reset before `anon_inode_getfd()`. At that point the event fd is marked busy, but the new fd has not been installed yet, so userspace cannot access it while the FIFO is reset.

Affected products

Linux
  • <0d4a646d7f87ea3625fafe387043fddc6a2f5e7f
  • <d16a702ca7d29c0b7a9b509339d1b044a1cadb32
  • <a13ef1adbc62085b21b546b07b0be7e2fbf52150
  • <af791d295737ea6b6ff2c8d8488462a49c14af01
  • =<6.18.*
  • =<6.12.*
  • <9edefd4c56bee3fe331e0355d1f10a533134999d
  • ==3.15
  • <3.15
  • =<7.1.*
  • =<6.1.*
  • =<*
  • =<6.6.*
  • =<5.15.*
  • <f187dc5a4c4846ffa07d9bda6e760837ed005574
  • <9dc84ba4be5bbeb29ee49efe6cea2cb32c461424
  • =<5.10.*
  • <72c6aa8e0d74eab91b8694cde97dec088c248fee
Dismissed
(max. allowed matches exceeded)
created 3 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
RDMA/siw: bound Read Response placement to the RREAD length

In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: bound Read Response placement to the RREAD length In drivers/infiniband/sw/siw/siw_qp_rx.c, siw_proc_rresp() places each inbound Read Response DDP segment at sge->laddr + wqe->processed and then accumulates wqe->processed, but it never checks the running total against the sink buffer length on continuation segments. siw_check_sge() resolves and validates the sink memory only on the first fragment (the if (!*mem) branch), and siw_rresp_check_ntoh() compares the cumulative length against wqe->bytes only on the final segment (the !frx->more_ddp_segs guard). A connected siw peer that answers an outstanding RREAD with Read Response segments that keep the DDP Last flag clear, carrying more total payload than the RREAD requested, drives wqe->processed past the validated sink buffer; the next siw_rx_data() call writes out of bounds at sge->laddr + wqe->processed. siw runs iWARP over ordinary routable TCP, so the peer is the remote end of an established RDMA connection and needs no local privilege. Bound every segment before placement, exactly as siw_proc_send() and siw_proc_write() already do for their tagged and untagged paths, and terminate the connection with a base-or-bounds DDP error when the Read Response would overrun the sink buffer. This is the second receive-path length fix for this file. A separate change rejects an MPA FPDU length that underflows the per-fragment remainder in the header decode; that guard does not cover this case, because here each individual segment length is self-consistent and only the accumulated placement offset overruns the buffer.

Affected products

Linux
  • <5.3
  • <595e6537ad1a210da32cbb9a7f91aa73090915ba
  • <3ef7e052cbd05a8b13a51a07b185a39ec93ee1cf
  • <6bc89f34a4597f9f6d41f7a60c67a3153bfe8851
  • <75c93cd3c421890f49ea93f0b978b9b7bb10e5e3
  • <a31b6d18ded3cc32d9ee85a6ff0726d4274887b2
  • ==5.3
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <7d29f7e9dbd844cae4d3e559cf78324b9642fd6b
  • <b2e26c955f8dd7e8d3f16c858db05245ea4fa817
  • =<*
  • <423a78ff7928c2601013f73ec6d896f5597d0df5
  • =<6.1.*
  • =<6.6.*
  • =<5.15.*
  • =<5.10.*
Dismissed
(max. allowed matches exceeded)
created 3 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Bluetooth: bnep: pin L2CAP connection during netdev registration

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: pin L2CAP connection during netdev registration bnep_add_connection() reads the L2CAP connection without holding the channel lock, then passes its HCI device to register_netdev(). Controller teardown can clear and release that connection concurrently, leaving the network device registration path to dereference a freed parent device. Take a reference to the L2CAP connection while holding the channel lock. Retain it until register_netdev() has taken the parent device reference.

Affected products

Linux
  • =<5.10.*
  • <563a8573047182f550b1e1e030615755cd8c41da
  • <390b5db3ff8745187f094c4e915663b7b1f98944
  • =<6.18.*
  • =<6.12.*
  • <a6b22dbd80926556290ad2243be25218d6956a19
  • <df22adc7eafc22e651561813c11dc51a796b12ee
  • =<7.1.*
  • <bb067a99a0356196c0b89a95721985485ebce5a5
  • <46a88784c4c9b96954dd86f747ce93f65efa1302
  • =<6.1.*
  • =<*
  • =<6.6.*
  • <ae215c5b6422d8eda443b861b124bd1be6969c31
  • <551ae773ec64045b4e72099132654887e0270bcc
  • =<5.15.*
  • ==3.13
  • <3.13
Dismissed
(max. allowed matches exceeded)
created 3 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
module: decompress: check return value of module_extend_max_pages()

In the Linux kernel, the following vulnerability has been resolved: module: decompress: check return value of module_extend_max_pages() module_extend_max_pages() calls kvrealloc() internally and returns -ENOMEM on allocation failure. The return value is never checked. If the initial allocation fails, info->pages remains NULL and info->max_pages remains 0. Subsequent calls to module_get_next_page() will attempt to dynamically grow the array by calling module_extend_max_pages(info, 0) since info->used_pages is 0. This results in kvrealloc(NULL, 0) returning ZERO_SIZE_PTR, which is treated as a success, leading to a dereference of ZERO_SIZE_PTR and a kernel oops. Fix: add the missing error check after module_extend_max_pages() and return immediately on failure. This matches the pattern used by every other kvrealloc() caller in the module loading path. [Sami: Corrected the analysis in the commit message.]

Affected products

Linux
  • <e7f174715f9f0cbcb9e87b52e4fc4ef149baac98
  • =<6.18.*
  • <786d2d84416a9a1c1a47b71a68d679d886284be2
  • ==5.17
  • <e7da02659c229f73492fb1ed87ceda4090153aaa
  • =<6.12.*
  • <168072baf9ad516d5a06046514c7fea4c0671990
  • <5.17
  • =<7.1.*
  • =<6.1.*
  • <afcc0515bbdd28d509a2b5870faaa89b137f5d53
  • =<6.6.*
  • <a82e170637e050a803b4f37542371ef216bf66d2
  • =<*
Dismissed
(max. allowed matches exceeded)
created 3 hours ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
media: nxp: imx8-isi: Fix use-after-free on remove

In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix use-after-free on remove KASAN reports a slab-use-after-free in __media_entity_remove_link() during rmmod of imx8_isi: BUG: KASAN: slab-use-after-free in __media_entity_remove_link+0x608/0x650 Read of size 2 at addr ffff0000d47cb02a by task rmmod/724 Call trace: __media_entity_remove_link+0x608/0x650 __media_entity_remove_links+0x78/0x144 __media_device_unregister_entity+0x150/0x280 media_device_unregister_entity+0x48/0x68 v4l2_device_unregister_subdev+0x158/0x300 v4l2_async_unbind_subdev_one+0x22c/0x358 v4l2_async_nf_unbind_all_subdevs+0xfc/0x1c0 v4l2_async_nf_unregister+0x5c/0x14c mxc_isi_remove+0x124/0x2a0 [imx8_isi] Allocated by task 249: __kmalloc_noprof+0x27c/0x690 mxc_isi_crossbar_init+0x22c/0x560 [imx8_isi] Freed by task 724: kfree+0x1e4/0x5b0 mxc_isi_crossbar_cleanup+0x34/0x80 [imx8_isi] mxc_isi_remove+0x11c/0x2a0 [imx8_isi] The problem is that mxc_isi_remove() calls mxc_isi_crossbar_cleanup() before mxc_isi_v4l2_cleanup(). The crossbar cleanup frees the media entity pads, but the subsequent v4l2 cleanup still tries to remove media links that reference those pads. Fix this by calling mxc_isi_v4l2_cleanup() before mxc_isi_crossbar_cleanup() to ensure all media entities are properly unregistered while the pads are still valid.

Affected products

Linux
  • <ef382a6baf0a95cf199fdf6bba2fd08e58b0a249
  • =<6.18.*
  • <d22fb719654bfde6f682c9f14629f5f9534175b7
  • ==6.4
  • <c12a5b2261351cd3b03921ce4720332ff5184b50
  • =<6.12.*
  • <6.4
  • =<7.1.*
  • =<*
  • =<6.6.*
  • <b670bf89824ede5d07d20bb9bfbafb754846081d
  • <ba2aa5d325270cd965c44458c5ff5ab555e6af51