fkie_cve-2022-49687
Vulnerability from fkie_nvd
Published
2025-02-26 07:01
Modified
2025-02-26 07:01
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
virtio_net: fix xdp_rxq_info bug after suspend/resume
The following sequence currently causes a driver bug warning
when using virtio_net:
# ip link set eth0 up
# echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem)
<resume>
# ip link set eth0 down
Missing register, driver bug
WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138 xdp_rxq_info_unreg+0x58/0x60
Call trace:
xdp_rxq_info_unreg+0x58/0x60
virtnet_close+0x58/0xac
__dev_close_many+0xac/0x140
__dev_change_flags+0xd8/0x210
dev_change_flags+0x24/0x64
do_setlink+0x230/0xdd0
...
This happens because virtnet_freeze() frees the receive_queue
completely (including struct xdp_rxq_info) but does not call
xdp_rxq_info_unreg(). Similarly, virtnet_restore() sets up the
receive_queue again but does not call xdp_rxq_info_reg().
Actually, parts of virtnet_freeze_down() and virtnet_restore_up()
are almost identical to virtnet_close() and virtnet_open(): only
the calls to xdp_rxq_info_(un)reg() are missing. This means that
we can fix this easily and avoid such problems in the future by
just calling virtnet_close()/open() from the freeze/restore handlers.
Aside from adding the missing xdp_rxq_info calls the only difference
is that the refill work is only cancelled if netif_running(). However,
this should not make any functional difference since the refill work
should only be active if the network interface is actually up.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: fix xdp_rxq_info bug after suspend/resume\n\nThe following sequence currently causes a driver bug warning\nwhen using virtio_net:\n\n # ip link set eth0 up\n # echo mem \u003e /sys/power/state (or e.g. # rtcwake -s 10 -m mem)\n \u003cresume\u003e\n # ip link set eth0 down\n\n Missing register, driver bug\n WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138 xdp_rxq_info_unreg+0x58/0x60\n Call trace:\n xdp_rxq_info_unreg+0x58/0x60\n virtnet_close+0x58/0xac\n __dev_close_many+0xac/0x140\n __dev_change_flags+0xd8/0x210\n dev_change_flags+0x24/0x64\n do_setlink+0x230/0xdd0\n ...\n\nThis happens because virtnet_freeze() frees the receive_queue\ncompletely (including struct xdp_rxq_info) but does not call\nxdp_rxq_info_unreg(). Similarly, virtnet_restore() sets up the\nreceive_queue again but does not call xdp_rxq_info_reg().\n\nActually, parts of virtnet_freeze_down() and virtnet_restore_up()\nare almost identical to virtnet_close() and virtnet_open(): only\nthe calls to xdp_rxq_info_(un)reg() are missing. This means that\nwe can fix this easily and avoid such problems in the future by\njust calling virtnet_close()/open() from the freeze/restore handlers.\n\nAside from adding the missing xdp_rxq_info calls the only difference\nis that the refill work is only cancelled if netif_running(). However,\nthis should not make any functional difference since the refill work\nshould only be active if the network interface is actually up."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio_net: correcci\u00f3n del error xdp_rxq_info despu\u00e9s de suspender/reanudar La siguiente secuencia actualmente provoca una advertencia de error del controlador al usar virtio_net: # ip link set eth0 up # echo mem \u0026gt; /sys/power/state (or e.g. # rtcwake -s 10 -m mem) # ip link set eth0 down Missing register, driver bug WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138 xdp_rxq_info_unreg+0x58/0x60 Call trace: xdp_rxq_info_unreg+0x58/0x60 virtnet_close+0x58/0xac __dev_close_many+0xac/0x140 __dev_change_flags+0xd8/0x210 dev_change_flags+0x24/0x64 do_setlink+0x230/0xdd0 ... This happens because virtnet_freeze() frees the receive_queue completely (including struct xdp_rxq_info) but does not call xdp_rxq_info_unreg(). Similarly, virtnet_restore() sets up the receive_queue again but does not call xdp_rxq_info_reg(). Actually, parts of virtnet_freeze_down() and virtnet_restore_up() are almost identical to virtnet_close() and virtnet_open(): only the calls to xdp_rxq_info_(un)reg() are missing. Esto significa que podemos solucionar esto f\u00e1cilmente y evitar este tipo de problemas en el futuro simplemente llamando a virtnet_close()/open() desde los controladores de congelaci\u00f3n/restauraci\u00f3n. Aparte de agregar las llamadas xdp_rxq_info faltantes, la \u00fanica diferencia es que el trabajo de recarga solo se cancela si se ejecuta netif_running(). Sin embargo, esto no deber\u00eda generar ninguna diferencia funcional, ya que el trabajo de recarga solo deber\u00eda estar activo si la interfaz de red est\u00e1 realmente activa."
}
],
"id": "CVE-2022-49687",
"lastModified": "2025-02-26T07:01:43.527",
"metrics": {},
"published": "2025-02-26T07:01:43.527",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/340fbdc8011f2dc678f622c5ce1cbb5ab8305de7"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/57ee40f1b198b59d43c216fbc4672f9300d3c8b0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/8af52fe9fd3bf5e7478da99193c0632276e1dfce"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/8c7a32b7c15555beddc5810c3334d9cefff061bf"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/8d7fe9ad6fddc2af8bde4b921b4f8fab231ed38c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/9222672fa6370f0ec3d899662cb8680e9282fc4c"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
Loading…
Loading…
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.
Loading…