User: Password:
|
|
Subscribe / Log in / New account

The source of the e1000e corruption bug

The source of the e1000e corruption bug

Posted Oct 23, 2008 18:02 UTC (Thu) by jimparis (subscriber, #38647)
Parent article: The source of the e1000e corruption bug

> So the no-ops will only be written to memory if the current contents of that memory are a call to mcount().
> This all seems pretty safe, except that it fell down in one obscure, but important case

There's another bad case: When the memory was freed and reallocated with vmalloc, then filled with non-code data that includes the same byte sequence as the original call to mcount(). No I/O remapping required and now you've corrupted something. Although the chance of having some random data in kernel memory exactly match the pattern that was there before is probably vanishingly small, it's still there. I'm glad to hear the ftrace code has been reworked to not do this anymore.


(Log in to post comments)

The source of the e1000e corruption bug

Posted Oct 23, 2008 18:34 UTC (Thu) by nevets (subscriber, #11875) [Link]

Why do you think I stressed in my quote:

The cmpxchg could have saved us in most cases (via luck) - but with ioremap-ed memory that was exactly the wrong thing to do - the results of cmpxchg on device memory are undefined. (and will likely result in a write)

;-)

The source of the e1000e corruption bug

Posted Oct 23, 2008 19:37 UTC (Thu) by jimparis (subscriber, #38647) [Link]

Aah, I did misread that, as "if we're lucky then the memory was not ioremapped and so the cmpxchg saves us". Nevermind, carry on :)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds