All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Freyermuth <o.freyermuth@googlemail.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Memory corruption kernel issue (potentially exploitable), request for help
Date: Fri, 26 May 2017 16:53:08 +0200	[thread overview]
Message-ID: <dbffb669-a9a4-aa08-53fe-b8f5e8841a36@googlemail.com> (raw)
In-Reply-To: <9a5a76c2-b38a-9cde-8da6-616ba23c6d88@googlemail.com>

Dear Kernel hackers, 

a small follow up: The problem is reproducible with an Ubuntu 17.04 live system. 
It vanishes as soon as I disable the Realtek-network-card in the UEFI, put in an Intel card, and use that. 

So the problem must either be a kernel bug (then most likely for r8168 only), or a very strange firmware / hardware issue of this specific card. 

If you have any further suggestions to debug this (if it's a kernel bug, I would guess it's exploitable since it allows writes to non-userspace memory), please let me know. 

Cheers and all the best, 
	Oliver

Am 26.05.2017 um 13:26 schrieb Oliver Freyermuth:
> Dear Kernel hackers, 
> 
> I have a machine with a self-built, non-tainted kernel, which exhibits memory corruption as soon as I execute
> while true; do cat /proc/self/net/dev > /dev/null; done
> as normal user. 
> 
> I am running 4.11.3 (almost vanilla, only Gentoo patches in) on mostly standard hardware (Intel CPU + GPU). 
> I can also reproduce with 4.9 on that machine. 
> RAM has already been exchanged. Due to a BIOS bug, the machine needs "iommu=soft" as kernel parameter, but nothing special otherwise. 
> 
> The corruption appears in two ways: 
> Often via:
> Corrupted low memory at ffff88000000b000 (b000 phys) = 0016e109
> Almost every time visible via:
> memtester 15G
> (machine has 16 G). 
> 
> Checking the output of memtester, the values it finds match with the content of the numbers in: 
> /proc/self/net/dev
> 
> After each boot, it seems the memory page where the corruption appears is slightly changed, it is usually in the region around 0x94F6000 (physical address). 
> 
> I have attached my kernel config, gzipped. 
> 
> I would be very grateful for any advice on how to debug this further - it does not really look like a hardware issue to me anymore, 
> but if it could be, please enlighten me. 
> 
> Please include me in replies, as I am not subscribed to the list. 
> 
> In case relevant, my network controller is:
> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
> 
> Thanks and all the best, 
> 	Oliver Freyermuth
> 

      reply	other threads:[~2017-05-26 14:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26 11:26 Memory corruption kernel issue (potentially exploitable), request for help Oliver Freyermuth
2017-05-26 14:53 ` Oliver Freyermuth [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dbffb669-a9a4-aa08-53fe-b8f5e8841a36@googlemail.com \
    --to=o.freyermuth@googlemail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.