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 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-27396 – net: gtp: Fix Use-After-Free in gtp_dellink
https://notcve.org/view.php?id=CVE-2024-27396
In the Linux kernel, the following vulnerability has been resolved: net: gtp: Fix Use-After-Free in gtp_dellink Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal of gtp_dellink, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free. To prevent this, it should be changed to hlist_for_each_entry_safe. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: gtp: corrige Use-After-Free en gtp_dellink Dado que call_rcu, que se llama en el recorrido hlist_for_each_entry_rcu de gtp_dellink, no forma parte de la sección crítica de lectura de RCU, es posible que el período de gracia de RCU pasará durante el recorrido y la clave quedará libre. Para evitar esto, se debe cambiar a hlist_for_each_entry_safe. • https://git.kernel.org/stable/c/043a283d24f40fea4c8a8d06b0e2694c8e372200 https://git.kernel.org/stable/c/c185e1d6e2752a4b656c3ca878c525fa11f55757 https://git.kernel.org/stable/c/94dc550a5062030569d4aa76e10e50c8fc001930 https://git.kernel.org/stable/c/a29c4303930bc0c25ae6a4f365dcdef71447b4ea https://git.kernel.org/stable/c/07b20d0a3dc13fb1adff10b60021a4924498da58 https://git.kernel.org/stable/c/718df1bc226c383dd803397d7f5d95557eb81ac7 https://git.kernel.org/stable/c/0caff3e6390f840666b8dc1ecebf985c2ef3f1dd https://git.kernel.org/stable/c/2e74b3fd6bf542349758f283676dff366 •
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 •