Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
net: atlantic: invert deep par in pm functions, preventing null derefs
From 6c4cd8210835489da84bf4ee5049945dc0f2c986 Mon Sep 17 00:00:00 2001 Date: Mon, 18 Apr 2022 00:20:01 +0200 This will reset deeply on freeze and thaw instead of suspend and resume and prevent null pointer dereferences of the uninitialized ring 0 buffer while thawing. The impact is an indefinitely hanging kernel. You can't switch consoles after this and the only possible user interaction is SysRq. BUG: kernel NULL pointer dereference RIP: 0010:aq_ring_rx_fill+0xcf/0x210 [atlantic] aq_vec_init+0x85/0xe0 [atlantic] aq_nic_init+0xf7/0x1d0 [atlantic] atl_resume_common+0x4f/0x100 [atlantic] pci_pm_thaw+0x42/0xa0 resolves in aq_ring.o to ``` 0000000000000ae0 <aq_ring_rx_fill>: { /* ... */ baf: 48 8b 43 08 mov 0x8(%rbx),%rax buff->flags = 0U; /* buff is NULL */ ``` The bug has been present since the introduction of the new pm code in 8aaa112 ("net: atlantic: refactoring pm logic") and was hidden until 8ce8427 ("net: atlantic: changes for multi-TC support"), which refactored the aq_vec_{free,alloc} functions into aq_vec_{,ring}_{free,alloc}, but is technically not wrong. The original functions just always reinitialized the buffers on S3/S4. If the interface is down before freezing, the bug does not occur. It does not matter, whether the initrd contains and loads the module before thawing. So the fix is to invert the boolean parameter deep in all pm function calls, which was clearly intended to be set like that. First report was on Github [1], which you have to guess from the resume logs in the posted dmesg snippet. Recently I posted one on Bugzilla [2], since I did not have an AQC device so far. #regzbot introduced: 8ce8427 #regzbot from: koo5 <[email protected]> #regzbot monitor: Aquantia/AQtion#32 Fixes: 8aaa112 ("net: atlantic: refactoring pm logic") Link: Aquantia/AQtion#32 [1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=215798 [2] Cc: [email protected] Reported-by: koo5 <[email protected]> Signed-off-by: Manuel Ullmann <[email protected]>
- Loading branch information