Vulnerabilities > Linux > Linux Kernel > 6.6.25
| DATE | CVE | VULNERABILITY TITLE | RISK |
|---|---|---|---|
| 2024-05-23 | CVE-2024-36012 | Use After Free vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: Bluetooth: msft: fix slab-use-after-free in msft_do_close() Tying the msft->data lifetime to hdev by freeing it in hci_release_dev() to fix the following case: [use] msft_do_close() msft = hdev->msft_data; if (!msft) ...(1) <- passed. return; mutex_lock(&msft->filter_lock); ...(4) <- used after freed. [free] msft_unregister() msft = hdev->msft_data; hdev->msft_data = NULL; ...(2) kfree(msft); ...(3) <- msft is freed. ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0x8f/0xc30 kernel/locking/mutex.c:752 Read of size 8 at addr ffff888106cbbca8 by task kworker/u5:2/309 | 7.8 |
| 2024-05-21 | CVE-2021-47319 | Memory Leak vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: virtio-blk: Fix memory leak among suspend/resume procedure The vblk->vqs should be freed before we call init_vqs() in virtblk_restore(). | 5.5 |
| 2024-05-21 | CVE-2021-47321 | Use After Free vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: watchdog: Fix possible use-after-free by calling del_timer_sync() This driver's remove path calls del_timer(). | 7.8 |
| 2024-05-21 | CVE-2021-47330 | Memory Leak vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: tty: serial: 8250: serial_cs: Fix a memory leak in error handling path In the probe function, if the final 'serial_config()' fails, 'info' is leaking. Add a resource handling path to free this memory. | 5.5 |
| 2024-05-21 | CVE-2021-47334 | Use After Free vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: misc/libmasm/module: Fix two use after free in ibmasm_init_one In ibmasm_init_one, it calls ibmasm_init_remote_input_dev(). Inside ibmasm_init_remote_input_dev, mouse_dev and keybd_dev are allocated by input_allocate_device(), and assigned to sp->remote.mouse_dev and sp->remote.keybd_dev respectively. In the err_free_devices error branch of ibmasm_init_one, mouse_dev and keybd_dev are freed by input_free_device(), and return error. | 7.8 |
| 2024-05-21 | CVE-2021-47345 | Memory Leak vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix rdma_resolve_route() memory leak Fix a memory leak when "mda_resolve_route() is called more than once on the same "rdma_cm_id". This is possible if cma_query_handler() triggers the RDMA_CM_EVENT_ROUTE_ERROR flow which puts the state machine back and allows rdma_resolve_route() to be called again. | 5.5 |
| 2024-05-21 | CVE-2021-47353 | NULL Pointer Dereference vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: udf: Fix NULL pointer dereference in udf_symlink function In function udf_symlink, epos.bh is assigned with the value returned by udf_tgetblk. | 5.5 |
| 2024-05-21 | CVE-2021-47355 | Use After Free vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: atm: nicstar: Fix possible use-after-free in nicstar_cleanup() This module's remove path calls del_timer(). | 7.8 |
| 2024-05-21 | CVE-2021-47357 | Use After Free vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: atm: iphase: fix possible use-after-free in ia_module_exit() This module's remove path calls del_timer(). | 7.8 |
| 2024-05-20 | CVE-2024-35953 | Improper Locking vulnerability in Linux Kernel In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix deadlock in context_xa ivpu_device->context_xa is locked both in kernel thread and IRQ context. It requires XA_FLAGS_LOCK_IRQ flag to be passed during initialization otherwise the lock could be acquired from a thread and interrupted by an IRQ that locks it for the second time causing the deadlock. This deadlock was reported by lockdep and observed in internal tests. | 5.5 |