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: 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: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48704 – drm/radeon: add a force flush to delay work when radeon
https://notcve.org/view.php?id=CVE-2022-48704
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: add a force flush to delay work when radeon Although radeon card fence and wait for gpu to finish processing current batch rings, there is still a corner case that radeon lockup work queue may not be fully flushed, and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to put device in D3hot state. Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State. > Configuration and Message requests are the only TLPs accepted by a Function in > the D3hot state. All other received Requests must be handled as Unsupported Requests, > and all received Completions may optionally be handled as Unexpected Completions. This issue will happen in following logs: Unable to handle kernel paging request at virtual address 00008800e0008010 CPU 0 kworker/0:3(131): Oops 0 pc = [<ffffffff811bea5c>] ra = [<ffffffff81240844>] ps = 0000 Tainted: G W pc is at si_gpu_check_soft_reset+0x3c/0x240 ra is at si_dma_is_lockup+0x34/0xd0 v0 = 0000000000000000 t0 = fff08800e0008010 t1 = 0000000000010000 t2 = 0000000000008010 t3 = fff00007e3c00000 t4 = fff00007e3c00258 t5 = 000000000000ffff t6 = 0000000000000001 t7 = fff00007ef078000 s0 = fff00007e3c016e8 s1 = fff00007e3c00000 s2 = fff00007e3c00018 s3 = fff00007e3c00000 s4 = fff00007fff59d80 s5 = 0000000000000000 s6 = fff00007ef07bd98 a0 = fff00007e3c00000 a1 = fff00007e3c016e8 a2 = 0000000000000008 a3 = 0000000000000001 a4 = 8f5c28f5c28f5c29 a5 = ffffffff810f4338 t8 = 0000000000000275 t9 = ffffffff809b66f8 t10 = ff6769c5d964b800 t11= 000000000000b886 pv = ffffffff811bea20 at = 0000000000000000 gp = ffffffff81d89690 sp = 00000000aa814126 Disabling lock debugging due to kernel taint Trace: [<ffffffff81240844>] si_dma_is_lockup+0x34/0xd0 [<ffffffff81119610>] radeon_fence_check_lockup+0xd0/0x290 [<ffffffff80977010>] process_one_work+0x280/0x550 [<ffffffff80977350>] worker_thread+0x70/0x7c0 [<ffffffff80977410>] worker_thread+0x130/0x7c0 [<ffffffff80982040>] kthread+0x200/0x210 [<ffffffff809772e0>] worker_thread+0x0/0x7c0 [<ffffffff80981f8c>] kthread+0x14c/0x210 [<ffffffff80911658>] ret_from_kernel_thread+0x18/0x20 [<ffffffff80981e40>] kthread+0x0/0x210 Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101 <88210000> 4821ed21 So force lockup work queue flush to fix this problem. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/radeon: agregue un vaciado forzado para retrasar el trabajo cuando radeon. Aunque la tarjeta radeon protege y espera a que la gpu termine de procesar los anillos de lotes actuales, todavía existe un caso de esquina en el que el bloqueo de radeon funciona. Es posible que la cola no se haya vaciado por completo y, mientras tanto, la función radeon_suspend_kms() ha llamado a pci_set_power_state() para poner el dispositivo en estado D3hot. • https://git.kernel.org/stable/c/b878da58df2c40b08914d3960e2224040fd1fbfe https://git.kernel.org/stable/c/4e25e8f27fdbdc6fd55cc572a9939bf24500b9e8 https://git.kernel.org/stable/c/c0a45f41fde4a0f2c900f719817493ee5c4a5aa3 https://git.kernel.org/stable/c/c72d97146fc5a4dff381b1737f6167e89860430d https://git.kernel.org/stable/c/826b46fd5974113515abe9e4fc8178009a8ce18c https://git.kernel.org/stable/c/5a7a5b2edac4b05abd744eeaebda46d9dacd952d https://git.kernel.org/stable/c/16cb367daa446923d82e332537f446a4cc784b40 https://git.kernel.org/stable/c/f461950fdc374a3ada5a63c669d997de4 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48695 – scsi: mpt3sas: Fix use-after-free warning
https://notcve.org/view.php?id=CVE-2022-48695
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix use-after-free warning Fix the following use-after-free warning which is observed during controller reset: refcount_t: underflow; use-after-free. WARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpt3sas: Corrija la advertencia de use-after-free. Corrija la siguiente advertencia de use-after-free que se observa durante el reinicio del controlador: refcount_t: underflow; use-after-free. ADVERTENCIA: CPU: 23 PID: 5399 en lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0 A user after-free vulnerability was found in the Linux kernel in the refcount_t variable when performing the controller reset. This issue could lead to denial of service of the system. • https://git.kernel.org/stable/c/b8fc9e91b931215110ba824d1a2983c5f60b6f82 https://git.kernel.org/stable/c/d4959d09b76eb7a4146f5133962b88d3bddb63d6 https://git.kernel.org/stable/c/82efb917eeb27454dc4c6fe26432fc8f6c75bc16 https://git.kernel.org/stable/c/5682c94644fde72f72bded6580c38189ffc856b5 https://git.kernel.org/stable/c/ea10a652ad2ae2cf3eced6f632a5c98f26727057 https://git.kernel.org/stable/c/6229fa494a5949be209bc73afbc5d0a749c2e3c7 https://git.kernel.org/stable/c/41acb064c4e013808bc7d5fc1b506fa449425b0b https://git.kernel.org/stable/c/991df3dd5144f2e6b1c38b8d20ed3d4d2 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48703 – thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR
https://notcve.org/view.php?id=CVE-2022-48703
In the Linux kernel, the following vulnerability has been resolved: thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR In some case, the GDDV returns a package with a buffer which has zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10). Then the data_vault_read() got NULL point dereference problem when accessing the 0x10 value in data_vault. [ 71.024560] BUG: kernel NULL pointer dereference, address: 0000000000000010 This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or NULL value in data_vault. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Thermal/int340x_thermal: maneja data_vault cuando el valor es ZERO_SIZE_PTR. En algunos casos, el GDDV devuelve un paquete con un buffer que tiene longitud cero. Provoca que kmemdup() devuelva ZERO_SIZE_PTR (0x10). • https://git.kernel.org/stable/c/dae42083b045a4ddf71c57cf350cb2412b5915c2 https://git.kernel.org/stable/c/7931e28098a4c1a2a6802510b0cbe57546d2049d •