Homepage

CVE-2022-49687 The advisory has been revoked - it doesn't affect any version of package kernel  (opens in a new tab)

Threat Intelligence

EPSS
0.29% (22nd percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-RHEL9-KERNEL-10222562
  • published21 May 2025
  • disclosed26 Feb 2025
Report a new vulnerability Found a mistake?

Introduced: 26 Feb 2025

CVE-2022-49687  (opens in a new tab)

Amendment

The Red Hat security team deemed this advisory irrelevant for RHEL:9.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel package and not the kernel package as distributed by RHEL.

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.