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: 5.3EPSS: 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 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47511 – ALSA: pcm: oss: Fix negative period/buffer sizes
https://notcve.org/view.php?id=CVE-2021-47511
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix negative period/buffer sizes The period size calculation in OSS layer may receive a negative value as an error, but the code there assumes only the positive values and handle them with size_t. Due to that, a too big value may be passed to the lower layers. This patch changes the code to handle with ssize_t and adds the proper error checks appropriately. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: pcm: oss: corrige tamaños de período/búfer negativos El cálculo del tamaño del período en la capa OSS puede recibir un valor negativo como error, pero el código allí asume solo los valores positivos y manejarlos con size_t. Debido a esto, es posible que se pase un valor demasiado grande a las capas inferiores. Este parche cambia el código para manejar con ssize_t y agrega las comprobaciones de errores adecuadas. • https://git.kernel.org/stable/c/be8869d388593e57223ad39297c8e54be632f2f2 https://git.kernel.org/stable/c/502e1146873d870f87da3b8f93d6bf2de5f38d0c https://git.kernel.org/stable/c/8af815ab052eaf74addbbfb556d63ce2137c0e1b https://git.kernel.org/stable/c/f96c0959c1ee92adc911c10d6ec209af50105049 https://git.kernel.org/stable/c/f12c8a7515f641885677960af450082569a87243 https://git.kernel.org/stable/c/02b2b691b77cd7b951fa7b6c9d44d4e472cdc823 https://git.kernel.org/stable/c/00a860678098fcd9fa8db2b5fb9d2ddf4776d4cc https://git.kernel.org/stable/c/9d2479c960875ca1239bcb899f386970c •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47509 – ALSA: pcm: oss: Limit the period size to 16MB
https://notcve.org/view.php?id=CVE-2021-47509
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Limit the period size to 16MB Set the practical limit to the period size (the fragment shift in OSS) instead of a full 31bit; a too large value could lead to the exhaust of memory as we allocate temporary buffers of the period size, too. As of this patch, we set to 16MB limit, which should cover all use cases. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: pcm: oss: Limitar el tamaño del período a 16 MB Establezca el límite práctico para el tamaño del período (el desplazamiento de fragmentos en OSS) en lugar de 31 bits completos; un valor demasiado grande podría provocar el agotamiento de la memoria, ya que también asignamos búferes temporales del tamaño del período. A partir de este parche, establecimos un límite de 16 MB, que debería cubrir todos los casos de uso. • https://git.kernel.org/stable/c/d1bb703ad050de9095f10b2d3416c32921ac6bcc https://git.kernel.org/stable/c/b02a41eebcc36d4f07196780f2e165ca2c499257 https://git.kernel.org/stable/c/be55f306396cd62c6889286a7194fd8b53363aeb https://git.kernel.org/stable/c/2e54cf6794bf82a54aaefc78da13819aea9cd28a https://git.kernel.org/stable/c/76f19e4cbb548e28547f8c328aa0bfb3a10222d3 https://git.kernel.org/stable/c/ad45babf7886e7a212ee1d5eda9ef49f696db43c https://git.kernel.org/stable/c/35a3e511032146941085f87dd9fb5b82ea5c00a2 https://git.kernel.org/stable/c/8839c8c0f77ab8fc0463f4ab8b37fca3f •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47508 – btrfs: free exchange changeset on failures
https://notcve.org/view.php?id=CVE-2021-47508
In the Linux kernel, the following vulnerability has been resolved: btrfs: free exchange changeset on failures Fstests runs on my VMs have show several kmemleak reports like the following. unreferenced object 0xffff88811ae59080 (size 64): comm "xfs_io", pid 12124, jiffies 4294987392 (age 6.368s) hex dump (first 32 bytes): 00 c0 1c 00 00 00 00 00 ff cf 1c 00 00 00 00 00 ................ 90 97 e5 1a 81 88 ff ff 90 97 e5 1a 81 88 ff ff ................ backtrace: [<00000000ac0176d2>] ulist_add_merge+0x60/0x150 [btrfs] [<0000000076e9f312>] set_state_bits+0x86/0xc0 [btrfs] [<0000000014fe73d6>] set_extent_bit+0x270/0x690 [btrfs] [<000000004f675208>] set_record_extent_bits+0x19/0x20 [btrfs] [<00000000b96137b1>] qgroup_reserve_data+0x274/0x310 [btrfs] [<0000000057e9dcbb>] btrfs_check_data_free_space+0x5c/0xa0 [btrfs] [<0000000019c4511d>] btrfs_delalloc_reserve_space+0x1b/0xa0 [btrfs] [<000000006d37e007>] btrfs_dio_iomap_begin+0x415/0x970 [btrfs] [<00000000fb8a74b8>] iomap_iter+0x161/0x1e0 [<0000000071dff6ff>] __iomap_dio_rw+0x1df/0x700 [<000000002567ba53>] iomap_dio_rw+0x5/0x20 [<0000000072e555f8>] btrfs_file_write_iter+0x290/0x530 [btrfs] [<000000005eb3d845>] new_sync_write+0x106/0x180 [<000000003fb505bf>] vfs_write+0x24d/0x2f0 [<000000009bb57d37>] __x64_sys_pwrite64+0x69/0xa0 [<000000003eba3fdf>] do_syscall_64+0x43/0x90 In case brtfs_qgroup_reserve_data() or btrfs_delalloc_reserve_metadata() fail the allocated extent_changeset will not be freed. So in btrfs_check_data_free_space() and btrfs_delalloc_reserve_space() free the allocated extent_changeset to get rid of the allocated memory. The issue currently only happens in the direct IO write path, but only after 65b3c08606e5 ("btrfs: fix ENOSPC failure when attempting direct IO write into NOCOW range"), and also at defrag_one_locked_target(). Every other place is always calling extent_changeset_free() even if its call to btrfs_delalloc_reserve_space() or btrfs_check_data_free_space() has failed. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: conjunto de cambios de intercambio gratuito en caso de fallas. Las ejecuciones de Fstests en mis VM han mostrado varios informes de kmemleak como el siguiente. objeto sin referencia 0xffff88811ae59080 (tamaño 64): comm "xfs_io", pid 12124, jiffies 4294987392 (edad 6,368 s) volcado hexadecimal (primeros 32 bytes): 00 c0 1c 00 00 00 00 00 ff cf 1c 00 00 00 00... ............. 90 97 e5 1a 81 88 ff ff 90 97 e5 1a 81 88 ff ff ................ retroceso: [<00000000ac0176d2 >] ulist_add_merge+0x60/0x150 [btrfs] [<0000000076e9f312>] set_state_bits+0x86/0xc0 [btrfs] [<0000000014fe73d6>] set_extent_bit+0x270/0x690 [btrfs] [<000000004f 675208>] set_record_extent_bits+0x19/0x20 [btrfs] [ <00000000b96137b1>] qgroup_reserve_data+0x274/0x310 [btrfs] [<0000000057e9dcbb>] btrfs_check_data_free_space+0x5c/0xa0 [btrfs] [<0000000019c4511d>] +0x1b/0xa0 [btrfs] [<000000006d37e007>] btrfs_dio_iomap_begin+0x415/0x970 [btrfs ] [<00000000fb8a74b8>] iomap_iter+0x161/0x1e0 [<0000000071dff6ff>] __iomap_dio_rw+0x1df/0x700 [<000000002567ba53>] iomap_dio_rw+0x5/0x20 [<000000 0072e555f8>] btrfs_file_write_iter+0x290/0x530 [btrfs] [<000000005eb3d845>] new_sync_write +0x106/0x180 [<000000003fb505bf>] vfs_write+0x24d/0x2f0 [<000000009bb57d37>] __x64_sys_pwrite64+0x69/0xa0 [<000000003eba3fdf>] 3/0x90 En caso de que brtfs_qgroup_reserve_data() o btrfs_delalloc_reserve_metadata() fallen, el conjunto de cambios asignado no será liberado. Entonces, en btrfs_check_data_free_space() y btrfs_delalloc_reserve_space() libera el extend_changeset asignado para deshacerte de la memoria asignada. • https://git.kernel.org/stable/c/ca06c5cb1b6dbfe67655b33c02fc394d65824519 https://git.kernel.org/stable/c/da5e817d9d75422eaaa05490d0b9a5e328fc1a51 •