Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
_CONN_HANDLE_UNSET is introduced to identify new connections. To make sure the events do not contain this or another invalid handle HCI_CONN_HANDLE_MAX and checks are introduced. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=215497 References: - https://git.kernel.org/stable/c/aa1ca580e3ffe62a2c5ea1c095b609b2943c5269 - https://git.kernel.org/stable/c/d5ebaa7c5f6f688959e8d40840b2249ede63b8ed
CVE ID: CVE-2022-49139 State: PUBLISHED Published: 2025-02-26T01:55:11.163Z Last Updated: 2025-10-01T19:57:02.106Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt This event is just specified for SCO and eSCO link types. On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR of an existing LE connection, LE link type and a status that triggers the second case of the packet processing a NULL pointer dereference happens, as conn->link is NULL. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/1c1291a84e94f6501
NULL. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/1c1291a84e94f6501644634c97544bb8291e9a1a - https://git.kernel.org/stable/c/0f9db1209f59844839175b5b907d3778cafde93d - https://git.kernel.org/stable/c/c1aa0dd52db4ce888be0bd820c3fa918d350ca0b - https://git.kernel.org/stable/c/f61c23e73dc653b957781066abfa8105c3fa3f5b - https://git.kernel.org/stable/c/3afee2118132e93e5f6fa636dfde86201a860ab3
CVE ID: CVE-2022-49140 State: REJECTED Published: 2025-02-26T01:55:11.664Z Last Updated: 2025-02-27T01:54:26.159Z Description: No description available.
CVE ID: CVE-2022-49141 State: PUBLISHED Published: 2025-02-26T01:55:12.197Z Last Updated: 2025-10-01T19:57:01.859Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: dsa: felix: fix possible NULL pointer dereference As the possible failure of the allocation, kzalloc() may return NULL pointer. Therefore, it should be better to check the 'sgi' in order to prevent the dereference of NULL pointer. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/b7ff8b5e75d4e91ec8c62d621aac8dfb84c57aa9 - https://git.kernel.org/stable/c/866b7a278cdb51eb158cd8513bc7438fc857804a
CVE ID: CVE-2022-49142 State: PUBLISHED Published: 2025-02-26T01:55:12.823Z Last Updated: 2025-05-04T12:44:18.986Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: preserve skb_end_offset() in skb_unclone_keeptruesize() syzbot found another way to trigger the infamous WARN_ON_ONCE(delta < len) in skb_try_coalesce() [1] I was able to root cause the issue to kfence. When kfence is in action, the following assertion is no longer true: int size = xxxx; void *ptr1 = kmalloc(size, gfp); void *ptr2 = kmalloc(size, gfp); if (ptr1 && ptr2) ASSERT(ksize(ptr1) == ksize(ptr2)); We attempted to fix these issues in the blamed commits, but
gfp); if (ptr1 && ptr2) ASSERT(ksize(ptr1) == ksize(ptr2)); We attempted to fix these issues in the blamed commits, but forgot that TCP was possibly shifting data after skb_unclone_keeptruesize() has been used, notably from tcp_retrans_try_collapse(). So we not only need to keep same skb->truesize value, we also need to make sure TCP wont fill new tailroom that pskb_expand_head() was able to get from a addr = kmalloc(...) followed by ksize(addr) Split skb_unclone_keeptruesize() into two parts: 1) Inline skb_unclone_keeptruesize() for the common case, when skb is not cloned. 2) Out of line __skb_unclone_keeptruesize() for the 'slow path'. WARNING: CPU: 1 PID: 6490 at net/core/skbuff.c:5295 s
. 2) Out of line __skb_unclone_keeptruesize() for the 'slow path'. WARNING: CPU: 1 PID: 6490 at net/core/skbuff.c:5295 skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295 Modules linked in: CPU: 1 PID: 6490 Comm: syz-executor161 Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295 Code: bf 01 00 00 00 0f b7 c0 89 c6 89 44 24 20 e8 62 24 4e fa 8b 44 24 20 83 e8 01 0f 85 e5 f0 ff ff e9 87 f4 ff ff e8 cb 20 4e fa <0f> 0b e9 06 f9 ff ff e8 af b2 95 fa e9 69 f0 ff ff e8 95 b2 95 fa RSP: 0018:ffffc900063af268 EFLAGS: 00010293 RAX: 0000000000
e9 06 f9 ff ff e8 af b2 95 fa e9 69 f0 ff ff e8 95 b2 95 fa RSP: 0018:ffffc900063af268 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 00000000ffffffd5 RCX: 0000000000000000 RDX: ffff88806fc05700 RSI: ffffffff872abd55 RDI: 0000000000000003 RBP: ffff88806e675500 R08: 00000000ffffffd5 R09: 0000000000000000 R10: ffffffff872ab659 R11: 0000000000000000 R12: ffff88806dd554e8 R13: ffff88806dd9bac0 R14: ffff88806dd9a2c0 R15: 0000000000000155 FS: 00007f18014f9700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002000 CR3: 000000006be7a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 000
0 CR3: 000000006be7a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tcp_try_coalesce net/ipv4/tcp_input.c:4651 [inline] tcp_try_coalesce+0x393/0x920 net/ipv4/tcp_input.c:4630 tcp_queue_rcv+0x8a/0x6e0 net/ipv4/tcp_input.c:4914 tcp_data_queue+0x11fd/0x4bb0 net/ipv4/tcp_input.c:5025 tcp_rcv_established+0x81e/0x1ff0 net/ipv4/tcp_input.c:5947 tcp_v4_do_rcv+0x65e/0x980 net/ipv4/tcp_ipv4.c:1719 sk_backlog_rcv include/net/sock.h:1037 [inline] __release_sock+0x134/0x3b0 net/core/sock.c:2779 release_sock+0x54/0x1b0 net/core/sock.c:3311 sk_wait_data+0x177/0x450 net/core/sock.
ck+0x134/0x3b0 net/core/sock.c:2779 release_sock+0x54/0x1b0 net/core/sock.c:3311 sk_wait_data+0x177/0x450 net/core/sock.c:2821 tcp_recvmsg_locked+0xe28/0x1fd0 net/ipv4/tcp.c:2457 tcp_recvmsg+0x137/0x610 net/ipv4/tcp.c:2572 inet_recvmsg+0x11b/0x5e0 net/ipv4/af_inet.c:850 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] sock_recvmsg net/socket.c:962 [inline] ____sys_recvmsg+0x2c4/0x600 net/socket.c:2632 ___sys_recvmsg+0x127/0x200 net/socket.c:2674 __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae References: - https://git.ker
o_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae References: - https://git.kernel.org/stable/c/23629b673b780d967b88a850b1518cf0f0ffc6aa - https://git.kernel.org/stable/c/a9a6d30264327d8ff7f23da33e7a77ffb793fa3f - https://git.kernel.org/stable/c/a903e516f5df44b46d526b403d93e7be1a425538 - https://git.kernel.org/stable/c/2b88cba55883eaafbc9b7cbff0b2c7cdba71ed01
CVE ID: CVE-2022-49143 State: REJECTED Published: 2025-02-26T01:55:13.332Z Last Updated: 2025-02-26T14:56:03.171Z Description: No description available.
CVE ID: CVE-2022-49144 State: PUBLISHED Published: 2025-02-26T01:55:13.843Z Last Updated: 2025-10-01T19:57:01.623Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: io_uring: fix memory leak of uid in files registration When there are no files for __io_sqe_files_scm() to process in the range, it'll free everything and return. However, it forgets to put uid. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/b27de7011cb3ba14b047be2cee0ed8278368665b - https://git.kernel.org/stable/c/0853bd6885c2f293d88aaa7f7f1702c959b31680 - https://git.kernel.org/stable/c/d6d7a517e81accf6ed22d55684baea7
.org/stable/c/0853bd6885c2f293d88aaa7f7f1702c959b31680 - https://git.kernel.org/stable/c/d6d7a517e81accf6ed22d55684baea763d2dbe43 - https://git.kernel.org/stable/c/7fa8b228c3f30060b9f4b24bb9aaaf41b0ae83fe - https://git.kernel.org/stable/c/c86d18f4aa93e0e66cda0e55827cd03eea6bc5f8
CVE ID: CVE-2022-49145 State: PUBLISHED Published: 2025-02-26T01:55:14.355Z Last Updated: 2025-05-04T08:30:56.127Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Avoid out of bounds access when parsing _CPC data If the NumEntries field in the _CPC return package is less than 2, do not attempt to access the "Revision" element of that package, because it may not be present then. BugLink: https://lore.kernel.org/lkml/20220322143534.GC32582@xsang-OptiPlex-9020/ References: - https://git.kernel.org/stable/c/b3f15609ffa521de12244cd6af24002030dda3f5 - https://git.kernel.org/stable/c/d208ea44e25b31db5a4d5e8c31df51787a3e9303
le/c/b3f15609ffa521de12244cd6af24002030dda3f5 - https://git.kernel.org/stable/c/d208ea44e25b31db5a4d5e8c31df51787a3e9303 - https://git.kernel.org/stable/c/28d5387c1994f5e1e0d41b30a1f3dd6e1f609252 - https://git.kernel.org/stable/c/cb249f8c00f40dba83b7da8207ac14ca46e9ec9e - https://git.kernel.org/stable/c/e5b681822cac1f8093759b02e16c06b2c64b6788 - https://git.kernel.org/stable/c/97b5593fd1b182b3fdb180b6bbe64ec09669988b - https://git.kernel.org/stable/c/b80b19b32a432c9eee1cd200ef7aaddf608f54d1 - https://git.kernel.org/stable/c/d7339f2a3938fb56b5f28d53f5345900b5fa0e74 - https://git.kernel.org/stable/c/40d8abf364bcab23bc715a9221a3c8623956257b
CVE ID: CVE-2022-49146 State: PUBLISHED Published: 2025-02-26T01:55:14.849Z Last Updated: 2025-05-04T08:30:57.555Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: virtio: use virtio_device_ready() in virtio_device_restore() After waking up a suspended VM, the kernel prints the following trace for virtio drivers which do not directly call virtio_device_ready() in the .restore: PM: suspend exit irq 22: nobody cared (try booting with the "irqpoll" option) Call Trace: <IRQ> dump_stack_lvl+0x38/0x49 dump_stack+0x10/0x12 __report_bad_irq+0x3a/0xaf note_interrupt.cold+0xb/0x60 handle_irq_event+0x71/0x80 handle_fasteoi_irq+0x95/0x1e0 __
0x12 __report_bad_irq+0x3a/0xaf note_interrupt.cold+0xb/0x60 handle_irq_event+0x71/0x80 handle_fasteoi_irq+0x95/0x1e0 __common_interrupt+0x6b/0x110 common_interrupt+0x63/0xe0 asm_common_interrupt+0x1e/0x40 ? __do_softirq+0x75/0x2f3 irq_exit_rcu+0x93/0xe0 sysvec_apic_timer_interrupt+0xac/0xd0 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x12/0x20 arch_cpu_idle+0x12/0x20 default_idle_call+0x39/0xf0 do_idle+0x1b5/0x210 cpu_startup_entry+0x20/0x30 start_secondary+0xf3/0x100 secondary_startup_64_no_verify+0xc3/0xcb </TASK> handlers: [<000000008f9bac49>] vp_interrupt [<000000008f9bac49>] vp_interrupt Disabling IRQ #22 This happens because we don't invoke .enable_cbs callback in virtio_device_rest
f9bac49>] vp_interrupt Disabling IRQ #22 This happens because we don't invoke .enable_cbs callback in virtio_device_restore(). That callback is used by some transports (e.g. virtio-pci) to enable interrupts. Let's fix it, by calling virtio_device_ready() as we do in virtio_dev_probe(). This function calls .enable_cts callback and sets DRIVER_OK status bit. This fix also avoids setting DRIVER_OK twice for those drivers that call virtio_device_ready() in the .restore. References: - https://git.kernel.org/stable/c/94e9f5da39ee5f8ea31be1585de31c54f10dedce - https://git.kernel.org/stable/c/4ae431113179d72c668b61df320af0c06d1aa5c5 - https://git.kernel.org/stable/c/8d65bc9a5be3f23c5e2ab36b6b8ef4009
rg/stable/c/4ae431113179d72c668b61df320af0c06d1aa5c5 - https://git.kernel.org/stable/c/8d65bc9a5be3f23c5e2ab36b6b8ef40095165b18
CVE ID: CVE-2022-49147 State: PUBLISHED Published: 2025-02-26T01:55:15.373Z Last Updated: 2025-05-04T08:30:59.109Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: block: Fix the maximum minor value is blk_alloc_ext_minor() ida_alloc_range(..., min, max, ...) returns values from min to max, inclusive. So, NR_EXT_DEVT is a valid idx returned by blk_alloc_ext_minor(). This is an issue because in device_add_disk(), this value is used in: ddev->devt = MKDEV(disk->major, disk->first_minor); and NR_EXT_DEVT is '(1 << MINORBITS)'. So, should 'disk->first_minor' be NR_EXT_DEVT, it would overflow. References: - https://git.kernel.org/stab
MINORBITS)'. So, should 'disk->first_minor' be NR_EXT_DEVT, it would overflow. References: - https://git.kernel.org/stable/c/5b9ac3727e4abb11c9cfbe9c0781fc05dfdd7cfb - https://git.kernel.org/stable/c/0f8cf8f5ccbad25ed6828875b222dbab29d5c272 - https://git.kernel.org/stable/c/fbe2cc4525480ddd20c866bb5c0578071e01451a - https://git.kernel.org/stable/c/d1868328dec5ae2cf210111025fcbc71f78dd5ca
CVE ID: CVE-2022-49148 State: PUBLISHED Published: 2025-02-26T01:55:15.872Z Last Updated: 2025-10-01T19:57:01.488Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: watch_queue: Free the page array when watch_queue is dismantled Commit 7ea1a0124b6d ("watch_queue: Free the alloc bitmap when the watch_queue is torn down") took care of the bitmap, but not the page array. BUG: memory leak unreferenced object 0xffff88810d9bc140 (size 32): comm "syz-executor335", pid 3603, jiffies 4294946994 (age 12.840s) hex dump (first 32 bytes): 40 a7 40 04 00 ea ff ff 00 00 00 00 00 00 00 00 @.@............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00
st 32 bytes): 40 a7 40 04 00 ea ff ff 00 00 00 00 00 00 00 00 @.@............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: kmalloc_array include/linux/slab.h:621 [inline] kcalloc include/linux/slab.h:652 [inline] watch_queue_set_size+0x12f/0x2e0 kernel/watch_queue.c:251 pipe_ioctl+0x82/0x140 fs/pipe.c:632 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7169f60110915c8b53bffd43741fa020a75eb87a - https://git.kerne
Vulnrichment: References: - https://git.kernel.org/stable/c/7169f60110915c8b53bffd43741fa020a75eb87a - https://git.kernel.org/stable/c/4913daecd04addb41bc96a9175a885e1c19862a8 - https://git.kernel.org/stable/c/3963a5d1ff75585bddf0c3a918566a6be09d7520 - https://git.kernel.org/stable/c/375cd2536494cfbcdda84ae8b3e35bf19d0250b9 - https://git.kernel.org/stable/c/b490207017ba237d97b735b2aa66dc241ccd18f5
CVE ID: CVE-2022-49149 State: PUBLISHED Published: 2025-02-26T01:55:16.371Z Last Updated: 2025-05-04T08:31:01.988Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix call timer start racing with call destruction The rxrpc_call struct has a timer used to handle various timed events relating to a call. This timer can get started from the packet input routines that are run in softirq mode with just the RCU read lock held. Unfortunately, because only the RCU read lock is held - and neither ref or other lock is taken - the call can start getting destroyed at the same time a packet comes in addressed to that call. This causes
is taken - the call can start getting destroyed at the same time a packet comes in addressed to that call. This causes the timer - which was already stopped - to get restarted. Later, the timer dispatch code may then oops if the timer got deallocated first. Fix this by trying to take a ref on the rxrpc_call struct and, if successful, passing that ref along to the timer. If the timer was already running, the ref is discarded. The timer completion routine can then pass the ref along to the call's work item when it queues it. If the timer or work item where already queued/running, the extra ref is discarded. References: - https://git.kernel.org/stable/c/051360e51341cd17738d82c15a8226010c7cb7f6
ning, the extra ref is discarded. References: - https://git.kernel.org/stable/c/051360e51341cd17738d82c15a8226010c7cb7f6 - https://git.kernel.org/stable/c/8cbf4ae7a2833767d63114573e5f9a45740cc975 - https://git.kernel.org/stable/c/54df5a37f1d951ed27fd47bf9b15a42279582110 - https://git.kernel.org/stable/c/5e3c11144e557a9dbf9a2f6abe444689ef9d8aae - https://git.kernel.org/stable/c/4a7f62f91933c8ae5308f9127fd8ea48188b6bc3
CVE ID: CVE-2022-49150 State: PUBLISHED Published: 2025-02-26T01:55:16.962Z Last Updated: 2025-10-01T19:57:01.248Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rtc: gamecube: Fix refcount leak in gamecube_rtc_read_offset_from_sram The of_find_compatible_node() function returns a node pointer with refcount incremented, We should use of_node_put() on it when done Add the missing of_node_put() to release the refcount. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/de66e4f28dfd11f954966c447b4430529ed040a2 - https://git.kernel.org/stable/c/4b2dc39ca024990abe36ad5d145c4fe0c06afd34
CVE ID: CVE-2022-49151 State: PUBLISHED Published: 2025-02-26T01:55:17.665Z Last Updated: 2025-05-04T08:31:05.112Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: properly check endpoint type Syzbot reported warning in usb_submit_urb() which is caused by wrong endpoint type. We should check that in endpoint is actually present to prevent this warning. Found pipes are now saved to struct mcba_priv and code uses them directly instead of making pipes in place. Fail log: | usb 5-1: BOGUS urb xfer, pipe 3 != type 1 | WARNING: CPU: 1 PID: 49 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.
pe 3 != type 1 | WARNING: CPU: 1 PID: 49 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 | Modules linked in: | CPU: 1 PID: 49 Comm: kworker/1:2 Not tainted 5.17.0-rc6-syzkaller-00184-g38f80f42147f #0 | Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 | Workqueue: usb_hub_wq hub_event | RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 | ... | Call Trace: | <TASK> | mcba_usb_start drivers/net/can/usb/mcba_usb.c:662 [inline] | mcba_usb_probe+0x8a3/0xc50 drivers/net/can/usb/mcba_usb.c:858 | usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 | call_driver_probe drivers/base/dd.c:517 [inline] References: -
obe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 | call_driver_probe drivers/base/dd.c:517 [inline] References: - https://git.kernel.org/stable/c/5598442edc29e8f6f2380e4b471dc1a3fcd80508 - https://git.kernel.org/stable/c/b48d1bb3f1ca337ad653022aefb5a40a47dfe5cd - https://git.kernel.org/stable/c/cbd110b8dd7ad763bf413f71c0484116ae9302d4 - https://git.kernel.org/stable/c/ef0acc514123140157b19a9ff2e2de5d91d612bc - https://git.kernel.org/stable/c/fa9c1f14002dc0d5293e16a2007bd89b6e79207b - https://git.kernel.org/stable/c/88272b4a37913bdf6f339162a7920bd8e9b49de2 - https://git.kernel.org/stable/c/f2ec3cd0f34f8c3f94bc21fbba14868301c9c49d - https://git.kernel.org/stable/c/136bed0bfd3bc9c95c88aa
it.kernel.org/stable/c/f2ec3cd0f34f8c3f94bc21fbba14868301c9c49d - https://git.kernel.org/stable/c/136bed0bfd3bc9c95c88aafff2d22ecb3a919f23
CVE ID: CVE-2022-49152 State: PUBLISHED Published: 2025-02-26T01:55:18.249Z Last Updated: 2025-06-19T12:39:06.923Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: XArray: Fix xas_create_range() when multi-order entry present If there is already an entry present that is of order >= XA_CHUNK_SHIFT when we call xas_create_range(), xas_create_range() will misinterpret that entry as a node and dereference xa_node->parent, generally leading to a crash that looks something like this: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x00000000000
for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 32 Comm: khugepaged Not tainted 5.17.0-rc8-syzkaller-00003-g56e337f2cf13 #0 RIP: 0010:xa_parent_locked include/linux/xarray.h:1207 [inline] RIP: 0010:xas_create_range+0x2d9/0x6e0 lib/xarray.c:725 It's deterministically reproducable once you know what the problem is, but producing it in a live kernel requires khugepaged to hit a race. While the problem has been present since xas_create_range() was introduced, I'm not aware of a way to hit it before the page cache was converted to use multi-index entries. References: - https://git.kernel.
are of a way to hit it before the page cache was converted to use multi-index entries. References: - https://git.kernel.org/stable/c/18f13edf3424b3b61814b69d5269b2e14584800c - https://git.kernel.org/stable/c/3e3c658055c002900982513e289398a1aad4a488
CVE ID: CVE-2022-49153 State: PUBLISHED Published: 2025-02-26T01:55:18.745Z Last Updated: 2025-10-01T19:57:01.052Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wireguard: socket: free skb in send6 when ipv6 is disabled I got a memory leak report: unreferenced object 0xffff8881191fc040 (size 232): comm "kworker/u17:0", pid 23193, jiffies 4295238848 (age 3464.870s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814c3ef4>] slab_post_alloc_hook+0x84/0x3b0 [<ffffffff814c8977>] kmem_cache_alloc_node+0x1
......... backtrace: [<ffffffff814c3ef4>] slab_post_alloc_hook+0x84/0x3b0 [<ffffffff814c8977>] kmem_cache_alloc_node+0x167/0x340 [<ffffffff832974fb>] __alloc_skb+0x1db/0x200 [<ffffffff82612b5d>] wg_socket_send_buffer_to_peer+0x3d/0xc0 [<ffffffff8260e94a>] wg_packet_send_handshake_initiation+0xfa/0x110 [<ffffffff8260ec81>] wg_packet_handshake_send_worker+0x21/0x30 [<ffffffff8119c558>] process_one_work+0x2e8/0x770 [<ffffffff8119ca2a>] worker_thread+0x4a/0x4b0 [<ffffffff811a88e0>] kthread+0x120/0x160 [<ffffffff8100242f>] ret_from_fork+0x1f/0x30 In function wg_socket_send_buffer_as_reply_to_skb() or wg_socket_send_ buffer_to_peer(), the semantics of send6() is required to free skb. But when CONF
r_as_reply_to_skb() or wg_socket_send_ buffer_to_peer(), the semantics of send6() is required to free skb. But when CONFIG_IPV6 is disable, kfree_skb() is missing. This patch adds it to fix this bug. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/096f9d35cac0a0c95ffafc00db84786b665a4837 - https://git.kernel.org/stable/c/402991a9771587acc2947cf6c4d689c5397f2258 - https://git.kernel.org/stable/c/ebcc492f4ba14bae54b898f1016a37b4282558d1 - https://git.kernel.org/stable/c/0b19bcb753dbfb74710d12bb2761ec5ed706c726 - https://git.kernel.org/stable/c/bbbf962d9460194993ee1943a793a0a0af4a7fbf
CVE ID: CVE-2022-49154 State: PUBLISHED Published: 2025-02-26T01:55:19.245Z Last Updated: 2025-06-19T12:56:15.928Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: fix panic on out-of-bounds guest IRQ As guest_irq is coming from KVM_IRQFD API call, it may trigger crash in svm_update_pi_irte() due to out-of-bounds: crash> bt PID: 22218 TASK: ffff951a6ad74980 CPU: 73 COMMAND: "vcpu8" #0 [ffffb1ba6707fa40] machine_kexec at ffffffff8565b397 #1 [ffffb1ba6707fa90] __crash_kexec at ffffffff85788a6d #2 [ffffb1ba6707fb58] crash_kexec at ffffffff8578995d #3 [ffffb1ba6707fb70] oops_end at ffffffff85623c0d #4 [ffffb1ba6707fb90] no_
ba6707fb58] crash_kexec at ffffffff8578995d #3 [ffffb1ba6707fb70] oops_end at ffffffff85623c0d #4 [ffffb1ba6707fb90] no_context at ffffffff856692c9 #5 [ffffb1ba6707fbf8] exc_page_fault at ffffffff85f95b51 #6 [ffffb1ba6707fc50] asm_exc_page_fault at ffffffff86000ace [exception RIP: svm_update_pi_irte+227] RIP: ffffffffc0761b53 RSP: ffffb1ba6707fd08 RFLAGS: 00010086 RAX: ffffb1ba6707fd78 RBX: ffffb1ba66d91000 RCX: 0000000000000001 RDX: 00003c803f63f1c0 RSI: 000000000000019a RDI: ffffb1ba66db2ab8 RBP: 000000000000019a R8: 0000000000000040 R9: ffff94ca41b82200 R10: ffffffffffffffcf R11: 0000000000000001 R12: 0000000000000001 R13: 0000000000000001 R14: ffffffffffffffcf R15: 000000000000005f ORIG_