CVE-2022-49687

virtio_net: fix xdp_rxq_info bug after suspend/resume

published February 26, 2025

CVSS
—
EPSS
0%
Percentile
20.3
In the wild
Unconfirmed
What it is

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.

The record
Technical detail
CVSS
Not scored
CVSS v4.0
Not supplied
EPSS
0.00289 · 20.3th percentile
Published
2025-02-26T02:24Z
EPSS history
Timeline
  • 26 FEB 02:24Z
    virtio_net: fix xdp_rxq_info bug after suspend/resume
    cvelistv5