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
>
prev parent 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®