linux-kernel - Intel ixgbe: uninitialized variable use in ixgbe_non_sfp_link

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

Date:	Sun, 8 Jan 2012 22:23:16 +0100 (CET)
From:	Jesper Juhl <jj@...osbits.net>
To:	e1000-devel Mailing List <e1000-devel@...ts.sourceforge.net>
cc:	"David S. Miller" <davem@...emloft.net>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	Bruce Allan <bruce.w.allan@...el.com>,
	linux-kernel@...r.kernel.org
Subject: Intel ixgbe: uninitialized variable use in ixgbe_non_sfp_link_config()

Hi (sorry about the duplicate, I messed up the LKML addr. on the first mail)

In ixgbe_non_sfp_link_config(), the variable 'negotiation' is declared
without initializer and unless we take the true branch in the 'if
((!autoneg) && (hw->mac.ops.get_link_capabilities))' statement it will
remain uninitialized when it is subsequently read in the 'ret =
hw->mac.ops.setup_link(hw, autoneg, negotiation, link_up)' statement.

The test of 'ret' after the 'if ((!autoneg) &&
(hw->mac.ops.get_link_capabilities))' statement also looks fairly
pointless if we do not take the true branch, since then 'ret' will not
have been changed since the previous identical test.

The correct fix escapes me since I don't really know this code (and don't 
plan to spend the time to get to know it), but I thought I'd just report 
what I had noticed and then someone else can hopefully come up with a good 
fix :-)

PS. Please CC me on replies.

-- 
Jesper Juhl <jj@...osbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/