CVE-2024-57974 (GCVE-0-2024-57974)
Vulnerability from cvelistv5
Published
2025-02-27 02:07
Modified
2025-05-04 10:07
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: udp: Deal with race between UDP socket address change and rehash If a UDP socket changes its local address while it's receiving datagrams, as a result of connect(), there is a period during which a lookup operation might fail to find it, after the address is changed but before the secondary hash (port and address) and the four-tuple hash (local and remote ports and addresses) are updated. Secondary hash chains were introduced by commit 30fff9231fad ("udp: bind() optimisation") and, as a result, a rehash operation became needed to make a bound socket reachable again after a connect(). This operation was introduced by commit 719f835853a9 ("udp: add rehash on connect()") which isn't however a complete fix: the socket will be found once the rehashing completes, but not while it's pending. This is noticeable with a socat(1) server in UDP4-LISTEN mode, and a client sending datagrams to it. After the server receives the first datagram (cf. _xioopen_ipdgram_listen()), it issues a connect() to the address of the sender, in order to set up a directed flow. Now, if the client, running on a different CPU thread, happens to send a (subsequent) datagram while the server's socket changes its address, but is not rehashed yet, this will result in a failed lookup and a port unreachable error delivered to the client, as apparent from the following reproducer: LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4)) dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in while :; do taskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.1 || sleep 1 taskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null wait done where the client will eventually get ECONNREFUSED on a write() (typically the second or third one of a given iteration): 2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection refused This issue was first observed as a seldom failure in Podman's tests checking UDP functionality while using pasta(1) to connect the container's network namespace, which leads us to a reproducer with the lookup error resulting in an ICMP packet on a tap device: LOCAL_ADDR="$(ip -j -4 addr show|jq -rM '.[] | .addr_info[0] | select(.scope == "global").local')" while :; do ./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.2 || sleep 1 socat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null wait cmp tmp.in tmp.out done Once this fails: tmp.in tmp.out differ: char 8193, line 29 we can finally have a look at what's going on: $ tshark -r pasta.pcap 1 0.000000 :: ? ff02::16 ICMPv6 110 Multicast Listener Report Message v2 2 0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 3 0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 4 0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 5 0.168827 c6:47:05:8d:dc:04 ? Broadcast ARP 42 Who has 88.198.0.161? Tell 88.198.0.164 6 0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42 88.198.0.161 is at 9a:55:9a:55:9a:55 7 0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 8 0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable) 9 0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 10 0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 11 0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096 12 0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0 On the third datagram received, the network namespace of the container initiates an ARP lookup to deliver the ICMP message. In another variant of this reproducer, starting the client with: strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,tru ---truncated---
References
Impacted products
Vendor Product Version
Linux Linux Version: 30fff9231fad757c061285e347b33c5149c2c2e4
Version: 30fff9231fad757c061285e347b33c5149c2c2e4
Version: 30fff9231fad757c061285e347b33c5149c2c2e4
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "net/ipv4/udp.c",
            "net/ipv6/udp.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "4f8344fce91c5766d368edb0ad80142eacd805c7",
              "status": "affected",
              "version": "30fff9231fad757c061285e347b33c5149c2c2e4",
              "versionType": "git"
            },
            {
              "lessThan": "d65d3bf309b2649d27b24efd0d8784da2d81f2a6",
              "status": "affected",
              "version": "30fff9231fad757c061285e347b33c5149c2c2e4",
              "versionType": "git"
            },
            {
              "lessThan": "a502ea6fa94b1f7be72a24bcf9e3f5f6b7e6e90c",
              "status": "affected",
              "version": "30fff9231fad757c061285e347b33c5149c2c2e4",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "net/ipv4/udp.c",
            "net/ipv6/udp.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "2.6.33"
            },
            {
              "lessThan": "2.6.33",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.13",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.13.*",
              "status": "unaffected",
              "version": "6.13.2",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.14",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.13",
                  "versionStartIncluding": "2.6.33",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.13.2",
                  "versionStartIncluding": "2.6.33",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.14",
                  "versionStartIncluding": "2.6.33",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nudp: Deal with race between UDP socket address change and rehash\n\nIf a UDP socket changes its local address while it\u0027s receiving\ndatagrams, as a result of connect(), there is a period during which\na lookup operation might fail to find it, after the address is changed\nbut before the secondary hash (port and address) and the four-tuple\nhash (local and remote ports and addresses) are updated.\n\nSecondary hash chains were introduced by commit 30fff9231fad (\"udp:\nbind() optimisation\") and, as a result, a rehash operation became\nneeded to make a bound socket reachable again after a connect().\n\nThis operation was introduced by commit 719f835853a9 (\"udp: add\nrehash on connect()\") which isn\u0027t however a complete fix: the\nsocket will be found once the rehashing completes, but not while\nit\u0027s pending.\n\nThis is noticeable with a socat(1) server in UDP4-LISTEN mode, and a\nclient sending datagrams to it. After the server receives the first\ndatagram (cf. _xioopen_ipdgram_listen()), it issues a connect() to\nthe address of the sender, in order to set up a directed flow.\n\nNow, if the client, running on a different CPU thread, happens to\nsend a (subsequent) datagram while the server\u0027s socket changes its\naddress, but is not rehashed yet, this will result in a failed\nlookup and a port unreachable error delivered to the client, as\napparent from the following reproducer:\n\n  LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4))\n  dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in\n\n  while :; do\n  \ttaskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc \u0026\n  \tsleep 0.1 || sleep 1\n  \ttaskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null\n  \twait\n  done\n\nwhere the client will eventually get ECONNREFUSED on a write()\n(typically the second or third one of a given iteration):\n\n  2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection refused\n\nThis issue was first observed as a seldom failure in Podman\u0027s tests\nchecking UDP functionality while using pasta(1) to connect the\ncontainer\u0027s network namespace, which leads us to a reproducer with\nthe lookup error resulting in an ICMP packet on a tap device:\n\n  LOCAL_ADDR=\"$(ip -j -4 addr show|jq -rM \u0027.[] | .addr_info[0] | select(.scope == \"global\").local\u0027)\"\n\n  while :; do\n  \t./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc \u0026\n  \tsleep 0.2 || sleep 1\n  \tsocat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null\n  \twait\n  \tcmp tmp.in tmp.out\n  done\n\nOnce this fails:\n\n  tmp.in tmp.out differ: char 8193, line 29\n\nwe can finally have a look at what\u0027s going on:\n\n  $ tshark -r pasta.pcap\n      1   0.000000           :: ? ff02::16     ICMPv6 110 Multicast Listener Report Message v2\n      2   0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\n      3   0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\n      4   0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\n      5   0.168827 c6:47:05:8d:dc:04 ? Broadcast    ARP 42 Who has 88.198.0.161? Tell 88.198.0.164\n      6   0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42 88.198.0.161 is at 9a:55:9a:55:9a:55\n      7   0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\n      8   0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable)\n      9   0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\n     10   0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\n     11   0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096\n     12   0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0\n\nOn the third datagram received, the network namespace of the container\ninitiates an ARP lookup to deliver the ICMP message.\n\nIn another variant of this reproducer, starting the client with:\n\n  strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,tru\n---truncated---"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-05-04T10:07:29.082Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/4f8344fce91c5766d368edb0ad80142eacd805c7"
        },
        {
          "url": "https://git.kernel.org/stable/c/d65d3bf309b2649d27b24efd0d8784da2d81f2a6"
        },
        {
          "url": "https://git.kernel.org/stable/c/a502ea6fa94b1f7be72a24bcf9e3f5f6b7e6e90c"
        }
      ],
      "title": "udp: Deal with race between UDP socket address change and rehash",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-57974",
    "datePublished": "2025-02-27T02:07:02.973Z",
    "dateReserved": "2025-02-27T02:04:28.912Z",
    "dateUpdated": "2025-05-04T10:07:29.082Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-57974\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-02-27T02:15:10.590\",\"lastModified\":\"2025-02-27T02:15:10.590\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nudp: Deal with race between UDP socket address change and rehash\\n\\nIf a UDP socket changes its local address while it\u0027s receiving\\ndatagrams, as a result of connect(), there is a period during which\\na lookup operation might fail to find it, after the address is changed\\nbut before the secondary hash (port and address) and the four-tuple\\nhash (local and remote ports and addresses) are updated.\\n\\nSecondary hash chains were introduced by commit 30fff9231fad (\\\"udp:\\nbind() optimisation\\\") and, as a result, a rehash operation became\\nneeded to make a bound socket reachable again after a connect().\\n\\nThis operation was introduced by commit 719f835853a9 (\\\"udp: add\\nrehash on connect()\\\") which isn\u0027t however a complete fix: the\\nsocket will be found once the rehashing completes, but not while\\nit\u0027s pending.\\n\\nThis is noticeable with a socat(1) server in UDP4-LISTEN mode, and a\\nclient sending datagrams to it. After the server receives the first\\ndatagram (cf. _xioopen_ipdgram_listen()), it issues a connect() to\\nthe address of the sender, in order to set up a directed flow.\\n\\nNow, if the client, running on a different CPU thread, happens to\\nsend a (subsequent) datagram while the server\u0027s socket changes its\\naddress, but is not rehashed yet, this will result in a failed\\nlookup and a port unreachable error delivered to the client, as\\napparent from the following reproducer:\\n\\n  LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4))\\n  dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in\\n\\n  while :; do\\n  \\ttaskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc \u0026\\n  \\tsleep 0.1 || sleep 1\\n  \\ttaskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null\\n  \\twait\\n  done\\n\\nwhere the client will eventually get ECONNREFUSED on a write()\\n(typically the second or third one of a given iteration):\\n\\n  2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection refused\\n\\nThis issue was first observed as a seldom failure in Podman\u0027s tests\\nchecking UDP functionality while using pasta(1) to connect the\\ncontainer\u0027s network namespace, which leads us to a reproducer with\\nthe lookup error resulting in an ICMP packet on a tap device:\\n\\n  LOCAL_ADDR=\\\"$(ip -j -4 addr show|jq -rM \u0027.[] | .addr_info[0] | select(.scope == \\\"global\\\").local\u0027)\\\"\\n\\n  while :; do\\n  \\t./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc \u0026\\n  \\tsleep 0.2 || sleep 1\\n  \\tsocat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null\\n  \\twait\\n  \\tcmp tmp.in tmp.out\\n  done\\n\\nOnce this fails:\\n\\n  tmp.in tmp.out differ: char 8193, line 29\\n\\nwe can finally have a look at what\u0027s going on:\\n\\n  $ tshark -r pasta.pcap\\n      1   0.000000           :: ? ff02::16     ICMPv6 110 Multicast Listener Report Message v2\\n      2   0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\\n      3   0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\\n      4   0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\\n      5   0.168827 c6:47:05:8d:dc:04 ? Broadcast    ARP 42 Who has 88.198.0.161? Tell 88.198.0.164\\n      6   0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42 88.198.0.161 is at 9a:55:9a:55:9a:55\\n      7   0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\\n      8   0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable)\\n      9   0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\\n     10   0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\\n     11   0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096\\n     12   0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0\\n\\nOn the third datagram received, the network namespace of the container\\ninitiates an ARP lookup to deliver the ICMP message.\\n\\nIn another variant of this reproducer, starting the client with:\\n\\n  strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,tru\\n---truncated---\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: lidiar con la ejecuci\u00f3n entre el cambio de direcci\u00f3n del socket UDP y el rehash Si un socket UDP cambia su direcci\u00f3n local mientras recibe datagramas, como resultado de connect(), hay un per\u00edodo durante el cual una operaci\u00f3n de b\u00fasqueda podr\u00eda fallar en encontrarlo, despu\u00e9s de que se cambie la direcci\u00f3n pero antes de que se actualicen el hash secundario (puerto y direcci\u00f3n) y el hash de cuatro tuplas (puertos y direcciones locales y remotos). Las cadenas de hash secundarias fueron introducidas por el commit 30fff9231fad (\\\"udp: optimizaci\u00f3n de bind()\\\") y, como resultado, se necesit\u00f3 una operaci\u00f3n de rehash para hacer que un socket enlazado sea accesible nuevamente despu\u00e9s de un connect(). Esta operaci\u00f3n fue introducida por el commit 719f835853a9 (\\\"udp: agregar rehash en connect()\\\") que, sin embargo, no es una soluci\u00f3n completa: el socket se encontrar\u00e1 una vez que se complete el rehash, pero no mientras est\u00e9 pendiente. Esto se nota con un servidor socat(1) en modo UDP4-LISTEN y un cliente que le env\u00eda datagramas. Despu\u00e9s de que el servidor recibe el primer datagrama (cf. _xioopen_ipdgram_listen()), emite un connect() a la direcci\u00f3n del remitente, para establecer un flujo dirigido. Ahora, si el cliente, que se ejecuta en un subproceso de CPU diferente, env\u00eda un datagrama (posterior) mientras el socket del servidor cambia su direcci\u00f3n, pero a\u00fan no se vuelve a procesar, esto dar\u00e1 como resultado una b\u00fasqueda fallida y un error de puerto inalcanzable entregado al cliente, como se desprende del siguiente reproductor:  LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4)) dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in while :; do taskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc \u0026amp; sleep 0.1 || sleep 1 taskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null done donde el cliente eventualmente obtendr\u00e1 ECONNREFUSED en un write() (normalmente el segundo o tercero de una iteraci\u00f3n dada): 2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection denied Este problema se observ\u00f3 por primera vez como una falla poco frecuente en las pruebas de Podman que verificaban la funcionalidad de UDP mientras se usaba pasta(1) para conectar el espacio de nombres de red del contenedor, lo que nos lleva a un reproductor con el error de b\u00fasqueda que resulta en un paquete ICMP en un dispositivo tap: LOCAL_ADDR=\\\"$(ip -j -4 addr show|jq -rM \u0027.[] | .addr_info[0] | select(.scope == \\\"global\\\").local\u0027)\\\" while :; do ./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc \u0026amp; sleep 0.2 || sleep 1 socat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null wait cmp tmp.in tmp.out done Once this fails: tmp.in tmp.out differ: char 8193, line 29 we can finally have a look at what\u0027s going on: $ tshark -r pasta.pcap 1 0.000000 :: ? ff02::16 ICMPv6 110 Multicast Listener Report Message v2 2 0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 3 0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 4 0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 5 0.168827 c6:47:05:8d:dc:04 ? Broadcast ARP 42 Who has 88.198.0.161? Tell 88.198.0.164 6 0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42 88.198.0.161 is at 9a:55:9a:55:9a:55 7 0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 8 0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable) 9 0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 10 0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 11 0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096 12 0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0 On the third datagram received, the network namespace of the container initiates an ARP lookup to deliver the ICMP message. In another variant of this reproducer, starting the client with: strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp---truncada--- \"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/4f8344fce91c5766d368edb0ad80142eacd805c7\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/a502ea6fa94b1f7be72a24bcf9e3f5f6b7e6e90c\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/d65d3bf309b2649d27b24efd0d8784da2d81f2a6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.