Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
one append operations also cannot be split by the target driver as that would result in an invalid writen sector value return using the BIO sector. In order for zoned DM target drivers to avoid such incorrect BIO splitting, we must ensure that large BIOs are split before being passed to the map() function of the target, thus guaranteeing that the limits for the mapped device are not exceeded. dm-crypt and dm-flakey are the only target drivers supporting zoned devices and using dm_accept_partial_bio(). In the case of dm-crypt, this function is used to split BIOs to the internal max_write_size limit (which will be suppressed in a different patch). However, since crypt_alloc_buffer() uses a bio
nal max_write_size limit (which will be suppressed in a different patch). However, since crypt_alloc_buffer() uses a bioset allowing only up to BIO_MAX_VECS (256) vectors in a BIO. The dm-crypt device max_segments limit, which is not set and so default to BLK_MAX_SEGMENTS (128), must thus be respected and write BIOs split accordingly. In the case of dm-flakey, since zone append emulation is not required, the block layer zone write plugging is not used and no splitting of BIOs required. Modify the function dm_zone_bio_needs_split() to use the block layer helper function bio_needs_zone_write_plugging() to force a call to bio_split_to_limits() in dm_split_and_process_bio(). This allows DM targe
needs_zone_write_plugging() to force a call to bio_split_to_limits() in dm_split_and_process_bio(). This allows DM target drivers to avoid using dm_accept_partial_bio() for write operations on zoned DM devices. References: - https://git.kernel.org/stable/c/d10bf66d9f9335ffc7521b3029b114f50604cabe - https://git.kernel.org/stable/c/f5dd256333c08ab44b5aec4a8118cb04c0f20c54 - https://git.kernel.org/stable/c/4e9fef1cf0243d665d75c371cc80be6156cd30a2 - https://git.kernel.org/stable/c/2df7168717b7d2d32bcf017c68be16e4aae9dd13
CVE ID: CVE-2025-39793 State: PUBLISHED Published: 2025-09-12T15:59:30.388Z Last Updated: 2025-09-29T05:59:33.153Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: io_uring/memmap: cast nr_pages to size_t before shifting If the allocated size exceeds UINT_MAX, then it's necessary to cast the mr->nr_pages value to size_t to prevent it from overflowing. In practice this isn't much of a concern as the required memory size will have been validated upfront, and accounted to the user. And > 4GB sizes will be necessary to make the lack of a cast a problem, which greatly exceeds normal user locked_vm settings that are generally in the kb
to make the lack of a cast a problem, which greatly exceeds normal user locked_vm settings that are generally in the kb to mb range. However, if root is used, then accounting isn't done, and then it's possible to hit this issue. References: - https://git.kernel.org/stable/c/c6a2706e08b8a1b2d3740161c0977d38e596c1ee - https://git.kernel.org/stable/c/a69a9b53c54e2d33e2a5b1ea4a9a71fd01c6cf3a - https://git.kernel.org/stable/c/33503c083fda048c77903460ac0429e1e2c0e341
CVE ID: CVE-2025-39794 State: PUBLISHED Published: 2025-09-12T15:59:31.226Z Last Updated: 2025-11-03T17:43:26.094Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ARM: tegra: Use I/O memcpy to write to IRAM Kasan crashes the kernel trying to check boundaries when using the normal memcpy. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/b28c1a14accc79ead1e87bbdae53309da60be1e7 - https://git.kernel.org/stable/c/75a3bdfeed2f129a2c7d9fd7779382b78e35b014 - https://git.kernel.org/stable/c/2499b0ac908eefbb8a217aae609b7a5b5174f330 - https://git.kernel.org/stable/c/387435f4833f97aabfd74434e
kernel.org/stable/c/2499b0ac908eefbb8a217aae609b7a5b5174f330 - https://git.kernel.org/stable/c/387435f4833f97aabfd74434ee526e31e8a626ea - https://git.kernel.org/stable/c/46b3a7a3a36d5833f14914d1b95c69d28c6a76d6 - https://git.kernel.org/stable/c/9b0b3b5e5cae95e09bf0ae4a9bcb58d9b6d57f87 - https://git.kernel.org/stable/c/96d6605bf0561d6e568b1dd9265a0f73b5b94f51 - https://git.kernel.org/stable/c/30ef45b89a5961cdecf907ecff1ef3374d1de510 - https://git.kernel.org/stable/c/398e67e0f5ae04b29bcc9cbf342e339fe9d3f6f1
CVE ID: CVE-2025-39795 State: PUBLISHED Published: 2025-09-12T15:59:32.037Z Last Updated: 2025-11-03T17:43:27.990Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: block: avoid possible overflow for chunk_sectors check in blk_stack_limits() In blk_stack_limits(), we check that the t->chunk_sectors value is a multiple of the t->physical_block_size value. However, by finding the chunk_sectors value in bytes, we may overflow the unsigned int which holds chunk_sectors, so change the check to be based on sectors. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/418751910044649baa2b424ea3
itional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/418751910044649baa2b424ea31cce3fc4dcc253 - https://git.kernel.org/stable/c/8b3ce085b52e674290cbfdd07034e7653ffbe4dc - https://git.kernel.org/stable/c/31f2f080898e50cbf2bae62d35f9f2a997547b38 - https://git.kernel.org/stable/c/3b9d69f0e68aa6b0acd9791c45d445154a8c66e9 - https://git.kernel.org/stable/c/46aa80ef49594ed7de685ecbc673b291e9a2c159 - https://git.kernel.org/stable/c/5e276e6ff9aacf8901b9c3265c3cdd2568c9fff2 - https://git.kernel.org/stable/c/14beeef4aafecc8a41de534e31fb5be94739392f - https://git.kernel.org/stable/c/448dfecc7ff807822ecd47a5c052acedca7d09e8
CVE ID: CVE-2025-39796 State: PUBLISHED Published: 2025-09-12T15:59:32.871Z Last Updated: 2025-09-29T05:59:37.011Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: lapbether: ignore ops-locked netdevs Syzkaller managed to trigger lock dependency in xsk_notify via register_netdevice. As discussed in [0], using register_netdevice in the notifiers is problematic so skip adding lapbeth for ops-locked devices. xsk_notifier+0xa4/0x280 net/xdp/xsk.c:1645 notifier_call_chain+0xbc/0x410 kernel/notifier.c:85 call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:2230 call_netdevice_notifiers_extack net/core/dev.c:2268 [inline] call_n
device_notifiers_info+0xbe/0x140 net/core/dev.c:2230 call_netdevice_notifiers_extack net/core/dev.c:2268 [inline] call_netdevice_notifiers net/core/dev.c:2282 [inline] unregister_netdevice_many_notify+0xf9d/0x2700 net/core/dev.c:12077 unregister_netdevice_many net/core/dev.c:12140 [inline] unregister_netdevice_queue+0x305/0x3f0 net/core/dev.c:11984 register_netdevice+0x18f1/0x2270 net/core/dev.c:11149 lapbeth_new_device drivers/net/wan/lapbether.c:420 [inline] lapbeth_device_event+0x5b1/0xbe0 drivers/net/wan/lapbether.c:462 notifier_call_chain+0xbc/0x410 kernel/notifier.c:85 call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:2230 call_netdevice_notifiers_extack net/core/dev.c:2268 [inli
5 call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:2230 call_netdevice_notifiers_extack net/core/dev.c:2268 [inline] call_netdevice_notifiers net/core/dev.c:2282 [inline] __dev_notify_flags+0x12c/0x2e0 net/core/dev.c:9497 netif_change_flags+0x108/0x160 net/core/dev.c:9526 dev_change_flags+0xba/0x250 net/core/dev_api.c:68 devinet_ioctl+0x11d5/0x1f50 net/ipv4/devinet.c:1200 inet_ioctl+0x3a7/0x3f0 net/ipv4/af_inet.c:1001 0: https://lore.kernel.org/netdev/20250625140357.6203d0af@kernel.org/ References: - https://git.kernel.org/stable/c/57a7ef338a2cd62a22a15a199ab9afd3d953df55 - https://git.kernel.org/stable/c/628e233c1fefcc227fae9bdcff6be8ac92e1b4d2 - https://git.kernel.org/stable/c/53898
3df55 - https://git.kernel.org/stable/c/628e233c1fefcc227fae9bdcff6be8ac92e1b4d2 - https://git.kernel.org/stable/c/53898ebabe843bfa7baea9dae152797d5d0563c9
CVE ID: CVE-2025-39797 State: PUBLISHED Published: 2025-09-12T15:59:33.639Z Last Updated: 2025-09-29T05:59:38.268Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xfrm: Duplicate SPI Handling The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI Netlink message, which triggers the kernel function xfrm_alloc_spi(). This function is expected to ensure uniqueness of the Security Parameter Index (SPI) for inbound Security Associations (SAs). However, it can return success even when the requested SPI is already in use, leading to duplicate SPIs assigned to multiple inbound SAs, differentiated only by their destination a
s already in use, leading to duplicate SPIs assigned to multiple inbound SAs, differentiated only by their destination addresses. This behavior causes inconsistencies during SPI lookups for inbound packets. Since the lookup may return an arbitrary SA among those with the same SPI, packet processing can fail, resulting in packet drops. According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA is uniquely identified by the SPI and optionally protocol. Reproducing the Issue Reliably: To consistently reproduce the problem, restrict the available SPI range in charon.conf : spi_min = 0x10000000 spi_max = 0x10000002 This limits the system to only 2 usable SPI values. Next, create mo
ron.conf : spi_min = 0x10000000 spi_max = 0x10000002 This limits the system to only 2 usable SPI values. Next, create more than 2 Child SA. each using unique pair of src/dst address. As soon as the 3rd Child SA is initiated, it will be assigned a duplicate SPI, since the SPI pool is already exhausted. With a narrow SPI range, the issue is consistently reproducible. With a broader/default range, it becomes rare and unpredictable. Current implementation: xfrm_spi_hash() lookup function computes hash using daddr, proto, and family. So if two SAs have the same SPI but different destination addresses, then they will: a. Hash into different buckets b. Be stored in different linked lists (byspi + h
destination addresses, then they will: a. Hash into different buckets b. Be stored in different linked lists (byspi + h) c. Not be seen in the same hlist_for_each_entry_rcu() iteration. As a result, the lookup will result in NULL and kernel allows that Duplicate SPI Proposed Change: xfrm_state_lookup_spi_proto() does a truly global search - across all states, regardless of hash bucket and matches SPI and proto. References: - https://git.kernel.org/stable/c/3d8090bb53424432fa788fe9a49e8ceca74f0544 - https://git.kernel.org/stable/c/2fc5b54368a1bf1d2d74b4d3b8eea5309a653e38 - https://git.kernel.org/stable/c/c67d4e7a8f90fb6361ca89d4d5c9a28f4e935e47 - https://git.kernel.org/stable/c/29e9158f91f99
https://git.kernel.org/stable/c/c67d4e7a8f90fb6361ca89d4d5c9a28f4e935e47 - https://git.kernel.org/stable/c/29e9158f91f99057dbd35db5e8674d93b38549fe - https://git.kernel.org/stable/c/94f39804d891cffe4ce17737d295f3b195bc7299
CVE ID: CVE-2025-39798 State: PUBLISHED Published: 2025-09-12T15:59:34.386Z Last Updated: 2025-11-03T17:43:29.893Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: NFS: Fix the setting of capabilities when automounting a new filesystem Capabilities cannot be inherited when we cross into a new filesystem. They need to be reset to the minimal defaults, and then probed for again. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/95eb0d97ab98a10e966125c1f274e7d0fc0992b3 - https://git.kernel.org/stable/c/73fcb101bb3eb2a552d7856a476b2c0bc3b5ef9e - https://git.kernel.org/stable/c/3924dab908
- https://git.kernel.org/stable/c/73fcb101bb3eb2a552d7856a476b2c0bc3b5ef9e - https://git.kernel.org/stable/c/3924dab90816d0c683a110628ef386f83a9d1e13 - https://git.kernel.org/stable/c/175afda783e38c0660f2afc0602dd9c83d4e7ee1 - https://git.kernel.org/stable/c/987c20428f067c1c7f29ed0a2bd8c63fa74b1c2c - https://git.kernel.org/stable/c/816a6f60c2c2b679a33fa4276442bafd11473651 - https://git.kernel.org/stable/c/a8ffee4abd8ec9d7a64d394e0306ae64ba139fd2 - https://git.kernel.org/stable/c/50e0fd0050e510e749e1fdd1d7158e419ff8f3b9 - https://git.kernel.org/stable/c/b01f21cacde9f2878492cf318fee61bf4ccad323
CVE ID: CVE-2025-39799 State: REJECTED Published: 2025-09-12T15:59:35.221Z Last Updated: 2025-09-29T06:10:00.185Z Description: No description available.
CVE ID: CVE-2025-39800 State: PUBLISHED Published: 2025-09-15T12:36:43.043Z Last Updated: 2025-11-03T17:43:30.834Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: abort transaction on unexpected eb generation at btrfs_copy_root() If we find an unexpected generation for the extent buffer we are cloning at btrfs_copy_root(), we just WARN_ON() and don't error out and abort the transaction, meaning we allow to persist metadata with an unexpected generation. Instead of warning only, abort the transaction and return -EUCLEAN. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/4290e3
return -EUCLEAN. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/4290e34fb87ae556b12c216efd0ae91583446b7a - https://git.kernel.org/stable/c/4734255ef39b416864139dcda96a387fe5f33a6a - https://git.kernel.org/stable/c/da2124719f386b6e5d4d4b1a2e67c440e4d5892f - https://git.kernel.org/stable/c/f4f5bd9251a4cbe55aaa05725c6c3c32ad1f74b3 - https://git.kernel.org/stable/c/33e8f24b52d2796b8cfb28c19a1a7dd6476323a8
CVE ID: CVE-2025-39801 State: PUBLISHED Published: 2025-09-15T12:36:43.936Z Last Updated: 2025-11-03T17:43:31.805Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Remove WARN_ON for device endpoint command timeouts This commit addresses a rarely observed endpoint command timeout which causes kernel panic due to warn when 'panic_on_warn' is enabled and unnecessary call trace prints when 'panic_on_warn' is disabled. It is seen during fast software-controlled connect/disconnect testcases. The following is one such endpoint command timeout that we observed: 1. Connect ======= ->dwc3_thread_interrupt ->dwc3_ep0_interrupt -
is one such endpoint command timeout that we observed: 1. Connect ======= ->dwc3_thread_interrupt ->dwc3_ep0_interrupt ->configfs_composite_setup ->composite_setup ->usb_ep_queue ->dwc3_gadget_ep0_queue ->__dwc3_gadget_ep0_queue ->__dwc3_ep0_do_control_data ->dwc3_send_gadget_ep_cmd 2. Disconnect ========== ->dwc3_thread_interrupt ->dwc3_gadget_disconnect_interrupt ->dwc3_ep0_reset_state ->dwc3_ep0_end_control_data ->dwc3_send_gadget_ep_cmd In the issue scenario, in Exynos platforms, we observed that control transfers for the previous connect have not yet been completed and end transfer command sent as a part of the disconnect sequence and processing of USB_ENDPOINT_HALT feature request from
end transfer command sent as a part of the disconnect sequence and processing of USB_ENDPOINT_HALT feature request from the host timeout. This maybe an expected scenario since the controller is processing EP commands sent as a part of the previous connect. It maybe better to remove WARN_ON in all places where device endpoint commands are sent to avoid unnecessary kernel panic due to warn. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/dfe40159eec6ca63b40133bfa783eee2e3ed829f - https://git.kernel.org/stable/c/5a1a847d841505dba2bd85602daf5c218e1d85b8 - https://git.kernel.org/stable/c/84c95dbf5bece56086cdb65a64162af35158bdd9 - https://git.kerne
ba2bd85602daf5c218e1d85b8 - https://git.kernel.org/stable/c/84c95dbf5bece56086cdb65a64162af35158bdd9 - https://git.kernel.org/stable/c/f49697dfba2915a9ff36f94604eb76fa61413929 - https://git.kernel.org/stable/c/db27482b9db340402e05d4e9b75352bbaca51af2 - https://git.kernel.org/stable/c/45eae113dccaf8e502090ecf5b3d9e9b805add6f
CVE ID: CVE-2025-39802 State: PUBLISHED Published: 2025-09-15T12:36:44.792Z Last Updated: 2025-09-29T05:59:43.298Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: lib/crypto: arm/poly1305: Fix register corruption in no-SIMD contexts Restore the SIMD usability check that was removed by commit 773426f4771b ("crypto: arm/poly1305 - Add block-only interface"). This safety check is cheap and is well worth eliminating a footgun. While the Poly1305 functions should not be called when SIMD registers are unusable, if they are anyway, they should just do the right thing instead of corrupting random tasks' registers and/or computing incorr
ey are anyway, they should just do the right thing instead of corrupting random tasks' registers and/or computing incorrect MACs. Fixing this is also needed for poly1305_kunit to pass. Just use may_use_simd() instead of the original crypto_simd_usable(), since poly1305_kunit won't rely on crypto_simd_disabled_for_test. References: - https://git.kernel.org/stable/c/87bdfba903be7084cb3ee04032b14a81181fe413 - https://git.kernel.org/stable/c/52c3e242f4d0043186b70d65460ba1767f27494a
CVE ID: CVE-2025-39803 State: PUBLISHED Published: 2025-09-15T12:36:45.651Z Last Updated: 2025-09-29T05:59:44.525Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Remove WARN_ON_ONCE() call from ufshcd_uic_cmd_compl() The UIC completion interrupt may be disabled while an UIC command is being processed. When the UIC completion interrupt is reenabled, an UIC interrupt is triggered and the WARN_ON_ONCE(!cmd) statement is hit. Hence this patch that removes this kernel warning. References: - https://git.kernel.org/stable/c/c0cc24c139e0f62859dbf88e050ba074cd93988f - https://git.kernel.org/stable/c/e5203d89d59bfcbe1f34
/git.kernel.org/stable/c/c0cc24c139e0f62859dbf88e050ba074cd93988f - https://git.kernel.org/stable/c/e5203d89d59bfcbe1f348aa0d2dc4449a8ba644c
CVE ID: CVE-2025-39804 State: PUBLISHED Published: 2025-09-15T12:36:46.483Z Last Updated: 2025-09-29T05:59:45.812Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: lib/crypto: arm64/poly1305: Fix register corruption in no-SIMD contexts Restore the SIMD usability check that was removed by commit a59e5468a921 ("crypto: arm64/poly1305 - Add block-only interface"). This safety check is cheap and is well worth eliminating a footgun. While the Poly1305 functions should not be called when SIMD registers are unusable, if they are anyway, they should just do the right thing instead of corrupting random tasks' registers and/or computing in
f they are anyway, they should just do the right thing instead of corrupting random tasks' registers and/or computing incorrect MACs. Fixing this is also needed for poly1305_kunit to pass. Just use may_use_simd() instead of the original crypto_simd_usable(), since poly1305_kunit won't rely on crypto_simd_disabled_for_test. References: - https://git.kernel.org/stable/c/ef74efa598b7bbc5c24509f7f56af2806f81c339 - https://git.kernel.org/stable/c/eec76ea5a7213c48529a46eed1b343e5cee3aaab
CVE ID: CVE-2025-39805 State: PUBLISHED Published: 2025-09-16T13:00:06.731Z Last Updated: 2025-09-29T05:59:47.138Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: macb: fix unregister_netdev call order in macb_remove() When removing a macb device, the driver calls phy_exit() before unregister_netdev(). This leads to a WARN from kernfs: ------------[ cut here ]------------ kernfs: can not remove 'attached_dev', no directory WARNING: CPU: 1 PID: 27146 at fs/kernfs/dir.c:1683 Call trace: kernfs_remove_by_name_ns+0xd8/0xf0 sysfs_remove_link+0x24/0x58 phy_detach+0x5c/0x168 phy_disconnect+0x4c/0x70 phylink_disconnect_phy+0x6c/0xc
_ns+0xd8/0xf0 sysfs_remove_link+0x24/0x58 phy_detach+0x5c/0x168 phy_disconnect+0x4c/0x70 phylink_disconnect_phy+0x6c/0xc0 [phylink] macb_close+0x6c/0x170 [macb] ... macb_remove+0x60/0x168 [macb] platform_remove+0x5c/0x80 ... The warning happens because the PHY is being exited while the netdev is still registered. The correct order is to unregister the netdev before shutting down the PHY and cleaning up the MDIO bus. Fix this by moving unregister_netdev() ahead of phy_exit() in macb_remove(). References: - https://git.kernel.org/stable/c/ff0d3bad32108b57265e5b48f15327549af771d3 - https://git.kernel.org/stable/c/775fe690fd4a3337ad2115de2adb41b227d4dae7 - https://git.kernel.org/stable/c/01b9128
1d3 - https://git.kernel.org/stable/c/775fe690fd4a3337ad2115de2adb41b227d4dae7 - https://git.kernel.org/stable/c/01b9128c5db1b470575d07b05b67ffa3cb02ebf1
CVE ID: CVE-2025-39806 State: PUBLISHED Published: 2025-09-16T13:00:09.524Z Last Updated: 2025-11-03T17:43:32.753Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() A malicious HID device can trigger a slab out-of-bounds during mt_report_fixup() by passing in report descriptor smaller than 607 bytes. mt_report_fixup() attempts to patch byte offset 607 of the descriptor with 0x25 by first checking if byte offset 607 is 0x15 however it lacks bounds checks to verify if the descriptor is big enough before conducting this check. Fix this bug by ensuring the descriptor
checks to verify if the descriptor is big enough before conducting this check. Fix this bug by ensuring the descriptor size is at least 608 bytes before accessing it. Below is the KASAN splat after the out of bounds access happens: [ 13.671954] ================================================================== [ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110 [ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10 [ 13.673297] [ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3 [ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04 [ 13.673297] Call Tr
13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04 [ 13.673297] Call Trace: [ 13.673297] <TASK> [ 13.673297] dump_stack_lvl+0x5f/0x80 [ 13.673297] print_report+0xd1/0x660 [ 13.673297] kasan_report+0xe5/0x120 [ 13.673297] __asan_report_load1_noabort+0x18/0x20 [ 13.673297] mt_report_fixup+0x103/0x110 [ 13.673297] hid_open_report+0x1ef/0x810 [ 13.673297] mt_probe+0x422/0x960 [ 13.673297] hid_device_probe+0x2e2/0x6f0 [ 13.673297] really_probe+0x1c6/0x6b0 [ 13.673297] __driver_probe_device+0x24f/0x310 [ 13.673297] driver_probe_device+0x4e/0x220 [ 13.673297] __device_attach_driver+0x169/0x320 [ 13.673297] bus_for_each_drv+0x11d/0x1b0 [ 13.673297] __
ice+0x4e/0x220 [ 13.673297] __device_attach_driver+0x169/0x320 [ 13.673297] bus_for_each_drv+0x11d/0x1b0 [ 13.673297] __device_attach+0x1b8/0x3e0 [ 13.673297] device_initial_probe+0x12/0x20 [ 13.673297] bus_probe_device+0x13d/0x180 [ 13.673297] device_add+0xe3a/0x1670 [ 13.673297] hid_add_device+0x31d/0xa40 [...] Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/4263e5851779f7d8ebfbc9cc7d2e9b0217adba8d - https://git.kernel.org/stable/c/7ab7311c43ae19c66c53ccd8c5052a9072a4e338 - https://git.kernel.org/stable/c/d4e6e2680807671e1c73cd6a986b33659ce92f2b - https://git.kernel.org/stable/c/3055309821dd3da92888f88bad10f0324c3c89fe - https://git.kernel.o
73cd6a986b33659ce92f2b - https://git.kernel.org/stable/c/3055309821dd3da92888f88bad10f0324c3c89fe - https://git.kernel.org/stable/c/c13e95587583d018cfbcc277df7e02d41902ac5a - https://git.kernel.org/stable/c/0379eb8691b9c4477da0277ae0832036ca4410b4