CVSS: 7.8EPSS: 0%CPEs: 25EXPL: 0CVE-2021-41073
https://notcve.org/view.php?id=CVE-2021-41073
loop_rw_iter in fs/io_uring.c in the Linux kernel 5.10 through 5.14.6 allows local users to gain privileges by using IORING_OP_PROVIDE_BUFFERS to trigger a free of a kernel buffer, as demonstrated by using /proc/<pid>/maps for exploitation. La función loop_rw_iter en fs/io_uring.c en el kernel de Linux desde la versión 5.10 hasta la versión 5.14.6 permite a los usuarios locales ganar privilegios mediante el uso de IORING_OP_PROVIDE_BUFFERS para desencadenar una liberación de un búfer del kernel, como se ha demostrado utilizando /proc//maps para su explotación • http://www.openwall.com/lists/oss-security/2021/09/18/2 http://www.openwall.com/lists/oss-security/2022/06/04/4 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=16c8d2df7ec0eed31b7d3b61cb13206a7fb930cc https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/J7KSMIOQ4377CVTHMWNGNCWHMCRFRP2T https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PAP4TXEZ7J4EZQMQW5SIJMWXG7WZT3F7 https://security.netapp.com/advisory/nta • CWE-763: Release of Invalid Pointer or Reference •
CVSS: 6.1EPSS: 0%CPEs: 46EXPL: 1CVE-2021-22947 – curl: Server responses received before STARTTLS processed after TLS handshake
https://notcve.org/view.php?id=CVE-2021-22947
When curl >= 7.20.0 and <= 7.78.0 connects to an IMAP or POP3 server to retrieve data using STARTTLS to upgrade to TLS security, the server can respond and send back multiple responses at once that curl caches. curl would then upgrade to TLS but not flush the in-queue of cached responses but instead continue using and trustingthe responses it got *before* the TLS handshake as if they were authenticated.Using this flaw, it allows a Man-In-The-Middle attacker to first inject the fake responses, then pass-through the TLS traffic from the legitimate server and trick curl into sending data back to the user thinking the attacker's injected data comes from the TLS-protected server. Cuando en curl versiones posteriores a 7.20.0 incluyéndola, y versiones anteriores a 7.78.0 incluyéndola, se conecta a un servidor IMAP o POP3 para recuperar datos usando STARTTLS para actualizar a la seguridad TLS, el servidor puede responder y enviar múltiples respuestas a la vez que curl almacena en caché. curl entonces actualizaría a TLS pero no vaciaría la cola de respuestas almacenadas en caché, sino que continuaría usando y confiando en las respuestas que obtuvo *antes* del protocolo de enlace TLS como si estuvieran autenticadas. Usando este fallo, permite a un atacante de tipo Man-In-The-Middle inyectar primero las respuestas falsas, luego pasar mediante el tráfico TLS del servidor legítimo y engañar a curl para que envíe datos de vuelta al usuario pensando que los datos inyectados por el atacante provienen del servidor protegido por TLS A flaw was found in curl. The flaw lies in how curl handles cached or pipelined responses that it receives from either a IMAP, POP3, SMTP or FTP server before the TLS upgrade using STARTTLS. In such a scenario curl even after upgrading to TLS would trust these cached responses treating them as valid and authenticated and use them. • http://seclists.org/fulldisclosure/2022/Mar/29 https://cert-portal.siemens.com/productcert/pdf/ssa-389290.pdf https://hackerone.com/reports/1334763 https://lists.debian.org/debian-lts-announce/2021/09/msg00022.html https://lists.debian.org/debian-lts-announce/2022/08/msg00017.html https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/APOAK4X73EJTAPTSVT7IRVDMUWVXNWGD https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RWLEC6YVEM2HWUBX67 • CWE-310: Cryptographic Issues CWE-319: Cleartext Transmission of Sensitive Information CWE-345: Insufficient Verification of Data Authenticity •
CVSS: 9.1EPSS: 0%CPEs: 29EXPL: 1CVE-2021-22945
https://notcve.org/view.php?id=CVE-2021-22945
When sending data to an MQTT server, libcurl <= 7.73.0 and 7.78.0 could in some circumstances erroneously keep a pointer to an already freed memory area and both use that again in a subsequent call to send data and also free it *again*. Cuando se envían datos a un servidor MQTT, libcurl versiones anteriores a 7.73.0, incluyéndola y 7.78.0, podría en algunas circunstancias, mantener erróneamente un puntero a un área de memoria ya liberada y usarlo de nuevo en una llamada posterior para enviar datos y también liberarlo *de nuevo* • http://seclists.org/fulldisclosure/2022/Mar/29 https://cert-portal.siemens.com/productcert/pdf/ssa-389290.pdf https://hackerone.com/reports/1269242 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/APOAK4X73EJTAPTSVT7IRVDMUWVXNWGD https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RWLEC6YVEM2HWUBX67SDGPSY4CQB72OE https://security.gentoo.org/glsa/202212-01 https://security.netapp.com/advisory/ntap-20211029-0003 https://support.apple.com& • CWE-415: Double Free •
CVSS: 7.5EPSS: 0%CPEs: 49EXPL: 1CVE-2021-22946 – curl: Requirement to use TLS not properly enforced for IMAP, POP3, and FTP protocols
https://notcve.org/view.php?id=CVE-2021-22946
A user can tell curl >= 7.20.0 and <= 7.78.0 to require a successful upgrade to TLS when speaking to an IMAP, POP3 or FTP server (`--ssl-reqd` on the command line or`CURLOPT_USE_SSL` set to `CURLUSESSL_CONTROL` or `CURLUSESSL_ALL` withlibcurl). This requirement could be bypassed if the server would return a properly crafted but perfectly legitimate response.This flaw would then make curl silently continue its operations **withoutTLS** contrary to the instructions and expectations, exposing possibly sensitive data in clear text over the network. Un usuario puede decirle a curl versiones posteriores a 7.20.0 incluyéndola , y versiones anteriores a 7.78.0 incluyéndola, que requiera una actualización con éxito a TLS cuando hable con un servidor IMAP, POP3 o FTP ("--ssl-reqd" en la línea de comandos o "CURLOPT_USE_SSL" configurado como "CURLUSESSL_CONTROL" o "CURLUSESSL_ALL" conlibcurl). Este requisito podría ser omitido si el servidor devolviera una respuesta correctamente diseñada pero perfectamente legítima. Este fallo haría que curl continuara silenciosamente sus operaciones **withoutTLS** en contra de las instrucciones y expectativas, exponiendo posiblemente datos confidenciales en texto sin cifrar a través de la red A flaw was found in curl. • http://seclists.org/fulldisclosure/2022/Mar/29 https://cert-portal.siemens.com/productcert/pdf/ssa-389290.pdf https://hackerone.com/reports/1334111 https://lists.debian.org/debian-lts-announce/2021/09/msg00022.html https://lists.debian.org/debian-lts-announce/2022/08/msg00017.html https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/APOAK4X73EJTAPTSVT7IRVDMUWVXNWGD https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RWLEC6YVEM2HWUBX67 • CWE-319: Cleartext Transmission of Sensitive Information CWE-325: Missing Cryptographic Step •
CVSS: 4.3EPSS: 0%CPEs: 60EXPL: 1CVE-2021-22924 – curl: Bad connection reuse due to flawed path name checks
https://notcve.org/view.php?id=CVE-2021-22924
libcurl keeps previously used connections in a connection pool for subsequenttransfers to reuse, if one of them matches the setup.Due to errors in the logic, the config matching function did not take 'issuercert' into account and it compared the involved paths *case insensitively*,which could lead to libcurl reusing wrong connections.File paths are, or can be, case sensitive on many systems but not all, and caneven vary depending on used file systems.The comparison also didn't include the 'issuer cert' which a transfer can setto qualify how to verify the server certificate. libcurl mantiene las conexiones usadas previamente en un pool de conexiones para reusarlas en posteriores transferencias, si una de ellas coincide con la configuración. Debido a errores en la lógica, la función de coincidencia de la configuración no tenía en cuenta "issuercert" y comparaba las rutas implicadas *sin tener en cuenta el caso*, que podía conllevar a que libcurl reusara conexiones erróneas. Las rutas de los archivos son, o pueden ser, casos confidenciales en muchos sistemas, pero no en todos, y pueden incluso variar dependiendo de los sistemas de archivos usados. La comparación tampoco incluía el "issuercert" que una transferencia puede ajustar para calificar cómo verificar el certificado del servidor A flaw was found in libcurl in the way libcurl handles previously used connections without accounting for 'issuer cert' and comparing the involved paths case-insensitively. This flaw allows libcurl to use the wrong connection. • https://cert-portal.siemens.com/productcert/pdf/ssa-389290.pdf https://cert-portal.siemens.com/productcert/pdf/ssa-484086.pdf https://cert-portal.siemens.com/productcert/pdf/ssa-732250.pdf https://hackerone.com/reports/1223565 https://lists.apache.org/thread.html/r61db8e7dcb56dc000a5387a88f7a473bacec5ee01b9ff3f55308aacc%40%3Cdev.kafka.apache.org%3E https://lists.apache.org/thread.html/r61db8e7dcb56dc000a5387a88f7a473bacec5ee01b9ff3f55308aacc%40%3Cusers.kafka.apache.org%3E https://lists.apache.org/thread.html/rbf4ce74b0d1fa9810dec50ba3ace0c • CWE-20: Improper Input Validation CWE-295: Improper Certificate Validation CWE-706: Use of Incorrectly-Resolved Name or Reference •