netdev - Re: [net-next 03/16] fm10k: Avoid crashing the kernel

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20160405.121234.207383895896842448.davem@davemloft.net>
Date:	Tue, 05 Apr 2016 12:12:34 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	jeffrey.t.kirsher@...el.com
Cc:	bruce.w.allan@...el.com, netdev@...r.kernel.org,
	nhorman@...hat.com, sassmann@...hat.com, jogreene@...hat.com
Subject: Re: [net-next 03/16] fm10k: Avoid crashing the kernel

From: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Date: Tue,  5 Apr 2016 01:01:15 -0700

> diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
> index 28837ae..6a9f988 100644
> --- a/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
> +++ b/drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c
> @@ -398,7 +398,7 @@ static void fm10k_get_reg_q(struct fm10k_hw *hw, u32 *buff, int i)
>  	buff[idx++] = fm10k_read_reg(hw, FM10K_TX_SGLORT(i));
>  	buff[idx++] = fm10k_read_reg(hw, FM10K_PFVTCTL(i));
>  
> -	BUG_ON(idx != FM10K_REGS_LEN_Q);
> +	BUILD_BUG_ON(idx != FM10K_REGS_LEN_Q);
>  }
>  
>  /* If function above adds more registers this define needs to be updated */

As Joe suggested, it is not reasonable to expect all compilers to be able to figure
out the result of all of the index increments in this function lead to a specific
constant value.

Your only option is to either keep the code as-is, or add proper error reporting to
this function and to all callers, in order to handle the situation at run time which
I realize is exactly what you are trying to avoid.

If this crashes at run time with the BUG_ON(), it's going to happen really quickly
when you bring the interface up.  So I don't see the run time check as so tragic.