linux-kernel - Re: [PATCH] sky2: avoid using uninitialized variable

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20110614000230.4166a1ae@s6510.ftrdhcpuser.net>
Date:	Tue, 14 Jun 2011 00:02:30 -0400
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Greg Thelen <gthelen@...gle.com>
Cc:	Stephen Hemminger <shemminger@...ux-foundation.org>,
	netdev@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] sky2: avoid using uninitialized variable

On Mon, 13 Jun 2011 17:34:00 -0700
Greg Thelen <gthelen@...gle.com> wrote:

> On Mon, Jun 13, 2011 at 3:12 PM, Stephen Hemminger
> <shemminger@...tta.com> wrote:
> > On Mon, 13 Jun 2011 14:21:59 -0700
> > Greg Thelen <gthelen@...gle.com> wrote:
> >
> >> I am not sure if 0 or ~0 would be a better choice in the gm_phy_read()
> >> error case.  I used 0.  A more complete solution might be to plumb up
> >> error handling to the callers of gm_phy_read().
> >>
> >> ==
> >> From 37486219a3d93881f3b2619a4b2bb21be62db7d4 Mon Sep 17 00:00:00 2001
> >> From: Greg Thelen <gthelen@...gle.com>
> >> Date: Mon, 13 Jun 2011 14:09:07 -0700
> >> Subject: [PATCH] sky2: avoid using uninitialized variable
> >>
> >> Prior to this change gm_phy_read() could return an uninitialized
> >> variable if __gm_phy_read() failed.
> >>
> >> This change returns zero in the failure case.
> >>
> >> Signed-off-by: Greg Thelen <gthelen@...gle.com>
> >
> > Shouldn't the callers be changed to check rather than just returning
> > 0 and masking the problem.
> 
> I agree that the right long term solution is to plumb the error
> handling up through the callers.  This would involve deleting the
> error-free gm_phy_read() routine and replacing all calls to it with
> calls to error-capable __gm_phy_read().  This would require converting
> several routines from returning void to returning int allowing errors
> to propagate upwards.  Notable affected routines include:
> sky2_phy_power_up(), sky2_wol_init(), sky2_phy_power_down(),
> sky2_hw_down(), sky2_mac_init(), sky2_hw_up(), sky2_phy_intr(),
> sky2_led().  sky2_restart() would likely have to re-queue the work
> item in the case of failure.  Presumably sky2_poll() would return 0 if
> error is seen.  On a related note, it also seems that gm_phy_write()
> callers should be checking its return value to also handle the same
> class of I/O errors.  Testing these changes would involve injecting
> error values or access to certain kinds of broken hardware.

In my experience if phy reads once successfully, it is going
to read every time. If there is a problem it only happens on
the first access (powered off, bad timing, etc).


 
> For the short term I figured that not consuming random data was a step
> in right direction.  But I understand if you prefer to hold out for
> the complete solution.  Unfortunately, I do not currently have time to
> contribute to the complete solution.

--
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/