CVE-2024-42239 (GCVE-0-2024-42239)

Vulnerability from cvelistv5 – Published: 2024-08-07 15:14 – Updated: 2026-05-11 20:28
VLAI
Title
bpf: Fail bpf_timer_cancel when callback is being cancelled
Summary
In the Linux kernel, the following vulnerability has been resolved: bpf: Fail bpf_timer_cancel when callback is being cancelled Given a schedule: timer1 cb timer2 cb bpf_timer_cancel(timer2); bpf_timer_cancel(timer1); Both bpf_timer_cancel calls would wait for the other callback to finish executing, introducing a lockup. Add an atomic_t count named 'cancelling' in bpf_hrtimer. This keeps track of all in-flight cancellation requests for a given BPF timer. Whenever cancelling a BPF timer, we must check if we have outstanding cancellation requests, and if so, we must fail the operation with an error (-EDEADLK) since cancellation is synchronous and waits for the callback to finish executing. This implies that we can enter a deadlock situation involving two or more timer callbacks executing in parallel and attempting to cancel one another. Note that we avoid incrementing the cancelling counter for the target timer (the one being cancelled) if bpf_timer_cancel is not invoked from a callback, to avoid spurious errors. The whole point of detecting cur->cancelling and returning -EDEADLK is to not enter a busy wait loop (which may or may not lead to a lockup). This does not apply in case the caller is in a non-callback context, the other side can continue to cancel as it sees fit without running into errors. Background on prior attempts: Earlier versions of this patch used a bool 'cancelling' bit and used the following pattern under timer->lock to publish cancellation status. lock(t->lock); t->cancelling = true; mb(); if (cur->cancelling) return -EDEADLK; unlock(t->lock); hrtimer_cancel(t->timer); t->cancelling = false; The store outside the critical section could overwrite a parallel requests t->cancelling assignment to true, to ensure the parallely executing callback observes its cancellation status. It would be necessary to clear this cancelling bit once hrtimer_cancel is done, but lack of serialization introduced races. Another option was explored where bpf_timer_start would clear the bit when (re)starting the timer under timer->lock. This would ensure serialized access to the cancelling bit, but may allow it to be cleared before in-flight hrtimer_cancel has finished executing, such that lockups can occur again. Thus, we choose an atomic counter to keep track of all outstanding cancellation requests and use it to prevent lockups in case callbacks attempt to cancel each other while executing in parallel.
Severity
No CVSS data available.
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator (v2.0.3)
Assigner
References
Impacted products
Vendor Product Version
Linux Linux Affected: b00628b1c7d595ae5b544e059c27b1f5828314b4 , < 9369830518688ecd5b08ffc08ab3302ce2b5d0f7 (git)
Affected: b00628b1c7d595ae5b544e059c27b1f5828314b4 , < 3e4e8178a8666c56813bd167b848fca0f4c9af0a (git)
Affected: b00628b1c7d595ae5b544e059c27b1f5828314b4 , < d4523831f07a267a943f0dde844bf8ead7495f13 (git)
Create a notification for this product.
Linux Linux Affected: 5.15
Unaffected: 0 , < 5.15 (semver)
Unaffected: 6.6.41 , ≤ 6.6.* (semver)
Unaffected: 6.9.10 , ≤ 6.9.* (semver)
Unaffected: 6.10 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-42239",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-10T16:13:54.505425Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-09-11T17:34:31.803Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/helpers.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "9369830518688ecd5b08ffc08ab3302ce2b5d0f7",
              "status": "affected",
              "version": "b00628b1c7d595ae5b544e059c27b1f5828314b4",
              "versionType": "git"
            },
            {
              "lessThan": "3e4e8178a8666c56813bd167b848fca0f4c9af0a",
              "status": "affected",
              "version": "b00628b1c7d595ae5b544e059c27b1f5828314b4",
              "versionType": "git"
            },
            {
              "lessThan": "d4523831f07a267a943f0dde844bf8ead7495f13",
              "status": "affected",
              "version": "b00628b1c7d595ae5b544e059c27b1f5828314b4",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/helpers.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.15"
            },
            {
              "lessThan": "5.15",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.41",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.9.*",
              "status": "unaffected",
              "version": "6.9.10",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.10",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.41",
                  "versionStartIncluding": "5.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.9.10",
                  "versionStartIncluding": "5.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.10",
                  "versionStartIncluding": "5.15",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fail bpf_timer_cancel when callback is being cancelled\n\nGiven a schedule:\n\ntimer1 cb\t\t\ttimer2 cb\n\nbpf_timer_cancel(timer2);\tbpf_timer_cancel(timer1);\n\nBoth bpf_timer_cancel calls would wait for the other callback to finish\nexecuting, introducing a lockup.\n\nAdd an atomic_t count named \u0027cancelling\u0027 in bpf_hrtimer. This keeps\ntrack of all in-flight cancellation requests for a given BPF timer.\nWhenever cancelling a BPF timer, we must check if we have outstanding\ncancellation requests, and if so, we must fail the operation with an\nerror (-EDEADLK) since cancellation is synchronous and waits for the\ncallback to finish executing. This implies that we can enter a deadlock\nsituation involving two or more timer callbacks executing in parallel\nand attempting to cancel one another.\n\nNote that we avoid incrementing the cancelling counter for the target\ntimer (the one being cancelled) if bpf_timer_cancel is not invoked from\na callback, to avoid spurious errors. The whole point of detecting\ncur-\u003ecancelling and returning -EDEADLK is to not enter a busy wait loop\n(which may or may not lead to a lockup). This does not apply in case the\ncaller is in a non-callback context, the other side can continue to\ncancel as it sees fit without running into errors.\n\nBackground on prior attempts:\n\nEarlier versions of this patch used a bool \u0027cancelling\u0027 bit and used the\nfollowing pattern under timer-\u003elock to publish cancellation status.\n\nlock(t-\u003elock);\nt-\u003ecancelling = true;\nmb();\nif (cur-\u003ecancelling)\n\treturn -EDEADLK;\nunlock(t-\u003elock);\nhrtimer_cancel(t-\u003etimer);\nt-\u003ecancelling = false;\n\nThe store outside the critical section could overwrite a parallel\nrequests t-\u003ecancelling assignment to true, to ensure the parallely\nexecuting callback observes its cancellation status.\n\nIt would be necessary to clear this cancelling bit once hrtimer_cancel\nis done, but lack of serialization introduced races. Another option was\nexplored where bpf_timer_start would clear the bit when (re)starting the\ntimer under timer-\u003elock. This would ensure serialized access to the\ncancelling bit, but may allow it to be cleared before in-flight\nhrtimer_cancel has finished executing, such that lockups can occur\nagain.\n\nThus, we choose an atomic counter to keep track of all outstanding\ncancellation requests and use it to prevent lockups in case callbacks\nattempt to cancel each other while executing in parallel."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T20:28:29.824Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/9369830518688ecd5b08ffc08ab3302ce2b5d0f7"
        },
        {
          "url": "https://git.kernel.org/stable/c/3e4e8178a8666c56813bd167b848fca0f4c9af0a"
        },
        {
          "url": "https://git.kernel.org/stable/c/d4523831f07a267a943f0dde844bf8ead7495f13"
        }
      ],
      "title": "bpf: Fail bpf_timer_cancel when callback is being cancelled",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-42239",
    "datePublished": "2024-08-07T15:14:27.382Z",
    "dateReserved": "2024-07-30T07:40:12.253Z",
    "dateUpdated": "2026-05-11T20:28:29.824Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2024-42239",
      "date": "2026-06-23",
      "epss": "0.00166",
      "percentile": "0.06064"
    },
    "fkie_nvd": {
      "configurations": "[{\"nodes\": [{\"operator\": \"OR\", \"negate\": false, \"cpeMatch\": [{\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"5.15\", \"versionEndExcluding\": \"6.6.41\", \"matchCriteriaId\": \"DA87C02E-A4BF-4FD7-AE47-A2AB23061A91\"}, {\"vulnerable\": true, \"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"versionStartIncluding\": \"6.7\", \"versionEndExcluding\": \"6.9.10\", \"matchCriteriaId\": \"AB2E8DEC-CFD5-4C2B-981D-E7E45A36C352\"}]}]}]",
      "descriptions": "[{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbpf: Fail bpf_timer_cancel when callback is being cancelled\\n\\nGiven a schedule:\\n\\ntimer1 cb\\t\\t\\ttimer2 cb\\n\\nbpf_timer_cancel(timer2);\\tbpf_timer_cancel(timer1);\\n\\nBoth bpf_timer_cancel calls would wait for the other callback to finish\\nexecuting, introducing a lockup.\\n\\nAdd an atomic_t count named \u0027cancelling\u0027 in bpf_hrtimer. This keeps\\ntrack of all in-flight cancellation requests for a given BPF timer.\\nWhenever cancelling a BPF timer, we must check if we have outstanding\\ncancellation requests, and if so, we must fail the operation with an\\nerror (-EDEADLK) since cancellation is synchronous and waits for the\\ncallback to finish executing. This implies that we can enter a deadlock\\nsituation involving two or more timer callbacks executing in parallel\\nand attempting to cancel one another.\\n\\nNote that we avoid incrementing the cancelling counter for the target\\ntimer (the one being cancelled) if bpf_timer_cancel is not invoked from\\na callback, to avoid spurious errors. The whole point of detecting\\ncur-\u003ecancelling and returning -EDEADLK is to not enter a busy wait loop\\n(which may or may not lead to a lockup). This does not apply in case the\\ncaller is in a non-callback context, the other side can continue to\\ncancel as it sees fit without running into errors.\\n\\nBackground on prior attempts:\\n\\nEarlier versions of this patch used a bool \u0027cancelling\u0027 bit and used the\\nfollowing pattern under timer-\u003elock to publish cancellation status.\\n\\nlock(t-\u003elock);\\nt-\u003ecancelling = true;\\nmb();\\nif (cur-\u003ecancelling)\\n\\treturn -EDEADLK;\\nunlock(t-\u003elock);\\nhrtimer_cancel(t-\u003etimer);\\nt-\u003ecancelling = false;\\n\\nThe store outside the critical section could overwrite a parallel\\nrequests t-\u003ecancelling assignment to true, to ensure the parallely\\nexecuting callback observes its cancellation status.\\n\\nIt would be necessary to clear this cancelling bit once hrtimer_cancel\\nis done, but lack of serialization introduced races. Another option was\\nexplored where bpf_timer_start would clear the bit when (re)starting the\\ntimer under timer-\u003elock. This would ensure serialized access to the\\ncancelling bit, but may allow it to be cleared before in-flight\\nhrtimer_cancel has finished executing, such that lockups can occur\\nagain.\\n\\nThus, we choose an atomic counter to keep track of all outstanding\\ncancellation requests and use it to prevent lockups in case callbacks\\nattempt to cancel each other while executing in parallel.\"}, {\"lang\": \"es\", \"value\": \"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: falla bpf_timer_cancel cuando se cancela la devoluci\\u00f3n de llamada. Dada una programaci\\u00f3n: timer1 cb timer2 cb bpf_timer_cancel(timer2); bpf_timer_cancel(timer1); Ambas llamadas a bpf_timer_cancel esperar\\u00edan a que la otra devoluci\\u00f3n de llamada termine de ejecutarse, introduciendo un bloqueo. Agregue un recuento atomic_t llamado \u0027cancelaci\\u00f3n\u0027 en bpf_hrtimer. Esto realiza un seguimiento de todas las solicitudes de cancelaci\\u00f3n en vuelo para un temporizador BPF determinado. Siempre que cancelemos un temporizador BPF, debemos verificar si tenemos solicitudes de cancelaci\\u00f3n pendientes y, de ser as\\u00ed, debemos fallar la operaci\\u00f3n con un error (-EDEADLK) ya que la cancelaci\\u00f3n es sincr\\u00f3nica y espera a que termine de ejecutarse la devoluci\\u00f3n de llamada. Esto implica que podemos entrar en una situaci\\u00f3n de punto muerto que involucre dos o m\\u00e1s devoluciones de llamada de temporizador ejecut\\u00e1ndose en paralelo e intentando cancelarse entre s\\u00ed. Tenga en cuenta que evitamos incrementar el contador de cancelaci\\u00f3n para el temporizador de destino (el que se cancela) si no se invoca bpf_timer_cancel desde una devoluci\\u00f3n de llamada, para evitar errores falsos. El objetivo de detectar cur-\u0026gt;cancelar y devolver -EDEADLK es no ingresar a un ciclo de espera ocupado (que puede o no conducir a un bloqueo). Esto no se aplica en caso de que la persona que llama se encuentre en un contexto sin devoluci\\u00f3n de llamada; la otra parte puede continuar cancelando como mejor le parezca sin cometer errores. Antecedentes de intentos anteriores: Las versiones anteriores de este parche usaban un bit bool de \u0027cancelaci\\u00f3n\u0027 y usaban el siguiente patr\\u00f3n en temporizador-\u0026gt;bloqueo para publicar el estado de cancelaci\\u00f3n.  lock(t-\u0026gt;lock); t-\u0026gt;cancelling = true; mb(); if (cur-\u0026gt;cancelling) return -EDEADLK; unlock(t-\u0026gt;lock); hrtimer_cancel(t-\u0026gt;timer); t-\u0026gt;cancelling = false; El almac\\u00e9n fuera de la secci\\u00f3n cr\\u00edtica podr\\u00eda sobrescribir una asignaci\\u00f3n de cancelaci\\u00f3n t-\u0026gt;de solicitudes paralelas a verdadero, para garantizar que la devoluci\\u00f3n de llamada que se ejecuta en paralelo observe su estado de cancelaci\\u00f3n. Ser\\u00eda necesario borrar este bit de cancelaci\\u00f3n una vez que se complete hrtimer_cancel, pero la falta de serializaci\\u00f3n introdujo ejecuciones. Se explor\\u00f3 otra opci\\u00f3n donde bpf_timer_start borrar\\u00eda el bit al (re)iniciar el temporizador bajo temporizador-\u0026gt;bloqueo. Esto garantizar\\u00eda el acceso serializado al bit de cancelaci\\u00f3n, pero puede permitir que se borre antes de que hrtimer_cancel en vuelo haya terminado de ejecutarse, de modo que los bloqueos puedan ocurrir nuevamente. Por lo tanto, elegimos un contador at\\u00f3mico para realizar un seguimiento de todas las solicitudes de cancelaci\\u00f3n pendientes y lo utilizamos para evitar bloqueos en caso de que las devoluciones de llamada intenten cancelarse entre s\\u00ed mientras se ejecutan en paralelo.\"}]",
      "id": "CVE-2024-42239",
      "lastModified": "2024-08-08T14:54:08.330",
      "metrics": "{\"cvssMetricV31\": [{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"cvssData\": {\"version\": \"3.1\", \"vectorString\": \"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\", \"baseScore\": 5.5, \"baseSeverity\": \"MEDIUM\", \"attackVector\": \"LOCAL\", \"attackComplexity\": \"LOW\", \"privilegesRequired\": \"LOW\", \"userInteraction\": \"NONE\", \"scope\": \"UNCHANGED\", \"confidentialityImpact\": \"NONE\", \"integrityImpact\": \"NONE\", \"availabilityImpact\": \"HIGH\"}, \"exploitabilityScore\": 1.8, \"impactScore\": 3.6}]}",
      "published": "2024-08-07T16:15:46.733",
      "references": "[{\"url\": \"https://git.kernel.org/stable/c/3e4e8178a8666c56813bd167b848fca0f4c9af0a\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/9369830518688ecd5b08ffc08ab3302ce2b5d0f7\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}, {\"url\": \"https://git.kernel.org/stable/c/d4523831f07a267a943f0dde844bf8ead7495f13\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"tags\": [\"Patch\"]}]",
      "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "vulnStatus": "Analyzed",
      "weaknesses": "[{\"source\": \"nvd@nist.gov\", \"type\": \"Primary\", \"description\": [{\"lang\": \"en\", \"value\": \"CWE-667\"}]}]"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-42239\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-08-07T16:15:46.733\",\"lastModified\":\"2024-08-08T14:54:08.330\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbpf: Fail bpf_timer_cancel when callback is being cancelled\\n\\nGiven a schedule:\\n\\ntimer1 cb\\t\\t\\ttimer2 cb\\n\\nbpf_timer_cancel(timer2);\\tbpf_timer_cancel(timer1);\\n\\nBoth bpf_timer_cancel calls would wait for the other callback to finish\\nexecuting, introducing a lockup.\\n\\nAdd an atomic_t count named \u0027cancelling\u0027 in bpf_hrtimer. This keeps\\ntrack of all in-flight cancellation requests for a given BPF timer.\\nWhenever cancelling a BPF timer, we must check if we have outstanding\\ncancellation requests, and if so, we must fail the operation with an\\nerror (-EDEADLK) since cancellation is synchronous and waits for the\\ncallback to finish executing. This implies that we can enter a deadlock\\nsituation involving two or more timer callbacks executing in parallel\\nand attempting to cancel one another.\\n\\nNote that we avoid incrementing the cancelling counter for the target\\ntimer (the one being cancelled) if bpf_timer_cancel is not invoked from\\na callback, to avoid spurious errors. The whole point of detecting\\ncur-\u003ecancelling and returning -EDEADLK is to not enter a busy wait loop\\n(which may or may not lead to a lockup). This does not apply in case the\\ncaller is in a non-callback context, the other side can continue to\\ncancel as it sees fit without running into errors.\\n\\nBackground on prior attempts:\\n\\nEarlier versions of this patch used a bool \u0027cancelling\u0027 bit and used the\\nfollowing pattern under timer-\u003elock to publish cancellation status.\\n\\nlock(t-\u003elock);\\nt-\u003ecancelling = true;\\nmb();\\nif (cur-\u003ecancelling)\\n\\treturn -EDEADLK;\\nunlock(t-\u003elock);\\nhrtimer_cancel(t-\u003etimer);\\nt-\u003ecancelling = false;\\n\\nThe store outside the critical section could overwrite a parallel\\nrequests t-\u003ecancelling assignment to true, to ensure the parallely\\nexecuting callback observes its cancellation status.\\n\\nIt would be necessary to clear this cancelling bit once hrtimer_cancel\\nis done, but lack of serialization introduced races. Another option was\\nexplored where bpf_timer_start would clear the bit when (re)starting the\\ntimer under timer-\u003elock. This would ensure serialized access to the\\ncancelling bit, but may allow it to be cleared before in-flight\\nhrtimer_cancel has finished executing, such that lockups can occur\\nagain.\\n\\nThus, we choose an atomic counter to keep track of all outstanding\\ncancellation requests and use it to prevent lockups in case callbacks\\nattempt to cancel each other while executing in parallel.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: falla bpf_timer_cancel cuando se cancela la devoluci\u00f3n de llamada. Dada una programaci\u00f3n: timer1 cb timer2 cb bpf_timer_cancel(timer2); bpf_timer_cancel(timer1); Ambas llamadas a bpf_timer_cancel esperar\u00edan a que la otra devoluci\u00f3n de llamada termine de ejecutarse, introduciendo un bloqueo. Agregue un recuento atomic_t llamado \u0027cancelaci\u00f3n\u0027 en bpf_hrtimer. Esto realiza un seguimiento de todas las solicitudes de cancelaci\u00f3n en vuelo para un temporizador BPF determinado. Siempre que cancelemos un temporizador BPF, debemos verificar si tenemos solicitudes de cancelaci\u00f3n pendientes y, de ser as\u00ed, debemos fallar la operaci\u00f3n con un error (-EDEADLK) ya que la cancelaci\u00f3n es sincr\u00f3nica y espera a que termine de ejecutarse la devoluci\u00f3n de llamada. Esto implica que podemos entrar en una situaci\u00f3n de punto muerto que involucre dos o m\u00e1s devoluciones de llamada de temporizador ejecut\u00e1ndose en paralelo e intentando cancelarse entre s\u00ed. Tenga en cuenta que evitamos incrementar el contador de cancelaci\u00f3n para el temporizador de destino (el que se cancela) si no se invoca bpf_timer_cancel desde una devoluci\u00f3n de llamada, para evitar errores falsos. El objetivo de detectar cur-\u0026gt;cancelar y devolver -EDEADLK es no ingresar a un ciclo de espera ocupado (que puede o no conducir a un bloqueo). Esto no se aplica en caso de que la persona que llama se encuentre en un contexto sin devoluci\u00f3n de llamada; la otra parte puede continuar cancelando como mejor le parezca sin cometer errores. Antecedentes de intentos anteriores: Las versiones anteriores de este parche usaban un bit bool de \u0027cancelaci\u00f3n\u0027 y usaban el siguiente patr\u00f3n en temporizador-\u0026gt;bloqueo para publicar el estado de cancelaci\u00f3n.  lock(t-\u0026gt;lock); t-\u0026gt;cancelling = true; mb(); if (cur-\u0026gt;cancelling) return -EDEADLK; unlock(t-\u0026gt;lock); hrtimer_cancel(t-\u0026gt;timer); t-\u0026gt;cancelling = false; El almac\u00e9n fuera de la secci\u00f3n cr\u00edtica podr\u00eda sobrescribir una asignaci\u00f3n de cancelaci\u00f3n t-\u0026gt;de solicitudes paralelas a verdadero, para garantizar que la devoluci\u00f3n de llamada que se ejecuta en paralelo observe su estado de cancelaci\u00f3n. Ser\u00eda necesario borrar este bit de cancelaci\u00f3n una vez que se complete hrtimer_cancel, pero la falta de serializaci\u00f3n introdujo ejecuciones. Se explor\u00f3 otra opci\u00f3n donde bpf_timer_start borrar\u00eda el bit al (re)iniciar el temporizador bajo temporizador-\u0026gt;bloqueo. Esto garantizar\u00eda el acceso serializado al bit de cancelaci\u00f3n, pero puede permitir que se borre antes de que hrtimer_cancel en vuelo haya terminado de ejecutarse, de modo que los bloqueos puedan ocurrir nuevamente. Por lo tanto, elegimos un contador at\u00f3mico para realizar un seguimiento de todas las solicitudes de cancelaci\u00f3n pendientes y lo utilizamos para evitar bloqueos en caso de que las devoluciones de llamada intenten cancelarse entre s\u00ed mientras se ejecutan en paralelo.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-667\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.15\",\"versionEndExcluding\":\"6.6.41\",\"matchCriteriaId\":\"DA87C02E-A4BF-4FD7-AE47-A2AB23061A91\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.7\",\"versionEndExcluding\":\"6.9.10\",\"matchCriteriaId\":\"AB2E8DEC-CFD5-4C2B-981D-E7E45A36C352\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/3e4e8178a8666c56813bd167b848fca0f4c9af0a\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/9369830518688ecd5b08ffc08ab3302ce2b5d0f7\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/d4523831f07a267a943f0dde844bf8ead7495f13\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2024-42239\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2024-09-10T16:13:54.505425Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2024-09-11T12:42:24.240Z\"}}], \"cna\": {\"title\": \"bpf: Fail bpf_timer_cancel when callback is being cancelled\", \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"b00628b1c7d595ae5b544e059c27b1f5828314b4\", \"lessThan\": \"9369830518688ecd5b08ffc08ab3302ce2b5d0f7\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"b00628b1c7d595ae5b544e059c27b1f5828314b4\", \"lessThan\": \"3e4e8178a8666c56813bd167b848fca0f4c9af0a\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"b00628b1c7d595ae5b544e059c27b1f5828314b4\", \"lessThan\": \"d4523831f07a267a943f0dde844bf8ead7495f13\", \"versionType\": \"git\"}], \"programFiles\": [\"kernel/bpf/helpers.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"5.15\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"5.15\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"6.6.41\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.6.*\"}, {\"status\": \"unaffected\", \"version\": \"6.9.10\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.9.*\"}, {\"status\": \"unaffected\", \"version\": \"6.10\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"kernel/bpf/helpers.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/9369830518688ecd5b08ffc08ab3302ce2b5d0f7\"}, {\"url\": \"https://git.kernel.org/stable/c/3e4e8178a8666c56813bd167b848fca0f4c9af0a\"}, {\"url\": \"https://git.kernel.org/stable/c/d4523831f07a267a943f0dde844bf8ead7495f13\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbpf: Fail bpf_timer_cancel when callback is being cancelled\\n\\nGiven a schedule:\\n\\ntimer1 cb\\t\\t\\ttimer2 cb\\n\\nbpf_timer_cancel(timer2);\\tbpf_timer_cancel(timer1);\\n\\nBoth bpf_timer_cancel calls would wait for the other callback to finish\\nexecuting, introducing a lockup.\\n\\nAdd an atomic_t count named \u0027cancelling\u0027 in bpf_hrtimer. This keeps\\ntrack of all in-flight cancellation requests for a given BPF timer.\\nWhenever cancelling a BPF timer, we must check if we have outstanding\\ncancellation requests, and if so, we must fail the operation with an\\nerror (-EDEADLK) since cancellation is synchronous and waits for the\\ncallback to finish executing. This implies that we can enter a deadlock\\nsituation involving two or more timer callbacks executing in parallel\\nand attempting to cancel one another.\\n\\nNote that we avoid incrementing the cancelling counter for the target\\ntimer (the one being cancelled) if bpf_timer_cancel is not invoked from\\na callback, to avoid spurious errors. The whole point of detecting\\ncur-\u003ecancelling and returning -EDEADLK is to not enter a busy wait loop\\n(which may or may not lead to a lockup). This does not apply in case the\\ncaller is in a non-callback context, the other side can continue to\\ncancel as it sees fit without running into errors.\\n\\nBackground on prior attempts:\\n\\nEarlier versions of this patch used a bool \u0027cancelling\u0027 bit and used the\\nfollowing pattern under timer-\u003elock to publish cancellation status.\\n\\nlock(t-\u003elock);\\nt-\u003ecancelling = true;\\nmb();\\nif (cur-\u003ecancelling)\\n\\treturn -EDEADLK;\\nunlock(t-\u003elock);\\nhrtimer_cancel(t-\u003etimer);\\nt-\u003ecancelling = false;\\n\\nThe store outside the critical section could overwrite a parallel\\nrequests t-\u003ecancelling assignment to true, to ensure the parallely\\nexecuting callback observes its cancellation status.\\n\\nIt would be necessary to clear this cancelling bit once hrtimer_cancel\\nis done, but lack of serialization introduced races. Another option was\\nexplored where bpf_timer_start would clear the bit when (re)starting the\\ntimer under timer-\u003elock. This would ensure serialized access to the\\ncancelling bit, but may allow it to be cleared before in-flight\\nhrtimer_cancel has finished executing, such that lockups can occur\\nagain.\\n\\nThus, we choose an atomic counter to keep track of all outstanding\\ncancellation requests and use it to prevent lockups in case callbacks\\nattempt to cancel each other while executing in parallel.\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.6.41\", \"versionStartIncluding\": \"5.15\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.9.10\", \"versionStartIncluding\": \"5.15\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.10\", \"versionStartIncluding\": \"5.15\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2025-05-04T09:24:50.911Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2024-42239\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2025-05-04T09:24:50.911Z\", \"dateReserved\": \"2024-07-30T07:40:12.253Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-08-07T15:14:27.382Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.