CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48706 – vdpa: ifcvf: Do proper cleanup if IFCVF init fails
https://notcve.org/view.php?id=CVE-2022-48706
In the Linux kernel, the following vulnerability has been resolved: vdpa: ifcvf: Do proper cleanup if IFCVF init fails ifcvf_mgmt_dev leaks memory if it is not freed before returning. Call is made to correct return statement so memory does not leak. ifcvf_init_hw does not take care of this so it is needed to do it here. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vdpa: ifcvf: realice una limpieza adecuada si falla el inicio de IFCVF. ifcvf_mgmt_dev pierde memoria si no se libera antes de regresar. Se realiza una llamada para corregir la declaración de devolución para que no se pierda memoria. ifcvf_init_hw no se encarga de esto, por lo que es necesario hacerlo aquí. • https://git.kernel.org/stable/c/5d2cc32c1c10bd889125d2adc16a6bc3338dcd3e https://git.kernel.org/stable/c/6b04456e248761cf68f562f2fd7c04e591fcac94 •
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 •