linux-kernel - Re: [PATCH] e1000 driver RX race condition fixed

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]

Date:	Mon, 15 Oct 2012 11:53:59 -0700
From:	Alexander Duyck <alexander.h.duyck@...el.com>
To:	Dmitry Fleytman <dmitry@...nix.com>
CC:	linux-kernel@...r.kernel.org, e1000-devel@...ts.sourceforge.net,
	Chris Webb <chris.webb@...stichosts.com>,
	Richard Davies <richard.davies@...stichosts.com>
Subject: Re: [PATCH] e1000 driver RX race condition fixed

On 10/14/2012 10:19 AM, Dmitry Fleytman wrote:
> There is a race condition in e1000 driver.
> It enables HW receive before RX rings initalization.
> In case of specific timing this may lead to host memory corruption
> due to DMA write to arbitrary memory location.
> Following patch fixes this issue by reordering initialization steps.
>
> Other Intel network drivers does not seem to have this issue.
>
> Dmitry Fleytman (1):
>   RX initialization sequence fixed - enable RX after corresponding ring
>     initialization only
>
>  drivers/net/ethernet/intel/e1000/e1000_ethtool.c |    9 +++++----
>  drivers/net/ethernet/intel/e1000/e1000_main.c    |   18 ++++++++++++++++--
>  2 files changed, 21 insertions(+), 6 deletions(-)
>

What device was it you saw this issue with?  The reason why I ask is
because I suspect this change should cause most of our e1000 hardware to
lock up since normally if you allocate buffers and then enable Rx it
will mean the ring was not updated and it will treat it as if there are
no buffers available.

Thanks,

Alex

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