CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47431 – drm/amdgpu: fix gart.bo pin_count leak
https://notcve.org/view.php?id=CVE-2021-47431
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gart.bo pin_count leak gmc_v{9,10}_0_gart_disable() isn't called matched with correspoding gart_enbale function in SRIOV case. This will lead to gart.bo pin_count leak on driver unload. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: corrige la fuga de pin_count de gart.bo gmc_v{9,10}_0_gart_disable() no se llama y coincide con la función gart_enbale correspondiente en el caso SRIOV. Esto provocará una pérdida de pin_count de gart.bo al descargar el controlador. • https://git.kernel.org/stable/c/83d857d6b0967b6709cd38750c3ce2ed8ced1a95 https://git.kernel.org/stable/c/621ddffb70db824eabd63d18ac635180fe9500f9 https://git.kernel.org/stable/c/18d1c5ea3798ba42cfa0f8b2264d873463facb03 https://git.kernel.org/stable/c/66805763a97f8f7bdf742fc0851d85c02ed9411f •
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: 8EXPL: 0CVE-2021-47416 – phy: mdio: fix memory leak
https://notcve.org/view.php?id=CVE-2021-47416
In the Linux kernel, the following vulnerability has been resolved: phy: mdio: fix memory leak Syzbot reported memory leak in MDIO bus interface, the problem was in wrong state logic. MDIOBUS_ALLOCATED indicates 2 states: 1. Bus is only allocated 2. Bus allocated and __mdiobus_register() fails, but device_register() was called In case of device_register() has been called we should call put_device() to correctly free the memory allocated for this device, but mdiobus_free() calls just kfree(dev) in case of MDIOBUS_ALLOCATED state To avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED _before_ calling device_register(), because put_device() should be called even in case of device_register() failure. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: phy: mdio: arreglar pérdida de memoria. Syzbot informó una pérdida de memoria en la interfaz del bus MDIO, el problema estaba en una lógica de estado incorrecta. • https://git.kernel.org/stable/c/46abc02175b3c246dd5141d878f565a8725060c9 https://git.kernel.org/stable/c/25e9f88c7e3cc35f5e3d3db199660d28a15df639 https://git.kernel.org/stable/c/2250392d930bd0d989f24d355d6355b0150256e7 https://git.kernel.org/stable/c/f4f502a04ee1e543825af78f47eb7785015cd9f6 https://git.kernel.org/stable/c/2397b9e118721292429fea8807a698e71b94795f https://git.kernel.org/stable/c/414bb4ead1362ef2c8592db723c017258f213988 https://git.kernel.org/stable/c/0d2dd40a7be61b89a7c99dae8ee96389d27b413a https://git.kernel.org/stable/c/064c2616234a7394867c924b5c1303974 •
CVSS: 4.7EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47412 – block: don't call rq_qos_ops->done_bio if the bio isn't tracked
https://notcve.org/view.php?id=CVE-2021-47412
In the Linux kernel, the following vulnerability has been resolved: block: don't call rq_qos_ops->done_bio if the bio isn't tracked rq_qos framework is only applied on request based driver, so: 1) rq_qos_done_bio() needn't to be called for bio based driver 2) rq_qos_done_bio() needn't to be called for bio which isn't tracked, such as bios ended from error handling code. Especially in bio_endio(): 1) request queue is referred via bio->bi_bdev->bd_disk->queue, which may be gone since request queue refcount may not be held in above two cases 2) q->rq_qos may be freed in blk_cleanup_queue() when calling into __rq_qos_done_bio() Fix the potential kernel panic by not calling rq_qos_ops->done_bio if the bio isn't tracked. This way is safe because both ioc_rqos_done_bio() and blkcg_iolatency_done_bio() are nop if the bio isn't tracked. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: no llame a rq_qos_ops->done_bio si no se realiza un seguimiento de la biografía. El framework rq_qos solo se aplica en el controlador basado en solicitudes, por lo que: 1) rq_qos_done_bio() no necesita hacerlo ser llamado para un controlador basado en biografía 2) No es necesario llamar a rq_qos_done_bio() para una biografía que no está rastreada, como una biografía terminada por un código de manejo de errores. Especialmente en bio_endio(): 1) la cola de solicitudes se remite a través de bio->bi_bdev->bd_disk->queue, que puede desaparecer ya que el recuento de la cola de solicitudes no se puede mantener en los dos casos anteriores 2) q->rq_qos se puede liberar en blk_cleanup_queue() al llamar a __rq_qos_done_bio() Solucione el posible pánico del kernel al no llamar a rq_qos_ops->done_bio si no se realiza un seguimiento de la biografía. • https://git.kernel.org/stable/c/004b8f8a691205a93d9e80d98b786b2b97424d6e https://git.kernel.org/stable/c/a647a524a46736786c95cdb553a070322ca096e3 https://access.redhat.com/security/cve/CVE-2021-47412 https://bugzilla.redhat.com/show_bug.cgi?id=2282324 • CWE-388: 7PK - Errors •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47410 – drm/amdkfd: fix svm_migrate_fini warning
https://notcve.org/view.php?id=CVE-2021-47410
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix svm_migrate_fini warning Device manager releases device-specific resources when a driver disconnects from a device, devm_memunmap_pages and devm_release_mem_region calls in svm_migrate_fini are redundant. It causes below warning trace after patch "drm/amdgpu: Split amdgpu_device_fini into early and late", so remove function svm_migrate_fini. BUG: https://gitlab.freedesktop.org/drm/amd/-/issues/1718 WARNING: CPU: 1 PID: 3646 at drivers/base/devres.c:795 devm_release_action+0x51/0x60 Call Trace: ? memunmap_pages+0x360/0x360 svm_migrate_fini+0x2d/0x60 [amdgpu] kgd2kfd_device_exit+0x23/0xa0 [amdgpu] amdgpu_amdkfd_device_fini_sw+0x1d/0x30 [amdgpu] amdgpu_device_fini_sw+0x45/0x290 [amdgpu] amdgpu_driver_release_kms+0x12/0x30 [amdgpu] drm_dev_release+0x20/0x40 [drm] release_nodes+0x196/0x1e0 device_release_driver_internal+0x104/0x1d0 driver_detach+0x47/0x90 bus_remove_driver+0x7a/0xd0 pci_unregister_driver+0x3d/0x90 amdgpu_exit+0x11/0x20 [amdgpu] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdkfd: corrige la advertencia de svm_migrate_fini. El administrador de dispositivos libera recursos específicos del dispositivo cuando un controlador se desconecta de un dispositivo, las llamadas a devm_memunmap_pages y devm_release_mem_region en svm_migrate_fini son redundantes. Provoca el siguiente seguimiento de advertencia después del parche "drm/amdgpu: dividir amdgpu_device_fini en temprano y tarde", por lo tanto, elimine la función svm_migrate_fini. ERROR: https://gitlab.freedesktop.org/drm/amd/-/issues/1718 ADVERTENCIA: CPU: 1 PID: 3646 en drivers/base/devres.c:795 devm_release_action+0x51/0x60 Seguimiento de llamadas:? • https://git.kernel.org/stable/c/ac7d732b24f4061f8a732ada49b054ab38c63e15 https://git.kernel.org/stable/c/197ae17722e989942b36e33e044787877f158574 •