CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-27400 – drm/amdgpu: once more fix the call oder in amdgpu_ttm_move() v2
https://notcve.org/view.php?id=CVE-2024-27400
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: once more fix the call oder in amdgpu_ttm_move() v2 This reverts drm/amdgpu: fix ftrace event amdgpu_bo_move always move on same heap. The basic problem here is that after the move the old location is simply not available any more. Some fixes were suggested, but essentially we should call the move notification before actually moving things because only this way we have the correct order for DMA-buf and VM move notifications as well. Also rework the statistic handling so that we don't update the eviction counter before the move. v2: add missing NULL check En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: una vez más corrige la llamada oder en amdgpu_ttm_move() v2. Esto revierte drm/amdgpu: corrige el evento ftrace amdgpu_bo_move siempre se mueve en el mismo montón. El problema básico aquí es que después de la mudanza, la antigua ubicación simplemente ya no está disponible. Se sugirieron algunas correcciones, pero esencialmente deberíamos llamar a la notificación de movimiento antes de mover cosas porque solo así tenemos el orden correcto para las notificaciones de movimiento de DMA-buf y VM también. • https://git.kernel.org/stable/c/d443fb67ca5ab04760449d21ddea66f6728e5b00 https://git.kernel.org/stable/c/e7a0ee45c653784edda5e36bae6ae3c75fd5e7a8 https://git.kernel.org/stable/c/94aeb4117343d072e3a35b9595bcbfc0058ee724 https://git.kernel.org/stable/c/77bcd4ab446fa35ad135b1c7404415ed9a129296 https://git.kernel.org/stable/c/1cd2b612474c07b17a21e27f2eed8dff75cb5057 https://git.kernel.org/stable/c/5c25b169f9a0b34ee410891a96bc9d7b9ed6f9be https://git.kernel.org/stable/c/0c7ed3ed35eec9138b88d42217b5a6b9a62bda4d https://git.kernel.org/stable/c/9a4f6e138720b6e9adf7b82a71d0292f3 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-27399 – Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout
https://notcve.org/view.php?id=CVE-2024-27399
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout There is a race condition between l2cap_chan_timeout() and l2cap_chan_del(). When we use l2cap_chan_del() to delete the channel, the chan->conn will be set to null. But the conn could be dereferenced again in the mutex_lock() of l2cap_chan_timeout(). As a result the null pointer dereference bug will happen. The KASAN report triggered by POC is shown below: [ 472.074580] ================================================================== [ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0 [ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7 [ 472.075308] [ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36 [ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4 [ 472.075308] Workqueue: events l2cap_chan_timeout [ 472.075308] Call Trace: [ 472.075308] <TASK> [ 472.075308] dump_stack_lvl+0x137/0x1a0 [ 472.075308] print_report+0x101/0x250 [ 472.075308] ? __virt_addr_valid+0x77/0x160 [ 472.075308] ? • https://git.kernel.org/stable/c/3df91ea20e744344100b10ae69a17211fcf5b207 https://git.kernel.org/stable/c/e137e2ba96e51902dc2878131823a96bf8e638ae https://git.kernel.org/stable/c/6466ee65e5b27161c846c73ef407f49dfa1bd1d9 https://git.kernel.org/stable/c/06acb75e7ed600d0bbf7bff5628aa8f24a97978c https://git.kernel.org/stable/c/e97e16433eb4533083b096a3824b93a5ca3aee79 https://git.kernel.org/stable/c/8960ff650aec70485b40771cd8e6e8c4cb467d33 https://git.kernel.org/stable/c/955b5b6c54d95b5e7444dfc81c95c8e013f27ac0 https://git.kernel.org/stable/c/eb86f955488c39526534211f2610e48a5 •
CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2024-27398 – Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout
https://notcve.org/view.php?id=CVE-2024-27398
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout When the sco connection is established and then, the sco socket is releasing, timeout_work will be scheduled to judge whether the sco disconnection is timeout. The sock will be deallocated later, but it is dereferenced again in sco_sock_timeout. As a result, the use-after-free bugs will happen. The root cause is shown below: Cleanup Thread | Worker Thread sco_sock_release | sco_sock_close | __sco_sock_close | sco_sock_set_timer | schedule_delayed_work | sco_sock_kill | (wait a time) sock_put(sk) //FREE | sco_sock_timeout | sock_hold(sk) //USE The KASAN report triggered by POC is shown below: [ 95.890016] ================================================================== [ 95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0 [ 95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7 ... [ 95.890755] Workqueue: events sco_sock_timeout [ 95.890755] Call Trace: [ 95.890755] <TASK> [ 95.890755] dump_stack_lvl+0x45/0x110 [ 95.890755] print_address_description+0x78/0x390 [ 95.890755] print_report+0x11b/0x250 [ 95.890755] ? __virt_addr_valid+0xbe/0xf0 [ 95.890755] ? • https://git.kernel.org/stable/c/48669c81a65628ef234cbdd91b9395952c7c27fe https://git.kernel.org/stable/c/37d7ae2b0578f2373674a755402ee722e96edc08 https://git.kernel.org/stable/c/a1073aad497d0d071a71f61b721966a176d50c08 https://git.kernel.org/stable/c/ba316be1b6a00db7126ed9a39f9bee434a508043 https://git.kernel.org/stable/c/fea63ccd928c01573306983346588b26cffb5572 https://git.kernel.org/stable/c/ec1f74319bb35c1c90c25014ec0f6ea6c3ca2134 https://git.kernel.org/stable/c/b657bba82ff6a007d84fd076bd73b11131726a2b https://git.kernel.org/stable/c/1b33d55fb7355e27f8c82cd4ecd560f16 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52655 – usb: aqc111: check packet for fixup for true limit
https://notcve.org/view.php?id=CVE-2023-52655
In the Linux kernel, the following vulnerability has been resolved: usb: aqc111: check packet for fixup for true limit If a device sends a packet that is inbetween 0 and sizeof(u64) the value passed to skb_trim() as length will wrap around ending up as some very large value. The driver will then proceed to parse the header located at that position, which will either oops or process some random value. The fix is to check against sizeof(u64) rather than 0, which the driver currently does. The issue exists since the introduction of the driver. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: aqc111: verifique el paquete para corregir el límite verdadero Si un dispositivo envía un paquete que está entre 0 y sizeof(u64), el valor pasado a skb_trim() como longitud se ajustará terminando como un valor muy grande. Luego, el controlador procederá a analizar el encabezado ubicado en esa posición, lo que procesará algún valor aleatorio. La solución es compararlo con sizeof(u64) en lugar de 0, como hace actualmente el controlador. • https://git.kernel.org/stable/c/84f2e5b3e70f08fce3cb1ff73414631c5e490204 https://git.kernel.org/stable/c/d69581c17608d81824dd497d9a54b6a5b6139975 https://git.kernel.org/stable/c/46412b2fb1f9cc895d6d4036bf24f640b5d86dab https://git.kernel.org/stable/c/82c386d73689a45d5ee8c1290827bce64056dddd https://git.kernel.org/stable/c/2ebf775f0541ae0d474836fa0cf3220e502f8e3e https://git.kernel.org/stable/c/ccab434e674ca95d483788b1895a70c21b7f016a •
CVSS: 7.0EPSS: 0%CPEs: 7EXPL: 0CVE-2024-27397 – netfilter: nf_tables: use timestamp to check for set element timeout
https://notcve.org/view.php?id=CVE-2024-27397
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: use timestamp to check for set element timeout Add a timestamp field at the beginning of the transaction, store it in the nftables per-netns area. Update set backend .insert, .deactivate and sync gc path to use the timestamp, this avoids that an element expires while control plane transaction is still unfinished. .lookup and .update, which are used from packet path, still use the current time to check if the element has expired. And .get path and dump also since this runs lockless under rcu read size lock. Then, there is async gc which also needs to check the current time since it runs asynchronously from a workqueue. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nf_tables: use la marca de tiempo para verificar el tiempo de espera del elemento establecido. Agregue un campo de marca de tiempo al comienzo de la transacción y guárdelo en el área nftables per-netns. • https://git.kernel.org/stable/c/c3e1b005ed1cc068fc9d454a6e745830d55d251d https://git.kernel.org/stable/c/f8dfda798650241c1692058713ca4fef8e429061 https://git.kernel.org/stable/c/eaf1a29ea5d7dba8e84e9e9f3b3f47d0cd540bfe https://git.kernel.org/stable/c/7b17de2a71e56c10335b565cc7ad238e6d984379 https://git.kernel.org/stable/c/0d40e8cb1d1f56a994cdd2e015af622fdca9ed4d https://git.kernel.org/stable/c/b45176b869673417ace338b87cf9cdb66e2eeb01 https://git.kernel.org/stable/c/383182db8d58c4237772ba0764cded4938a235c3 https://git.kernel.org/stable/c/7395dfacfff65e9938ac0889dafa1ab01 •