CVE-2024-26803

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: veth: clear GRO when clearing XDP even when down<br /> <br /> veth sets NETIF_F_GRO automatically when XDP is enabled,<br /> because both features use the same NAPI machinery.<br /> <br /> The logic to clear NETIF_F_GRO sits in veth_disable_xdp() which<br /> is called both on ndo_stop and when XDP is turned off.<br /> To avoid the flag from being cleared when the device is brought<br /> down, the clearing is skipped when IFF_UP is not set.<br /> Bringing the device down should indeed not modify its features.<br /> <br /> Unfortunately, this means that clearing is also skipped when<br /> XDP is disabled _while_ the device is down. And there&amp;#39;s nothing<br /> on the open path to bring the device features back into sync.<br /> IOW if user enables XDP, disables it and then brings the device<br /> up we&amp;#39;ll end up with a stray GRO flag set but no NAPI instances.<br /> <br /> We don&amp;#39;t depend on the GRO flag on the datapath, so the datapath<br /> won&amp;#39;t crash. We will crash (or hang), however, next time features<br /> are sync&amp;#39;ed (either by user via ethtool or peer changing its config).<br /> The GRO flag will go away, and veth will try to disable the NAPIs.<br /> But the open path never created them since XDP was off, the GRO flag<br /> was a stray. If NAPI was initialized before we&amp;#39;ll hang in napi_disable().<br /> If it never was we&amp;#39;ll crash trying to stop uninitialized hrtimer.<br /> <br /> Move the GRO flag updates to the XDP enable / disable paths,<br /> instead of mixing them with the ndo_open / ndo_close paths.