CVE-2022-49687

In the Linux kernel, the following vulnerability has been resolved:

virtionet: fix xdprxq_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 xdprxqinfounreg+0x58/0x60 Call trace: xdprxqinfounreg+0x58/0x60 virtnet_close+0x58/0xac __devclosemany+0xac/0x140 _devchangeflags+0xd8/0x210 devchangeflags+0x24/0x64 dosetlink+0x230/0xdd0 ...

This happens because virtnetfreeze() frees the receivequeue completely (including struct xdprxqinfo) but does not call xdprxqinfounreg(). Similarly, virtnetrestore() sets up the receivequeue again but does not call xdprxqinforeg().

Actually, parts of virtnetfreezedown() and virtnetrestoreup() are almost identical to virtnetclose() and virtnetopen(): only the calls to xdprxqinfo_(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 xdprxqinfo 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.