CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48775 – Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj
https://notcve.org/view.php?id=CVE-2022-48775
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add()： If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix memory leak by calling kobject_put(). • https://git.kernel.org/stable/c/c2e5df616e1ae6c2a074cb241ebb65a318ebaf7c https://git.kernel.org/stable/c/417947891bd5ae327f15efed1a0da2b12ef24962 https://git.kernel.org/stable/c/fe595759c2a4a5bb41c438474f15947d8ae32f5c https://git.kernel.org/stable/c/91d8866ca55232d21995a3d54fac96de33c9e20c https://git.kernel.org/stable/c/c377e2ba78d3fe9a1f0b4ec424e75f81da7e81e9 https://git.kernel.org/stable/c/92e25b637cd4e010f776c86e4810300e773eac5c https://git.kernel.org/stable/c/8bc69f86328e87a0ffa79438430cc82f3aa6a194 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48774 – dmaengine: ptdma: Fix the error handling path in pt_core_init()
https://notcve.org/view.php?id=CVE-2022-48774
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ptdma: Fix the error handling path in pt_core_init() In order to free resources correctly in the error handling path of pt_core_init(), 2 goto's have to be switched. Otherwise, some resources will leak and we will try to release things that have not been allocated yet. Also move a dev_err() to a place where it is more meaningful. • https://git.kernel.org/stable/c/fa5d823b16a9442d609617abeec31da8b6afa224 https://git.kernel.org/stable/c/3e41445287afa3cf6d572778e5aab31d25e60a8d https://git.kernel.org/stable/c/d7de1e4820c5a42441ff7276174c8c0e63575c1b https://git.kernel.org/stable/c/3c62fd3406e0b2277c76a6984d3979c7f3f1d129 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48773 – xprtrdma: fix pointer derefs in error cases of rpcrdma_ep_create
https://notcve.org/view.php?id=CVE-2022-48773
In the Linux kernel, the following vulnerability has been resolved: xprtrdma: fix pointer derefs in error cases of rpcrdma_ep_create If there are failures then we must not leave the non-NULL pointers with the error value, otherwise `rpcrdma_ep_destroy` gets confused and tries free them, resulting in an Oops. • https://git.kernel.org/stable/c/1e7433fb95ccc01629a5edaa4ced0cd8c98d0ae0 https://git.kernel.org/stable/c/9921c866dc369577c3ebb9adf2383b01b58c18de https://git.kernel.org/stable/c/2526d4d8b209dc5ac1fbeb468149774888b2a141 https://git.kernel.org/stable/c/a9c10b5b3b67b3750a10c8b089b2e05f5e176e33 https://access.redhat.com/security/cve/CVE-2022-48773 https://bugzilla.redhat.com/show_bug.cgi?id=2298109 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2023-52886 – USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
https://notcve.org/view.php?id=CVE-2023-52886
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors(): BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011 CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 ... Allocated by task 758: ... __do_kmalloc_node mm/slab_common.c:966 [inline] __kmalloc+0x5e/0x190 mm/slab_common.c:979 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:680 [inline] usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb/core/hub.c:2407 [inline] usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545 As analyzed by Khazhy Kumykov, the cause of this bug is a race between read_descriptors() and hub_port_init(): The first routine uses a field in udev->descriptor, not expecting it to change, while the second overwrites it. Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") this race couldn't occur, because the routines were mutually exclusive thanks to the device locking. Removing that locking from read_descriptors() exposed it to the race. The best way to fix the bug is to keep hub_port_init() from changing udev->descriptor once udev has been initialized and registered. Drivers expect the descriptors stored in the kernel to be immutable; we should not undermine this expectation. In fact, this change should have been made long ago. So now hub_port_init() will take an additional argument, specifying a buffer in which to store the device descriptor it reads. (If udev has not yet been initialized, the buffer pointer will be NULL and then hub_port_init() will store the device descriptor in udev as before.) This eliminates the data race responsible for the out-of-bounds read. The changes to hub_port_init() appear more extensive than they really are, because of indentation changes resulting from an attempt to avoid writing to other parts of the usb_device structure after it has been initialized. Similar changes should be made to the code that reads the BOS descriptor, but that can be handled in a separate patch later on. • https://git.kernel.org/stable/c/218925bfd5d1436e337c4f961e9c149fbe32de6d https://git.kernel.org/stable/c/77358093331e9769855140bf94a3f00ecdcf4bb1 https://git.kernel.org/stable/c/c87fb861ec185fdc578b4fdc6a05920b6a843840 https://git.kernel.org/stable/c/45bf39f8df7f05efb83b302c65ae3b9bc92b7065 https://git.kernel.org/stable/c/6badaf880edf51a2da7a439699676394dfdef3e5 https://git.kernel.org/stable/c/5f35b5d3bd6914c68f743741443dfd3a64b0e455 https://git.kernel.org/stable/c/a1e89c8b29d003a20ed2dae6bdae1598d1f23e42 https://git.kernel.org/stable/c/1bcb238c54a9c6dc4bded06b06ba7458a •
CVSS: 4.4EPSS: 0%CPEs: 1EXPL: 0CVE-2024-41008 – drm/amdgpu: change vm->task_info handling
https://notcve.org/view.php?id=CVE-2024-41008
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: change vm->task_info handling This patch changes the handling and lifecycle of vm->task_info object. The major changes are: - vm->task_info is a dynamically allocated ptr now, and its uasge is reference counted. - introducing two new helper funcs for task_info lifecycle management - amdgpu_vm_get_task_info: reference counts up task_info before returning this info - amdgpu_vm_put_task_info: reference counts down task_info - last put to task_info() frees task_info from the vm. This patch also does logistical changes required for existing usage of vm->task_info. V2: Do not block all the prints when task_info not found (Felix) V3: Fixed review comments from Felix - Fix wrong indentation - No debug message for -ENOMEM - Add NULL check for task_info - Do not duplicate the debug messages (ti vs no ti) - Get first reference of task_info in vm_init(), put last in vm_fini() V4: Fixed review comments from Felix - fix double reference increment in create_task_info - change amdgpu_vm_get_task_info_pasid - additional changes in amdgpu_gem.c while porting • https://git.kernel.org/stable/c/b8f67b9ddf4f8fe6dd536590712b5912ad78f99c https://access.redhat.com/security/cve/CVE-2024-41008 https://bugzilla.redhat.com/show_bug.cgi?id=2298079 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •