Page 128 of 2655 results (0.006 seconds)

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind For primary VM Bus channels, primary_channel pointer is always NULL. This pointer is valid only for the secondary channels. Also, rescind callback is meant for primary channels only. Fix NULL pointer dereference by retrieving the device_obj from the parent for the primary channel. • https://git.kernel.org/stable/c/ca3cda6fcf1e922213a0cc58e708ffb999151db3 https://git.kernel.org/stable/c/3d414b64ecf6fd717d7510ffb893c6f23acbf50e https://git.kernel.org/stable/c/f38f46da80a2ab7d1b2f8fcb444c916034a2dac4 https://git.kernel.org/stable/c/1d8e020e51ab07e40f9dd00b52f1da7d96fec04c https://git.kernel.org/stable/c/3005091cd537ef8cdb7530dcb2ecfba8d2ef475c https://git.kernel.org/stable/c/2be373469be1774bbe03b0fa7e2854e65005b1cc https://git.kernel.org/stable/c/de6946be9c8bc7d2279123433495af7c21011b99 https://git.kernel.org/stable/c/928e399e84f4e80307dce44e89415115c •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: VMCI: Fix use-after-free when removing resource in vmci_resource_remove() When removing a resource from vmci_resource_table in vmci_resource_remove(), the search is performed using the resource handle by comparing context and resource fields. It is possible though to create two resources with different types but same handle (same context and resource fields). When trying to remove one of the resources, vmci_resource_remove() may not remove the intended one, but the object will still be freed as in the case of the datagram type in vmci_datagram_destroy_handle(). vmci_resource_table will still hold a pointer to this freed resource leading to a use-after-free vulnerability. BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline] BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106 print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239 __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425 kasan_report+0x38/0x51 mm/kasan/report.c:442 vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline] vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182 ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444 kref_put include/linux/kref.h:65 [inline] vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline] vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195 vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143 __fput+0x261/0xa34 fs/file_table.c:282 task_work_run+0xf0/0x194 kernel/task_work.c:164 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187 exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220 __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline] syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313 do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x6e/0x0 This change ensures the type is also checked when removing the resource from vmci_resource_table in vmci_resource_remove(). • https://git.kernel.org/stable/c/bc63dedb7d46a7d690c6b6edf69136b88af06cc6 https://git.kernel.org/stable/c/f6365931bf7c07b2b397dbb06a4f6573cc9fae73 https://git.kernel.org/stable/c/b243d52b5f6f59f9d39e69b191fb3d58b94a43b1 https://git.kernel.org/stable/c/6c563a29857aa8053b67ee141191f69757f27f6e https://git.kernel.org/stable/c/ef5f4d0c5ee22d4f873116fec844ff6edaf3fa7d https://git.kernel.org/stable/c/b9efdf333174468651be40390cbc79c9f55d9cce https://git.kernel.org/stable/c/39e7e593418ccdbd151f2925fa6be1a616d16c96 https://git.kernel.org/stable/c/00fe5292f081f8d773e572df8e03bf6e1 •

CVSS: -EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix kernel crash if commands allocation fails If the commands allocation fails in nvmet_tcp_alloc_cmds() the kernel crashes in nvmet_tcp_release_queue_work() because of a NULL pointer dereference. nvmet: failed to install queue 0 cntlid 1 ret 6 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Fix the bug by setting queue->nr_cmds to zero in case nvmet_tcp_alloc_cmd() fails. • https://git.kernel.org/stable/c/872d26a391da92ed8f0c0f5cb5fef428067b7f30 https://git.kernel.org/stable/c/03e1fd0327fa5e2174567f5fe9290fe21d21b8f4 https://git.kernel.org/stable/c/50632b877ce55356f5d276b9add289b1e7ddc683 https://git.kernel.org/stable/c/91dad30c5607e62864f888e735d0965567827bdf https://git.kernel.org/stable/c/7957c731fc2b23312f8935812dee5a0b14b04e2d https://git.kernel.org/stable/c/489f2913a63f528cfe3f21722583fb981967ecda https://git.kernel.org/stable/c/6c04d1e3ab22cc5394ef656429638a5947f87244 https://git.kernel.org/stable/c/5572a55a6f830ee3f3a994b6b962a5c32 •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix double put of @cfile in smb2_rename_path() If smb2_set_path_attr() is called with a valid @cfile and returned -EINVAL, we need to call cifs_get_writable_path() again as the reference of @cfile was already dropped by previous smb2_compound_op() call. • https://git.kernel.org/stable/c/1e60bc0e954389af82f1d9a85f13a63f6572350f https://git.kernel.org/stable/c/71f15c90e785d1de4bcd65a279e7256684c25c0d https://git.kernel.org/stable/c/b27ea9c96efd2c252a981fb00d0f001b86c90f3e https://git.kernel.org/stable/c/1a46c7f6546b73cbf36f5a618a1a6bbb45391eb3 https://git.kernel.org/stable/c/3523a3df03c6f04f7ea9c2e7050102657e331a4f •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ublk_drv: fix NULL pointer dereference in ublk_ctrl_start_recovery() When two UBLK_CMD_START_USER_RECOVERY commands are submitted, the first one sets 'ubq->ubq_daemon' to NULL, and the second one triggers WARN in ublk_queue_reinit() and subsequently a NULL pointer dereference issue. Fix it by adding the check in ublk_ctrl_start_recovery() and return immediately in case of zero 'ub->nr_queues_ready'. BUG: kernel NULL pointer dereference, address: 0000000000000028 RIP: 0010:ublk_ctrl_start_recovery.constprop.0+0x82/0x180 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x75/0x170 ? exc_page_fault+0x64/0x140 ? asm_exc_page_fault+0x22/0x30 ? • https://git.kernel.org/stable/c/c732a852b419fa057b53657e2daaf9433940391c https://git.kernel.org/stable/c/ca249435893dda766f3845c15ca77ca5672022d8 https://git.kernel.org/stable/c/136a29d8112df4ea0a57f9602ddf3579e04089dc https://git.kernel.org/stable/c/7c890ef60bf417d3fe5c6f7a9f6cef0e1d77f74f https://git.kernel.org/stable/c/e58f5142f88320a5b1449f96a146f2f24615c5c7 •