fkie_cve-2022-49194
Vulnerability from fkie_nvd
Published
2025-02-26 07:00
Modified
2025-02-26 07:00
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: Use stronger register read/writes to assure ordering GCC12 appears to be much smarter about its dependency tracking and is aware that the relaxed variants are just normal loads and stores and this is causing problems like: [ 210.074549] ------------[ cut here ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet): transmit queue 1 timed out [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240 [ 210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat] [ 210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters [ 210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022 [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 210.161358] pc : dev_watchdog+0x234/0x240 [ 210.161364] lr : dev_watchdog+0x234/0x240 [ 210.161368] sp : ffff8000080a3a40 [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [ 210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [ 210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c [ 210.248171] x8 : 00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000 [ 210.255341] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044 [ 210.269682] Call trace: [ 210.272133] dev_watchdog+0x234/0x240 [ 210.275811] call_timer_fn+0x3c/0x15c [ 210.279489] __run_timers.part.0+0x288/0x310 [ 210.283777] run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x360 [ 210.291392] __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [ 210.298745] el1_interrupt+0x38/0x54 [ 210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445] el1h_64_irq+0x7c/0x80 [ 210.309857] arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [ 210.317470] cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737] cpu_startup_entry+0x30/0x8c [ 210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138] __secondary_switched+0x94/0x98 The assumption when these were relaxed seems to be that device memory would be mapped non reordering, and that other constructs (spinlocks/etc) would provide the barriers to assure that packet data and in memory rings/queues were ordered with respect to device register reads/writes. This itself seems a bit sketchy, but the real problem with GCC12 is that it is moving the actual reads/writes around at will as though they were independent operations when in truth they are not, but the compiler can't know that. When looking at the assembly dumps for many of these routines its possible to see very clean, but not strictly in program order operations occurring as the compiler would be free to do if these weren't actually register reads/write operations. Its possible to suppress the timeout with a liberal bit of dma_mb()'s sprinkled around but the device still seems unable to reliably send/receive data. A better plan is to use the safer readl/writel everywhere. Since this partially reverts an older commit, which notes the use of the relaxed variants for performance reasons. I would suggest that any performance problems ---truncated---
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/06d836801cd82ded282aaf9e888ff9e7e4a88b91
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/1d717816189fd68f9e089cf89ed1f7327d2c2e71
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/8d3ea3d402db94b61075617e71b67459a714a502
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/b26091a02093104259ca64aeca73601e56160d62
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/f49769b462f282477ca801cf648f875b1c5b59db
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bcmgenet: Use stronger register read/writes to assure ordering\n\nGCC12 appears to be much smarter about its dependency tracking and is\naware that the relaxed variants are just normal loads and stores and\nthis is causing problems like:\n\n[  210.074549] ------------[ cut here ]------------\n[  210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet): transmit queue 1 timed out\n[  210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240\n[  210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat]\n[  210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110\n[  210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G            E     5.17.0-rc7G12+ #58\n[  210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters\n[  210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022\n[  210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  210.161358] pc : dev_watchdog+0x234/0x240\n[  210.161364] lr : dev_watchdog+0x234/0x240\n[  210.161368] sp : ffff8000080a3a40\n[  210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20\n[  210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08\n[  210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000\n[  210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffff\n[  210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a\n[  210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0\n[  210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c\n[  210.248171] x8 : 00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000\n[  210.255341] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000001000\n[  210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044\n[  210.269682] Call trace:\n[  210.272133]  dev_watchdog+0x234/0x240\n[  210.275811]  call_timer_fn+0x3c/0x15c\n[  210.279489]  __run_timers.part.0+0x288/0x310\n[  210.283777]  run_timer_softirq+0x48/0x80\n[  210.287716]  __do_softirq+0x128/0x360\n[  210.291392]  __irq_exit_rcu+0x138/0x140\n[  210.295243]  irq_exit_rcu+0x1c/0x30\n[  210.298745]  el1_interrupt+0x38/0x54\n[  210.302334]  el1h_64_irq_handler+0x18/0x24\n[  210.306445]  el1h_64_irq+0x7c/0x80\n[  210.309857]  arch_cpu_idle+0x18/0x2c\n[  210.313445]  default_idle_call+0x4c/0x140\n[  210.317470]  cpuidle_idle_call+0x14c/0x1a0\n[  210.321584]  do_idle+0xb0/0x100\n[  210.324737]  cpu_startup_entry+0x30/0x8c\n[  210.328675]  secondary_start_kernel+0xe4/0x110\n[  210.333138]  __secondary_switched+0x94/0x98\n\nThe assumption when these were relaxed seems to be that device memory\nwould be mapped non reordering, and that other constructs\n(spinlocks/etc) would provide the barriers to assure that packet data\nand in memory rings/queues were ordered with respect to device\nregister reads/writes. This itself seems a bit sketchy, but the real\nproblem with GCC12 is that it is moving the actual reads/writes around\nat will as though they were independent operations when in truth they\nare not, but the compiler can\u0027t know that. When looking at the\nassembly dumps for many of these routines its possible to see very\nclean, but not strictly in program order operations occurring as the\ncompiler would be free to do if these weren\u0027t actually register\nreads/write operations.\n\nIts possible to suppress the timeout with a liberal bit of dma_mb()\u0027s\nsprinkled around but the device still seems unable to reliably\nsend/receive data. A better plan is to use the safer readl/writel\neverywhere.\n\nSince this partially reverts an older commit, which notes the use of\nthe relaxed variants for performance reasons. I would suggest that\nany performance problems \n---truncated---"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: bcmgenet: Use lecturas/escrituras de registros m\u00e1s fuertes para asegurar el orden GCC12 parece ser mucho m\u00e1s inteligente sobre su seguimiento de dependencias y es consciente de que las variantes relajadas son solo cargas y almacenamientos normales y esto est\u00e1 causando problemas como: [ 210.074549] ------------[ cortar aqu\u00ed ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet): se agot\u00f3 el tiempo de espera de la cola de transmisi\u00f3n 1 [ 210.086717] ADVERTENCIA: CPU: 1 PID: 0 en net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240 [ 210.095044] M\u00f3dulos vinculados en: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 CPPC ACPI: el canal de verificaci\u00f3n de PCC fall\u00f3 para ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Contaminado: GE 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: no se pudieron leer los contadores de rendimiento [ 210.161349] Nombre del hardware: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022 [ [210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [210.161358] pc: dev_watchdog+0x234/0x240 [210.161364] lr: dev_watchdog+0x234/0x240 [210.161368] sp: ffff8000080a3a40 [210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a [210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9: ffffcd4258bdad9c [210.248171] x8: 00000000ffffdfff x7: 000000000000003f x6: 0000000000000000 [210.255341] x5: 0000000000000000 x4 : 0000000000000000 x3 : 00000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044 [ 210.269682] Rastreo de llamadas: [ 210.272133] dev_watchdog+0x234/0x240 [ 210.275811] call_timer_fn+0x3c/0x15c [ 210.279489] __run_timers.part.0+0x288/0x310 [ 210.283777] run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x360 [ 210.291392] __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [ 210.298745] el1_interrupt+0x38/0x54 [ 210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445] el1h_64_irq+0x7c/0x80 [ 210.309857] arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [ 210.317470] cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737] cpu_startup_entry+0x30/0x8c [ 210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138] __secondary_switched+0x94/0x98 La suposici\u00f3n cuando se relajaron estos parece ser que la memoria del dispositivo se asignar\u00eda sin reordenamiento, y que otras construcciones (spinlocks/etc) proporcionar\u00eda las barreras para asegurar que los datos de los paquetes y los anillos/colas en memoria se ordenaran con respecto a las lecturas/escrituras de los registros del dispositivo. Esto en s\u00ed mismo parece un poco impreciso, pero el problema real con GCC12 es que est\u00e1 moviendo las lecturas/escrituras reales a voluntad como si fueran operaciones independientes cuando en realidad no lo son, pero el compilador no puede saberlo. Al observar los volcados de ensamblaje para muchas de estas rutinas, es posible ver operaciones muy limpias, pero no estrictamente en el orden del programa, que ocurren como el compilador podr\u00eda hacer si no fueran operaciones de lectura/escritura de registros en realidad. Es posible suprimir el tiempo de espera con un poco de dma_mb() esparcidos por ah\u00ed, pero el dispositivo todav\u00eda parece incapaz de enviar/recibir datos de manera confiable. Un mejor plan es usar el readl/writel m\u00e1s seguro en todas partes. Dado que esto revierte parcialmente una confirmaci\u00f3n anterior, que se\u00f1ala el uso de las variantes relajadas por razones de rendimiento. ---truncado---"
    }
  ],
  "id": "CVE-2022-49194",
  "lastModified": "2025-02-26T07:00:56.483",
  "metrics": {},
  "published": "2025-02-26T07:00:56.483",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/06d836801cd82ded282aaf9e888ff9e7e4a88b91"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/1d717816189fd68f9e089cf89ed1f7327d2c2e71"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/8d3ea3d402db94b61075617e71b67459a714a502"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/b26091a02093104259ca64aeca73601e56160d62"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/f49769b462f282477ca801cf648f875b1c5b59db"
    }
  ],
  "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.