fkie_cve-2021-47396
Vulnerability from fkie_nvd
Published
2024-05-21 15:15
Modified
2024-11-21 06:36
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: mac80211-hwsim: fix late beacon hrtimer handling Thomas explained in https://lore.kernel.org/r/87mtoeb4hb.ffs@tglx that our handling of the hrtimer here is wrong: If the timer fires late (e.g. due to vCPU scheduling, as reported by Dmitry/syzbot) then it tries to actually rearm the timer at the next deadline, which might be in the past already: 1 2 3 N N+1 | | | ... | | ^ intended to fire here (1) ^ next deadline here (2) ^ actually fired here The next time it fires, it's later, but will still try to schedule for the next deadline (now 3), etc. until it catches up with N, but that might take a long time, causing stalls etc. Now, all of this is simulation, so we just have to fix it, but note that the behaviour is wrong even per spec, since there's no value then in sending all those beacons unaligned - they should be aligned to the TBTT (1, 2, 3, ... in the picture), and if we're a bit (or a lot) late, then just resume at that point. Therefore, change the code to use hrtimer_forward_now() which will ensure that the next firing of the timer would be at N+1 (in the picture), i.e. the next interval point after the current time.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/2c204cf594df3b9468368dc9d0b24d482d93cda7
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/313bbd1990b6ddfdaa7da098d0c56b098a833572
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/9bee85de2c8155388c09a2e1530a243ec1c96f05
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/ed2adf69e29848d1eb9df99633dde655421c92ed
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/2c204cf594df3b9468368dc9d0b24d482d93cda7
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/313bbd1990b6ddfdaa7da098d0c56b098a833572
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/9bee85de2c8155388c09a2e1530a243ec1c96f05
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/ed2adf69e29848d1eb9df99633dde655421c92ed
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmac80211-hwsim: fix late beacon hrtimer handling\n\nThomas explained in https://lore.kernel.org/r/87mtoeb4hb.ffs@tglx\nthat our handling of the hrtimer here is wrong: If the timer fires\nlate (e.g. due to vCPU scheduling, as reported by Dmitry/syzbot)\nthen it tries to actually rearm the timer at the next deadline,\nwhich might be in the past already:\n\n 1          2          3          N          N+1\n |          |          |   ...    |          |\n\n ^ intended to fire here (1)\n            ^ next deadline here (2)\n                                      ^ actually fired here\n\nThe next time it fires, it\u0027s later, but will still try to schedule\nfor the next deadline (now 3), etc. until it catches up with N,\nbut that might take a long time, causing stalls etc.\n\nNow, all of this is simulation, so we just have to fix it, but\nnote that the behaviour is wrong even per spec, since there\u0027s no\nvalue then in sending all those beacons unaligned - they should be\naligned to the TBTT (1, 2, 3, ... in the picture), and if we\u0027re a\nbit (or a lot) late, then just resume at that point.\n\nTherefore, change the code to use hrtimer_forward_now() which will\nensure that the next firing of the timer would be at N+1 (in the\npicture), i.e. the next interval point after the current time."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: mac80211-hwsim: corrige el manejo tard\u00edo del hrtimer de baliza. Thomas explic\u00f3 en https://lore.kernel.org/r/87mtoeb4hb.ffs@tglx que nuestro manejo del hrtimer aqu\u00ed es incorrecto : Si el temporizador se activa tarde (por ejemplo, debido a la programaci\u00f3n de vCPU, seg\u00fan lo informado por Dmitry/syzbot), entonces intenta rearmar el temporizador en la pr\u00f3xima fecha l\u00edmite, que podr\u00eda haber sido ya en el pasado: 1 2 3 N N+1 | | | ... | | ^ intenci\u00f3n de disparar aqu\u00ed (1) ^ pr\u00f3xima fecha l\u00edmite aqu\u00ed (2) ^ realmente disparado aqu\u00ed La pr\u00f3xima vez que se active, ser\u00e1 m\u00e1s tarde, pero a\u00fan as\u00ed intentar\u00e1 programar la pr\u00f3xima fecha l\u00edmite (ahora 3), etc. hasta que se ponga al d\u00eda N, pero eso podr\u00eda llevar mucho tiempo, causando bloqueos, etc. Ahora, todo esto es simulaci\u00f3n, as\u00ed que solo tenemos que arreglarlo, pero tenga en cuenta que el comportamiento es incorrecto incluso seg\u00fan la especificaci\u00f3n, ya que no tiene ning\u00fan valor enviar todos esos balizas no alineadas: deben estar alineadas con el TBTT (1, 2, 3, ... en la imagen), y si llegamos un poco (o mucho) tarde, simplemente reanudemos en ese punto. Por lo tanto, cambie el c\u00f3digo para usar hrtimer_forward_now(), lo que garantizar\u00e1 que el siguiente disparo del temporizador sea en N+1 (en la imagen), es decir, el siguiente punto del intervalo despu\u00e9s de la hora actual."
    }
  ],
  "id": "CVE-2021-47396",
  "lastModified": "2024-11-21T06:36:03.537",
  "metrics": {},
  "published": "2024-05-21T15:15:24.920",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/2c204cf594df3b9468368dc9d0b24d482d93cda7"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/313bbd1990b6ddfdaa7da098d0c56b098a833572"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/9bee85de2c8155388c09a2e1530a243ec1c96f05"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/ed2adf69e29848d1eb9df99633dde655421c92ed"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://git.kernel.org/stable/c/2c204cf594df3b9468368dc9d0b24d482d93cda7"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://git.kernel.org/stable/c/313bbd1990b6ddfdaa7da098d0c56b098a833572"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://git.kernel.org/stable/c/9bee85de2c8155388c09a2e1530a243ec1c96f05"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://git.kernel.org/stable/c/ed2adf69e29848d1eb9df99633dde655421c92ed"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


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.