Wind River Support Network

Description

In the Linux kernel, the following vulnerability has been resolved:[EOL][EOL]net: netpoll: fix incorrect refcount handling causing incorrect cleanup[EOL][EOL]commit efa95b01da18 ("netpoll: fix use after free") incorrectly[EOL]ignored the refcount and prematurely set dev->npinfo to NULL during[EOL]netpoll cleanup, leading to improper behavior and memory leaks.[EOL][EOL]Scenario causing lack of proper cleanup:[EOL][EOL]1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is[EOL]   allocated, and refcnt = 1[EOL]   - Keep in mind that npinfo is shared among all netpoll instances. In[EOL]     this case, there is just one.[EOL][EOL]2) Another netpoll is also associated with the same NIC and[EOL]   npinfo->refcnt += 1.[EOL]   - Now dev->npinfo->refcnt = 2;[EOL]   - There is just one npinfo associated to the netdev.[EOL][EOL]3) When the first netpolls goes to clean up:[EOL]   - The first cleanup succeeds and clears np->dev->npinfo, ignoring[EOL]     refcnt.[EOL]     - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);`[EOL]   - Set dev->npinfo = NULL, without proper cleanup[EOL]   - No ->ndo_netpoll_cleanup() is either called[EOL][EOL]4) Now the second target tries to clean up[EOL]   - The second cleanup fails because np->dev->npinfo is already NULL.[EOL]     * In this case, ops->ndo_netpoll_cleanup() was never called, and[EOL]       the skb pool is not cleaned as well (for the second netpoll[EOL]       instance)[EOL]  - This leaks npinfo and skbpool skbs, which is clearly reported by[EOL]    kmemleak.[EOL][EOL]Revert commit efa95b01da18 ("netpoll: fix use after free") and adds[EOL]clarifying comments emphasizing that npinfo cleanup should only happen[EOL]once the refcount reaches zero, ensuring stable and correct netpoll[EOL]behavior.