CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47421 – drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume
https://notcve.org/view.php?id=CVE-2021-47421
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume In current code, when a PCI error state pci_channel_io_normal is detectd, it will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI driver will continue the execution of PCI resume callback report_resume by pci_walk_bridge, and the callback will go into amdgpu_pci_resume finally, where write lock is releasd unconditionally without acquiring such lock first. In this case, a deadlock will happen when other threads start to acquire the read lock. To fix this, add a member in amdgpu_device strucutre to cache pci_channel_state, and only continue the execution in amdgpu_pci_resume when it's pci_channel_io_frozen. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: maneja el caso de pci_channel_io_frozen solo en amdgpu_pci_resume. En el código actual, cuando se detecta un estado de error de PCI pci_channel_io_normal, informará el estado de PCI_ERS_RESULT_CAN_RECOVER al controlador PCI, y el controlador PCI continúe la ejecución de PCI resume callback report_resume mediante pci_walk_bridge, y la devolución de llamada finalmente irá a amdgpu_pci_resume, donde el bloqueo de escritura se libera incondicionalmente sin adquirir dicho bloqueo primero. En este caso, se producirá un punto muerto cuando otros subprocesos comiencen a adquirir el bloqueo de lectura. • https://git.kernel.org/stable/c/c9a6b82f45e261d247b980a7949aaa6a9bfffe01 https://git.kernel.org/stable/c/72e9a1bf9b722628c28092e0c2cd8717edd201dc https://git.kernel.org/stable/c/248b061689a40f4fed05252ee2c89f87cf26d7d8 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47420 – drm/amdkfd: fix a potential ttm->sg memory leak
https://notcve.org/view.php?id=CVE-2021-47420
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix a potential ttm->sg memory leak Memory is allocated for ttm->sg by kmalloc in kfd_mem_dmamap_userptr, but isn't freed by kfree in kfd_mem_dmaunmap_userptr. Free it! En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdkfd: soluciona una posible pérdida de memoria de ttm->sg. La memoria se asigna para ttm->sg mediante kmalloc en kfd_mem_dmamap_userptr, pero kfree no la libera en kfd_mem_dmaunmap_userptr. ¡Libérala! • https://git.kernel.org/stable/c/264fb4d332f5e76743818480e482464437837c52 https://git.kernel.org/stable/c/7e5ce6029b627efb4a004746cfdc1eeff850e6eb https://git.kernel.org/stable/c/b072ef1215aca33186e3a10109e872e528a9e516 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47419 – net/sched: sch_taprio: properly cancel timer from taprio_destroy()
https://notcve.org/view.php?id=CVE-2021-47419
In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_taprio: properly cancel timer from taprio_destroy() There is a comment in qdisc_create() about us not calling ops->reset() in some cases. err_out4: /* * Any broken qdiscs that would require a ops->reset() here? * The qdisc was never in action so it shouldn't be necessary. */ As taprio sets a timer before actually receiving a packet, we need to cancel it from ops->destroy, just in case ops->reset has not been called. syzbot reported: ODEBUG: free active (active state 0) object type: hrtimer hint: advance_sched+0x0/0x9a0 arch/x86/include/asm/atomic64_64.h:22 WARNING: CPU: 0 PID: 8441 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Modules linked in: CPU: 0 PID: 8441 Comm: syz-executor813 Not tainted 5.14.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd e0 d3 e3 89 4c 89 ee 48 c7 c7 e0 c7 e3 89 e8 5b 86 11 05 <0f> 0b 83 05 85 03 92 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3 RSP: 0018:ffffc9000130f330 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 RDX: ffff88802baeb880 RSI: ffffffff815d87b5 RDI: fffff52000261e58 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815d25ee R11: 0000000000000000 R12: ffffffff898dd020 R13: ffffffff89e3ce20 R14: ffffffff81653630 R15: dffffc0000000000 FS: 0000000000f0d300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffb64b3e000 CR3: 0000000036557000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __debug_check_no_obj_freed lib/debugobjects.c:987 [inline] debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1018 slab_free_hook mm/slub.c:1603 [inline] slab_free_freelist_hook+0x171/0x240 mm/slub.c:1653 slab_free mm/slub.c:3213 [inline] kfree+0xe4/0x540 mm/slub.c:4267 qdisc_create+0xbcf/0x1320 net/sched/sch_api.c:1299 tc_modify_qdisc+0x4c8/0x1a60 net/sched/sch_api.c:1663 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340 netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2403 ___sys_sendmsg+0xf3/0x170 net/socket.c:2457 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2486 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: sch_taprio: cancelar correctamente el temporizador de taprio_destroy(). Hay un comentario en qdisc_create() acerca de que no llamamos a ops->reset() en algunos casos. err_out4: /* * ¿Alguna qdisc rota que requiera un ops->reset() aquí? * La qdisc nunca estuvo en acción por lo que no debería ser necesaria. */ Como taprio establece un temporizador antes de recibir un paquete, debemos cancelarlo desde ops->destroy, en caso de que no se haya llamado a ops->reset. syzbot informó: ODEBUG: libre activo (estado activo 0) tipo de objeto: hrtimer sugerencia: advanced_sched+0x0/0x9a0 arch/x86/include/asm/atomic64_64.h:22 ADVERTENCIA: CPU: 0 PID: 8441 en lib/debugobjects.c :505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Módulos vinculados en: CPU: 0 PID: 8441 Comm: syz-executor813 No contaminado 5.14.0-rc6-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Motor, BIOS Google 01/01/2011 RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Código: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd e0 d3 e3 89 4c 89 ee 48 c7 c7 e0 c7 e3 89 e8 5b 86 11 05 <0f> 0b 83 05 85 03 92 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3 RSP 0018:ffff c9000130f330 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 00000000000000003 RCX: 0000000000000000 RDX: ffff88802baeb880 RSI: ffffffff815d87b5 RDI: fffff52000261e58 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815d25ee R11: 00000000000000000 R12: ffffffff898dd020 R13: 3ce20 R14: ffffffff81653630 R15: dffffc0000000000 FS: 0000000000f0d300( 0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffb64b3e000 CR3: 557000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 7: 0000000000000400 Seguimiento de llamadas: __debug_check_no_obj_freed lib/debugobjects.c:987 [en línea] debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1018 slab_free_hook mm/slub.c:1603 [en línea] slab_free_freelist_hook+0x171/0x240 mm/ slub.c:1653 slab_libre mm/slub.c:3213 [en línea] kfree+0xe4/0x540 mm/slub.c:4267 qdisc_create+0xbcf/0x1320 net/sched/sch_api.c:1299 tc_modify_qdisc+0x4c8/0x1a60 net/sched/sch_api.c:1663 rtnetlink_rcv_msg+0x413/0xb80 nore/rtnetlink.c: 5571 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c: 2504 netlink_unicast_kernel net/netlink/af_netlink.c: 1314 [netlin /0x7d0 net/netlink/ af_netlink.c:1340 netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/socket.c:704 [en línea] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net /zócalo .c:2403 ___sys_sendmsg+0xf3/0x170 net/socket.c:2457 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2486 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] arco/ x86/entrada/common.c:80 • https://git.kernel.org/stable/c/c71c512f4a65267e6a18163f4df729c489a51035 https://git.kernel.org/stable/c/a969a632cbe7165d448a5528806ad120c2599397 https://git.kernel.org/stable/c/44d4775ca51805b376a8db5b34f650434a08e556 https://git.kernel.org/stable/c/c951c08a5996365aecbc5f1a9bddec3905e1ddfc https://git.kernel.org/stable/c/3ec73ffeef54596c32aff0e73fe60971b9c8b866 https://git.kernel.org/stable/c/7a1c1af341041221b3acb9d7036cc2b43e0efa75 https://git.kernel.org/stable/c/a56d447f196fa9973c568f54c0d76d5391c3b0c0 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47418 – net_sched: fix NULL deref in fifo_set_limit()
https://notcve.org/view.php?id=CVE-2021-47418
In the Linux kernel, the following vulnerability has been resolved: net_sched: fix NULL deref in fifo_set_limit() syzbot reported another NULL deref in fifo_set_limit() [1] I could repro the issue with : unshare -n tc qd add dev lo root handle 1:0 tbf limit 200000 burst 70000 rate 100Mbit tc qd replace dev lo parent 1:0 pfifo_fast tc qd change dev lo root handle 1:0 tbf limit 300000 burst 70000 rate 100Mbit pfifo_fast does not have a change() operation. Make fifo_set_limit() more robust about this. [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 1cf99067 P4D 1cf99067 PUD 7ca49067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 1 PID: 14443 Comm: syz-executor959 Not tainted 5.15.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. RSP: 0018:ffffc9000e2f7310 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffffff8d6ecc00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff888024c27910 RDI: ffff888071e34000 RBP: ffff888071e34000 R08: 0000000000000001 R09: ffffffff8fcfb947 R10: 0000000000000001 R11: 0000000000000000 R12: ffff888024c27910 R13: ffff888071e34018 R14: 0000000000000000 R15: ffff88801ef74800 FS: 00007f321d897700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 00000000722c3000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: fifo_set_limit net/sched/sch_fifo.c:242 [inline] fifo_set_limit+0x198/0x210 net/sched/sch_fifo.c:227 tbf_change+0x6ec/0x16d0 net/sched/sch_tbf.c:418 qdisc_change net/sched/sch_api.c:1332 [inline] tc_modify_qdisc+0xd9a/0x1a60 net/sched/sch_api.c:1634 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5572 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340 netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net_sched: corrige el deref NULL en fifo_set_limit() syzbot informó otro deref NULL en fifo_set_limit() [1] Podría reproducir el problema con: unshare -n tc qd add dev lo root handle 1:0 tbf limit 200000 burst 70000 rate 100Mbit tc qd reemplazar dev lo parent 1:0 pfifo_fast tc qd cambiar dev lo root handle 1:0 tbf limit 300000 burst 70000 rate 100Mbit pfifo_fast no tiene una operación de cambio(). Haga que fifo_set_limit() sea más sólido al respecto. [1] BUG: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 PGD 1cf99067 P4D 1cf99067 PUD 7ca49067 PMD 0 Ups: 0010 [#1] PREEMPT SMP KASAN CPU: 1 PID: 14443 Comm: syz-executor959 No contaminado 5. 15.0-rc3- syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Código: No se puede acceder a los bytes del código de operación en RIP 0xffffffffffffffd6. RSP: 0018:ffffc9000e2f7310 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffffff8d6ecc00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: c27910 RDI: ffff888071e34000 RBP: ffff888071e34000 R08: 0000000000000001 R09: ffffffff8fcfb947 R10: 00000000000000001 R11: 0000000000000000 R12 : ffff888024c27910 R13: ffff888071e34018 R14: 00000000000000000 R15: ffff88801ef74800 FS: 00007f321d897700(0000) GS:ffff8880b9d00000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 50033 CR2: ffffffffffffffd6 CR3: 00000000722c3000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: fifo_set_limit net/sched/sch_fifo.c:242 [en línea] fifo_set_limit+0x198/0x210 net/sched/sch_fifo.c:227 6ec/0x16d0 net/sched/sch_tbf.c: 418 qdisc_change net/sched/sch_api.c:1332 [en línea] tc_modify_qdisc+0xd9a/0x1a60 net/sched/sch_api.c:1634 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5572 netlink_rcv_skb+0x153/0x42 0 red/enlace de red /af_netlink.c:2504 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [en línea] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340 netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/ socket.c:704 [en línea] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0 x1b0 neto /socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae • https://git.kernel.org/stable/c/fb0305ce1b03f6ff17f84f2c63daccecb45f2805 https://git.kernel.org/stable/c/0dd7ddc462b9c2d31eb5a9926a2cc63eaa3e9f52 https://git.kernel.org/stable/c/08d7056e8e250fd2e67dbea5be5fdecdd75bf6b4 https://git.kernel.org/stable/c/26af64d71b6277841285fa40e3f7164a378dfda9 https://git.kernel.org/stable/c/d07098f45be868a9cdce6c616563c36c64dbbd87 https://git.kernel.org/stable/c/c951a3be5e8803e93bb49a0aca0d30457d3c1b67 https://git.kernel.org/stable/c/acff2d182c0768a713cee77442caeb07668bd68f https://git.kernel.org/stable/c/fb58cd7991747b5e0b110c98c922d7b0e •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47417 – libbpf: Fix memory leak in strset
https://notcve.org/view.php?id=CVE-2021-47417
In the Linux kernel, the following vulnerability has been resolved: libbpf: Fix memory leak in strset Free struct strset itself, not just its internal parts. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: libbpf: repara la pérdida de memoria en strset Libera la estructura strset en sí, no solo sus partes internas. • https://git.kernel.org/stable/c/90d76d3ececc74bf43b2a97f178dadfa1e52be54 https://git.kernel.org/stable/c/9e8e7504e09831c469b67d6dc11d9a72654bdb8c https://git.kernel.org/stable/c/b0e875bac0fab3e7a7431c2eee36a8ccc0c712ac •