netdev - Re: [PATCH net-next] cnic: call cp->stop_hw() in cnic_start

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20160506.154529.2181132233503341654.davem@davemloft.net>
Date:	Fri, 06 May 2016 15:45:29 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	jmaxwell37@...il.com
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	jmaxwell@...hat.com, ivecera@...hat.com
Subject: Re: [PATCH net-next] cnic: call cp->stop_hw() in cnic_start_hw()
 on allocation failure

From: Jon Maxwell <jmaxwell37@...il.com>
Date: Thu,  5 May 2016 09:55:51 +1000

> We recently had a system crash in the cnic module. Vmcore analysis confirmed 
> that "ip link up" was executed which failed due to an allocation failure 
> because of memory fragmentation. Futher analysis revealed that the cnic irq 
> vector was still allocated after the "ip link up" that failed. When 
> "ip link down" was executed it called free_msi_irqs() which crashed the system 
> because the cnic irq was still inuse.
 ...
> The cnic_start_hw() routine is not handling the allocation failure correctly. 
> Fix this by checking whether CNIC_DRV_STATE_HANDLES_IRQ flag is set indicating 
> that the hardware has been started in cnic_start_hw(). If it has then call 
> cp->stop_hw() which frees the cnic irq vector and cnic resources. Otherwise 
> just maintain the previous behaviour and free cnic resources. 
> 
> I reproduced this by injecting an ENOMEM error into cnic_cm_alloc_mem()s return
> code. 
> 
> # ip link set dev enpX down
> # ip link set dev enpX up <--- hit's allocation failure
> # ip link set dev enpX down <--- crashes here
> 
> With this patch I confirmed there was no crash in the reproducer.
> 
> Signed-off-by: Jon Maxwell <jmaxwell37@...il.com>

Applied, thank you.