CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47521 – can: sja1000: fix use after free in ems_pcmcia_add_card()
https://notcve.org/view.php?id=CVE-2021-47521
In the Linux kernel, the following vulnerability has been resolved: can: sja1000: fix use after free in ems_pcmcia_add_card() If the last channel is not available then "dev" is freed. Fortunately, we can just use "pdev->irq" instead. Also we should check if at least one channel was set up. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: sja1000: arreglar el use after free en ems_pcmcia_add_card() Si el último canal no está disponible entonces se libera "dev". Afortunadamente, podemos usar "pdev->irq" en su lugar. También debemos comprobar si se configuró al menos un canal. • https://git.kernel.org/stable/c/fd734c6f25aea4b2b44b045e489aec67b388577e https://git.kernel.org/stable/c/cbd86110546f7f730a1f5d7de56c944a336c15c4 https://git.kernel.org/stable/c/1dd5b819f7e406dc15bbc7670596ff25261aaa2a https://git.kernel.org/stable/c/c8718026ba287168ff9ad0ccc4f9a413062cba36 https://git.kernel.org/stable/c/ccf070183e4655824936c0f96c4a2bcca93419aa https://git.kernel.org/stable/c/1a295fea90e1acbe80c6d4940f5ff856edcd6bec https://git.kernel.org/stable/c/923f4dc5df679f678e121c20bf2fd70f7bf3e288 https://git.kernel.org/stable/c/474f9a8534f5f89841240a7e978bafd6e • CWE-416: Use After Free •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47520 – can: pch_can: pch_can_rx_normal: fix use after free
https://notcve.org/view.php?id=CVE-2021-47520
In the Linux kernel, the following vulnerability has been resolved: can: pch_can: pch_can_rx_normal: fix use after free After calling netif_receive_skb(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is dereferenced just after the call netif_receive_skb(skb). Reordering the lines solves the issue. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: pch_can: pch_can_rx_normal: corregir el use after free después de llamar a netif_receive_skb(skb), desreferenciar skb no es seguro. Especialmente, el can_frame cf que alias la memoria skb se desreferencia justo después de la llamada netif_receive_skb(skb). Reordenar las líneas resuelve el problema. • https://git.kernel.org/stable/c/b21d18b51b31a24d17f883b678432fbdee3d5675 https://git.kernel.org/stable/c/bafe343a885c70dddf358379cf0b2a1c07355d8d https://git.kernel.org/stable/c/3a3c46e2eff0577454860a203be1a8295f4acb76 https://git.kernel.org/stable/c/affbad02bf80380a7403885b9fe4a1587d1bb4f3 https://git.kernel.org/stable/c/3e193ef4e0a3f5bf92ede83ef214cb09d01b00aa https://git.kernel.org/stable/c/abb4eff3dcd2e583060082a18a8dbf31f02689d4 https://git.kernel.org/stable/c/703dde112021c93d6e89443c070e7dbd4dea612e https://git.kernel.org/stable/c/6c73fc931658d8cbc8a1714b326cb31eb • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47518 – nfc: fix potential NULL pointer deref in nfc_genl_dump_ses_done
https://notcve.org/view.php?id=CVE-2021-47518
In the Linux kernel, the following vulnerability has been resolved: nfc: fix potential NULL pointer deref in nfc_genl_dump_ses_done The done() netlink callback nfc_genl_dump_ses_done() should check if received argument is non-NULL, because its allocation could fail earlier in dumpit() (nfc_genl_dump_ses()). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nfc: corrige la posible deref del puntero NULL en nfc_genl_dump_ses_done La devolución de llamada de netlink done() nfc_genl_dump_ses_done() debe verificar si el argumento recibido no es NULL, porque su asignación podría fallar antes en dumpit() (nfc_genl_dump_ses()). • https://git.kernel.org/stable/c/ac22ac466a659f1b2e02a2e2ee23fc5c42da2c95 https://git.kernel.org/stable/c/87cdb8789c38e44ae5454aafe277997c950d00ed https://git.kernel.org/stable/c/69bb79a8f5bb9f436b6f1434ca9742591b7bbe18 https://git.kernel.org/stable/c/811a7576747760bcaf60502f096d1e6e91d566fa https://git.kernel.org/stable/c/3b861a40325eac9c4c13b6c53874ad90617e944d https://git.kernel.org/stable/c/48fcd08fdbe05e35b650a252ec2a2d96057a1c7a https://git.kernel.org/stable/c/83ea620a1be840bf05089a5061fb8323ca42f38c https://git.kernel.org/stable/c/fae9705d281091254d4a81fa2da9d2234 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47516 – nfp: Fix memory leak in nfp_cpp_area_cache_add()
https://notcve.org/view.php?id=CVE-2021-47516
In the Linux kernel, the following vulnerability has been resolved: nfp: Fix memory leak in nfp_cpp_area_cache_add() In line 800 (#1), nfp_cpp_area_alloc() allocates and initializes a CPP area structure. But in line 807 (#2), when the cache is allocated failed, this CPP area structure is not freed, which will result in memory leak. We can fix it by freeing the CPP area when the cache is allocated failed (#2). 792 int nfp_cpp_area_cache_add(struct nfp_cpp *cpp, size_t size) 793 { 794 struct nfp_cpp_area_cache *cache; 795 struct nfp_cpp_area *area; 800 area = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0), 801 0, size); // #1: allocates and initializes 802 if (!area) 803 return -ENOMEM; 805 cache = kzalloc(sizeof(*cache), GFP_KERNEL); 806 if (!cache) 807 return -ENOMEM; // #2: missing free 817 return 0; 818 } En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nfp: corrige la pérdida de memoria en nfp_cpp_area_cache_add() En la línea 800 (#1), nfp_cpp_area_alloc() asigna e inicializa una estructura de área CPP. Pero en la línea 807 (#2), cuando falla la asignación de caché, esta estructura de área CPP no se libera, lo que resultará en una pérdida de memoria. • https://git.kernel.org/stable/c/4cb584e0ee7df70fd0376aee60cf701855ea8c81 https://git.kernel.org/stable/c/3e93abcdcec0436fbf0b6a88ae806902426895a2 https://git.kernel.org/stable/c/eb51f639ef3fd5498b7def290ed8681b6aadd9a7 https://git.kernel.org/stable/c/2e0e072e62fdaf7816220af08e05c020f0fcb77a https://git.kernel.org/stable/c/484069b5de9d223cc1c64c6f80389a99cfef51f1 https://git.kernel.org/stable/c/f707820c09239d6f67699d9b2ff57863cc7905b0 https://git.kernel.org/stable/c/c56c96303e9289cc34716b1179597b6f470833de • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47515 – seg6: fix the iif in the IPv6 socket control block
https://notcve.org/view.php?id=CVE-2021-47515
In the Linux kernel, the following vulnerability has been resolved: seg6: fix the iif in the IPv6 socket control block When an IPv4 packet is received, the ip_rcv_core(...) sets the receiving interface index into the IPv4 socket control block (v5.16-rc4, net/ipv4/ip_input.c line 510): IPCB(skb)->iif = skb->skb_iif; If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH header, the seg6_do_srh_encap(...) performs the required encapsulation. In this case, the seg6_do_srh_encap function clears the IPv6 socket control block (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163): memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); The memset(...) was introduced in commit ef489749aae5 ("ipv6: sr: clear IP6CB(skb) on SRH ip4ip6 encapsulation") a long time ago (2019-01-29). Since the IPv6 socket control block and the IPv4 socket control block share the same memory area (skb->cb), the receiving interface index info is lost (IP6CB(skb)->iif is set to zero). As a side effect, that condition triggers a NULL pointer dereference if commit 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig netdev") is applied. To fix that issue, we set the IP6CB(skb)->iif with the index of the receiving interface once again. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: seg6: corrige el iif en el bloque de control del socket IPv6 Cuando se recibe un paquete IPv4, ip_rcv_core(...) establece el índice de la interfaz de recepción en el bloque de control del socket IPv4 (v5 .16-rc4, net/ipv4/ip_input.c línea 510): IPCB(skb)->iif = skb->skb_iif; Si ese paquete IPv4 debe encapsularse en un encabezado IPv6+SRH externo, seg6_do_srh_encap(...) realiza la encapsulación requerida. En este caso, la función seg6_do_srh_encap borra el bloque de control del socket IPv6 (v5.16-rc4 net/ipv6/seg6_iptunnel.c línea 163): memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); El memset(...) se introdujo en El commit ef489749aae5 ("ipv6: sr: clear IP6CB(skb) en la encapsulación SRH ip4ip6") hace mucho tiempo (29 de enero de 2019). Dado que el bloque de control del socket IPv6 y el bloque de control del socket IPv4 comparten la misma área de memoria (skb->cb), la información del índice de la interfaz de recepción se pierde (IP6CB(skb)->iif se establece en cero). Como efecto secundario, esa condición desencadena una desreferencia del puntero NULL si se aplica el commit 0857d6f8c759 ("ipv6: al reenviar estadísticas de recuento de rx en el netdev original"). • https://git.kernel.org/stable/c/c630ec8bdadae9d557b1ceb9d6c06e149108a0d4 https://git.kernel.org/stable/c/2f704348c93ff8119e642dae6a72327f90b82810 https://git.kernel.org/stable/c/ef489749aae508e6f17886775c075f12ff919fb1 https://git.kernel.org/stable/c/b71b7e0280f47b4ac633fbfd153423814ea87810 https://git.kernel.org/stable/c/b16d412e5f79734033df04e97d7ea2f50a8e9fe3 https://git.kernel.org/stable/c/6431e71093f3da586a00c6d931481ffb0dc2db0e https://git.kernel.org/stable/c/ef8804e47c0a44ae106ead1740408af5ea6c6ee9 https://git.kernel.org/stable/c/666521b3852d2b2f52d570f9122b1e4b5 •