Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
00 CR3: 000000000d08e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __refcount_dec include/linux/refcount.h:344 [inline] refcount_dec include/linux/refcount.h:359 [inline] __sock_put include/net/sock.h:779 [inline] tcp_release_cb+0x2d0/0x360 net/ipv4/tcp_output.c:1092 release_sock+0xaf/0x1c0 net/core/sock.c:3468 sock_map_free+0x219/0x2c0 net/core/sock_map.c:356 process_one_work+0x81c/0xd10 kernel/workqueue.c:2289 worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK>
/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> References: - https://git.kernel.org/stable/c/4cabc3af4a6f36c222fecb15858c1060e59218e7 - https://git.kernel.org/stable/c/be719496ae6a7fc325e9e5056a52f63ebc84cc0c - https://git.kernel.org/stable/c/a443c55d96dede82a724df6e70a318ad15c199e1 - https://git.kernel.org/stable/c/e8b2b392a646bf5cb9413c1cc7a39d99c1b65a62 - https://git.kernel.org/stable/c/5c3568166129bc73fd6b37748d2d8f95cd8f22f3 - https://git.kernel.org/stable/c/0a182f8d607464911756b4dbef5d6cad8de22469
CVE ID: CVE-2022-50260 State: PUBLISHED Published: 2025-09-15T14:02:50.710Z Last Updated: 2025-09-15T14:02:50.710Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/msm: Make .remove and .shutdown HW shutdown consistent Drivers' .remove and .shutdown callbacks are executed on different code paths. The former is called when a device is removed from the bus, while the latter is called at system shutdown time to quiesce the device. This means that some overlap exists between the two, because both have to take care of properly shutting down the hardware. But currently the logic used in these two callbacks isn't consistent in msm d
re of properly shutting down the hardware. But currently the logic used in these two callbacks isn't consistent in msm drivers, which could lead to kernel panic. For example, on .remove the component is deleted and its .unbind callback leads to the hardware being shutdown but only if the DRM device has been marked as registered. That check doesn't exist in the .shutdown logic and this can lead to the driver calling drm_atomic_helper_shutdown() for a DRM device that hasn't been properly initialized. A situation like this can happen if drivers for expected sub-devices fail to probe, since the .bind callback will never be executed. If that is the case, drm_atomic_helper_shutdown() will attempt
probe, since the .bind callback will never be executed. If that is the case, drm_atomic_helper_shutdown() will attempt to take mutexes that are only initialized if drm_mode_config_init() is called during a device bind. This bug was attempted to be fixed in commit 623f279c7781 ("drm/msm: fix shutdown hook in case GPU components failed to bind"), but unfortunately it still happens in some cases as the one mentioned above, i.e: systemd-shutdown[1]: Powering off. kvm: exiting hardware virtualization platform wifi-firmware.0: Removing from iommu group 12 platform video-firmware.0: Removing from iommu group 10 ------------[ cut here ]------------ WARNING: CPU: 6 PID: 1 at drivers/gpu/drm/drm_mode
.0: Removing from iommu group 10 ------------[ cut here ]------------ WARNING: CPU: 6 PID: 1 at drivers/gpu/drm/drm_modeset_lock.c:317 drm_modeset_lock_all_ctx+0x3c4/0x3d0 ... Hardware name: Google CoachZ (rev3+) (DT) pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_modeset_lock_all_ctx+0x3c4/0x3d0 lr : drm_modeset_lock_all_ctx+0x48/0x3d0 sp : ffff80000805bb80 x29: ffff80000805bb80 x28: ffff327c00128000 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000001 x24: ffffc95d820ec030 x23: ffff327c00bbd090 x22: ffffc95d8215eca0 x21: ffff327c039c5800 x20: ffff327c039c5988 x19: ffff80000805bbe8 x18: 0000000000000034 x17: 000000040044ffff x16: ffffc95d80cac920 x15:
5800 x20: ffff327c039c5988 x19: ffff80000805bbe8 x18: 0000000000000034 x17: 000000040044ffff x16: ffffc95d80cac920 x15: 0000000000000000 x14: 0000000000000315 x13: 0000000000000315 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff80000805bc28 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff327c00128000 x1 : 0000000000000000 x0 : ffff327c039c59b0 Call trace: drm_modeset_lock_all_ctx+0x3c4/0x3d0 drm_atomic_helper_shutdown+0x70/0x134 msm_drv_shutdown+0x30/0x40 platform_shutdown+0x28/0x40 device_shutdown+0x148/0x350 kernel_power_off+0x38/0x80 __do_sys_reboot+0x288/0x2c0 __arm64_
platform_shutdown+0x28/0x40 device_shutdown+0x148/0x350 kernel_power_off+0x38/0x80 __do_sys_reboot+0x288/0x2c0 __arm64_sys_reboot+0x28/0x34 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0x44/0xec do_el0_svc+0x2c/0xc0 el0_svc+0x2c/0x84 el0t_64_sync_handler+0x11c/0x150 el0t_64_sync+0x18c/0x190 ---[ end trace 0000000000000000 ]--- Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010eab1000 [00
Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010eab1000 [0000000000000018] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP ... Hardware name: Google CoachZ (rev3+) (DT) pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ww_mutex_lock+0x28/0x32c lr : drm_modeset_lock_all_ctx+0x1b0/0x3d0 sp : ffff80000805bb50 x29: ffff80000805bb50 x28: ffff327c00128000 x27: 0000000000000000 x26: 00000 ---truncated--- References: - https://git.kernel.org/stable/c/26f9a766f87b33c50ed400a9500cc1dc9aced953 - https://git.kernel.org/stable/c/0e6649a2e31ac157c711d583ec8f5ec59da5de0e - https://git.
7b33c50ed400a9500cc1dc9aced953 - https://git.kernel.org/stable/c/0e6649a2e31ac157c711d583ec8f5ec59da5de0e - https://git.kernel.org/stable/c/0a58d2ae572adaec8d046f8d35b40c2c32ac7468
CVE ID: CVE-2022-50261 State: PUBLISHED Published: 2025-09-15T14:03:04.439Z Last Updated: 2025-09-15T14:03:04.439Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/sti: Fix return type of sti_{dvo,hda,hdmi}_connector_mode_valid() With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compi
ch manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals: drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_hda_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)'
atible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_dvo_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_hdmi_connector_mode_valid, ^~~~~~~
lay_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict] .mode_valid = sti_hdmi_connector_mode_valid, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ->mode_valid() in 'struct drm_connector_helper_funcs' expects a return type of 'enum drm_mode_status', not 'int'. Adjust the return type of sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to resolve the warning and CFI failure. References: - https://git.kernel.org/stable/c/b2c92b2a3801b09b709cbefd9a9e4944b72400bf - https://git.kernel.org/stable/c/b4307c7d35e346b909edfdc1f280902150570bb6 - https://git.kernel.org/stable/c/8f9941dea3a70b73f2063f9dcc4aaae6af03c5ba - https://git.kernel.org/stable/c/511b48ee8e4aec2d03d2af06b363d9eb3230b01
ble/c/8f9941dea3a70b73f2063f9dcc4aaae6af03c5ba - https://git.kernel.org/stable/c/511b48ee8e4aec2d03d2af06b363d9eb3230b017 - https://git.kernel.org/stable/c/6e3c4d3fa5d458d685561ecbaf8daa9dba14979e - https://git.kernel.org/stable/c/a075c21ee026f4a74f9fce5928ea3c8d18a8af13 - https://git.kernel.org/stable/c/e578b0906b6a81479cd5b5b6c848a7096addf5e9 - https://git.kernel.org/stable/c/04371a75a58422a301a9ff9ae3babd310ac3bb3f - https://git.kernel.org/stable/c/0ad811cc08a937d875cbad0149c1bab17f84ba05
CVE ID: CVE-2022-50262 State: PUBLISHED Published: 2025-09-15T14:20:58.578Z Last Updated: 2025-09-16T08:02:03.947Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Validate BOOT record_size When the NTFS BOOT record_size field < 0, it represents a shift value. However, there is no sanity check on the shift result and the sbi->record_bits calculation through blksize_bits() assumes the size always > 256, which could lead to NPD while mounting a malformed NTFS image. [ 318.675159] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 318.675682] #PF: supervisor read access in kernel mode [ 318.675869] #PF: erro
dereference, address: 0000000000000158 [ 318.675682] #PF: supervisor read access in kernel mode [ 318.675869] #PF: error_code(0x0000) - not-present page [ 318.676246] PGD 0 P4D 0 [ 318.676502] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 318.676934] CPU: 0 PID: 259 Comm: mount Not tainted 5.19.0 #5 [ 318.677289] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 318.678136] RIP: 0010:ni_find_attr+0x2d/0x1c0 [ 318.678656] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180 [ 318.679848] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246 [ 318.680104] RAX: 000000000000
25 28 00 00 00 48 89 44 24 180 [ 318.679848] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246 [ 318.680104] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080 [ 318.680790] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 318.681679] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 318.682577] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080 [ 318.683015] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000 [ 318.683618] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000 [ 318.684280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 318.684651] CR2: 0000000000000158 CR3: 0000000002e1a000
318.684280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 318.684651] CR2: 0000000000000158 CR3: 0000000002e1a000 CR4: 00000000000006f0 [ 318.685623] Call Trace: [ 318.686607] <TASK> [ 318.686872] ? ntfs_alloc_inode+0x1a/0x60 [ 318.687235] attr_load_runs_vcn+0x2b/0xa0 [ 318.687468] mi_read+0xbb/0x250 [ 318.687576] ntfs_iget5+0x114/0xd90 [ 318.687750] ntfs_fill_super+0x588/0x11b0 [ 318.687953] ? put_ntfs+0x130/0x130 [ 318.688065] ? snprintf+0x49/0x70 [ 318.688164] ? put_ntfs+0x130/0x130 [ 318.688256] get_tree_bdev+0x16a/0x260 [ 318.688407] vfs_get_tree+0x20/0xb0 [ 318.688519] path_mount+0x2dc/0x9b0 [ 318.688877] do_mount+0x74/0x90 [ 318.689142] __x64_sys_mount+0x89/0xd0 [ 318.689636] do
688519] path_mount+0x2dc/0x9b0 [ 318.688877] do_mount+0x74/0x90 [ 318.689142] __x64_sys_mount+0x89/0xd0 [ 318.689636] do_syscall_64+0x3b/0x90 [ 318.689998] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 318.690318] RIP: 0033:0x7fd9e133c48a [ 318.690687] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 318.691357] RSP: 002b:00007ffd374406c8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 [ 318.691632] RAX: ffffffffffffffda RBX: 0000564d0b051080 RCX: 00007fd9e133c48a [ 318.691920] RDX: 0000564d0b051280 RSI: 0000564d0b051300 RDI: 0000564d0b0596a0 [ 318.692123] RBP: 0000000000000000 R08: 0000564d0b0512a0 R09: 000000000000002
I: 0000564d0b051300 RDI: 0000564d0b0596a0 [ 318.692123] RBP: 0000000000000000 R08: 0000564d0b0512a0 R09: 0000000000000020 [ 318.692349] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564d0b0596a0 [ 318.692673] R13: 0000564d0b051280 R14: 0000000000000000 R15: 00000000ffffffff [ 318.693007] </TASK> [ 318.693271] Modules linked in: [ 318.693614] CR2: 0000000000000158 [ 318.694446] ---[ end trace 0000000000000000 ]--- [ 318.694779] RIP: 0010:ni_find_attr+0x2d/0x1c0 [ 318.694952] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180 [ 318.696042] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246 [ 318.696531] RAX: 0000000000
4 25 28 00 00 00 48 89 44 24 180 [ 318.696042] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246 [ 318.696531] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080 [ 318.698114] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 318.699286] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 318.699795] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080 [ 318.700236] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000 [ 318.700973] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000 [ ---truncated--- References: - https://git.kernel.org/stable/c/af7a195deae349f15baa765d000a5188920d61dd - https://git.
[ ---truncated--- References: - https://git.kernel.org/stable/c/af7a195deae349f15baa765d000a5188920d61dd - https://git.kernel.org/stable/c/8702e0dc987014f6d77740b693340f91344fd0ae - https://git.kernel.org/stable/c/db91a9c59162a9c56792ded88160442c0a2dabd5 - https://git.kernel.org/stable/c/0b66046266690454dc04e6307bcff4a5605b42a1
CVE ID: CVE-2022-50263 State: PUBLISHED Published: 2025-09-15T14:20:59.436Z Last Updated: 2025-09-15T14:20:59.436Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vdpasim: fix memory leak when freeing IOTLBs After commit bda324fd037a ("vdpasim: control virtqueue support"), vdpasim->iommu became an array of IOTLB, so we should clean the mappings of each free one by one instead of just deleting the ranges in the first IOTLB which may leak maps. References: - https://git.kernel.org/stable/c/54b210c90d2803a9f1c8fd2f0d08e90172e9a06d - https://git.kernel.org/stable/c/16b22e27fba6fd816d0dcb98f42cc71f0836c27e - https://git.kernel.org/st
f0d08e90172e9a06d - https://git.kernel.org/stable/c/16b22e27fba6fd816d0dcb98f42cc71f0836c27e - https://git.kernel.org/stable/c/0b7a04a30eef20e6b24926a45c0ce7906ae85bd6
CVE ID: CVE-2022-50264 State: PUBLISHED Published: 2025-09-15T14:21:00.379Z Last Updated: 2025-09-15T14:21:00.379Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: clk: socfpga: Fix memory leak in socfpga_gate_init() Free @socfpga_clk and @ops on the error path to avoid memory leak issue. References: - https://git.kernel.org/stable/c/6f2198914fb9aac286a6ff6cf09b23752141e04f - https://git.kernel.org/stable/c/3e8fd1d0fab4d5c9a50d225dddc207deac12f13a - https://git.kernel.org/stable/c/9de42116fc4540f6a1ceb51fd037b734ab7be12e - https://git.kernel.org/stable/c/9f9bb9f5ba9fd501a90f255eb746b4cf2ceeaaae - https://git.kernel.org/stable/c/b
4ab7be12e - https://git.kernel.org/stable/c/9f9bb9f5ba9fd501a90f255eb746b4cf2ceeaaae - https://git.kernel.org/stable/c/bd72ab5e6fc1c4d3e6b84636141d26a41b977b03 - https://git.kernel.org/stable/c/0b8ba891ad4d1ef6bfa4c72efc83f9f9f855f68b
CVE ID: CVE-2022-50265 State: PUBLISHED Published: 2025-09-15T14:21:01.380Z Last Updated: 2025-09-15T14:21:01.380Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: kcm: annotate data-races around kcm->rx_wait kcm->rx_psock can be read locklessly in kcm_rfree(). Annotate the read and writes accordingly. syzbot reported: BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfree write to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1: reserve_rx_kcm net/kcm/kcmsock.c:283 [inline] kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363 __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301 strp_recv+0x6d/0x80 net/strparser/strparser.c:3
/kcm/kcmsock.c:363 __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301 strp_recv+0x6d/0x80 net/strparser/strparser.c:335 tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703 strp_read_sock net/strparser/strparser.c:358 [inline] do_strp_work net/strparser/strparser.c:406 [inline] strp_work+0xe8/0x180 net/strparser/strparser.c:415 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0: kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181 skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841 skb_release_al
pu 0: kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181 skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841 skb_release_all net/core/skbuff.c:852 [inline] __kfree_skb net/core/skbuff.c:868 [inline] kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891 kfree_skb include/linux/skbuff.h:1216 [inline] kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161 ____sys_recvmsg+0x16c/0x2e0 ___sys_recvmsg net/socket.c:2743 [inline] do_recvmmsg+0x2f1/0x710 net/socket.c:2837 __sys_recvmmsg net/socket.c:2916 [inline] __do_sys_recvmmsg net/socket.c:2939 [inline] __se_sys_recvmmsg net/socket.c:2932 [inline] __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2
ne] __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x01 -> 0x00 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 References: - https://git.kernel.org/stable/c/dbc3a0b917c4f75292b1c0819c188e40fd3c8924 - https://git.kernel.org/stable/c/9ae47f11493509cde707af8ecc7eee04c8b8e635 - https://git.kernel.org/stable/c/f1f7122bb2ef056afc6f91ce4c35ab6df1207c8d - htt
ae47f11493509cde707af8ecc7eee04c8b8e635 - https://git.kernel.org/stable/c/f1f7122bb2ef056afc6f91ce4c35ab6df1207c8d - https://git.kernel.org/stable/c/663682cd3192dd4f3547b7890a4391c72441001d - https://git.kernel.org/stable/c/e2a28807b1ceaa309164b92c38d73d12feea33df - https://git.kernel.org/stable/c/62086d1c4602e4f2ec07b975165afc2ed0ff1be9 - https://git.kernel.org/stable/c/2733fb2ad5bfbe6538f2f93a21f2504e3dba9d6a - https://git.kernel.org/stable/c/0c745b5141a45a076f1cb9772a399f7ebcb0948a
CVE ID: CVE-2022-50266 State: PUBLISHED Published: 2025-09-15T14:21:02.529Z Last Updated: 2025-09-15T14:21:02.529Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: kprobes: Fix check for probe enabled in kill_kprobe() In kill_kprobe(), the check whether disarm_kprobe_ftrace() needs to be called always fails. This is because before that we set the KPROBE_FLAG_GONE flag for kprobe so that "!kprobe_disabled(p)" is always false. The disarm_kprobe_ftrace() call introduced by commit: 0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler") to fix the NULL pointer reference problem. When the probe is enabled, if w
ointer dereference at kprobe_ftrace_handler") to fix the NULL pointer reference problem. When the probe is enabled, if we do not disarm it, this problem still exists. Fix it by putting the probe enabled check before setting the KPROBE_FLAG_GONE flag. References: - https://git.kernel.org/stable/c/f20a067f13106565816b4b6a6b665b2088a63824 - https://git.kernel.org/stable/c/c909985dd0c0f74b61e3f8f0e04bf8aa9c8b97c7 - https://git.kernel.org/stable/c/0c76ef3f26d5ef2ac2c21b47e7620cff35809fbb
CVE ID: CVE-2022-50267 State: PUBLISHED Published: 2025-09-15T14:21:03.372Z Last Updated: 2025-09-15T14:21:03.372Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mmc: rtsx_pci: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and calling mmc_free_host() in the error path, beside, runtime PM also needs be disabled. References: - https://git.kernel.org/stable/c/30dc645461dfc63e52b3af8ee4
ath, beside, runtime PM also needs be disabled. References: - https://git.kernel.org/stable/c/30dc645461dfc63e52b3af8ee4a98e17bf14bacf - https://git.kernel.org/stable/c/5cd4e04eccaec140da6fa04db056a76282ee6852 - https://git.kernel.org/stable/c/ffa9b2a79e3e959683efbad3f6db937eca9d38f5 - https://git.kernel.org/stable/c/0c87db77423a282b3b38b8a6daf057b822680516
CVE ID: CVE-2022-50268 State: PUBLISHED Published: 2025-09-15T14:21:04.555Z Last Updated: 2025-09-15T14:21:04.555Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mmc: moxart: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(). References: - https://git.kernel.org/stable/c/a4c765f5d8e58138cff69f1510b2e8942ec37022 - https://git.kernel.org
_host(). References: - https://git.kernel.org/stable/c/a4c765f5d8e58138cff69f1510b2e8942ec37022 - https://git.kernel.org/stable/c/a94d466f31a5201995d39bc1208e2c09ab04f0bf - https://git.kernel.org/stable/c/c7e9a2059fb943fc3c3fa12261518fd72a0fc136 - https://git.kernel.org/stable/c/b174f2b36c638fc7737df6c8aac1889a646be98f - https://git.kernel.org/stable/c/7c3b301ca8b0cab392c71da8fcdfa499074f8e97 - https://git.kernel.org/stable/c/f0502fe86a2db2336c9498d2de3e97f22dcf85ae - https://git.kernel.org/stable/c/8f8bb62c7c5c833758ef1563fe738afd579c3efe - https://git.kernel.org/stable/c/40aa73c70e8a5706f9cbe01409a5e51cc0f1750e - https://git.kernel.org/stable/c/0ca18d09c744fb030ae9bc5836c3e357e0237dea
CVE ID: CVE-2022-50269 State: PUBLISHED Published: 2025-09-15T14:21:05.485Z Last Updated: 2025-09-15T14:21:05.485Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/vkms: Fix memory leak in vkms_init() A memory leak was reported after the vkms module install failed. unreferenced object 0xffff88810bc28520 (size 16): comm "modprobe", pid 9662, jiffies 4298009455 (age 42.590s) hex dump (first 16 bytes): 01 01 00 64 81 88 ff ff 00 00 dc 0a 81 88 ff ff ...d............ backtrace: [<00000000e7561ff8>] kmalloc_trace+0x27/0x60 [<000000000b1954a0>] 0xffffffffc45200a9 [<00000000abbf1da0>] do_one_initcall+0xd0/0x4f0 [<000000001505ee87>]