Alexander Popov

@a13xp0p0v

Linux Kernel Developer & Security Researcher

Moscow
Joined December 2012

Tweets

You blocked @a13xp0p0v

Are you sure you want to view these Tweets? Viewing Tweets won't unblock @a13xp0p0v

  1. Pinned Tweet
    4 Apr 2018

    I've created a Linux Kernel Defence Map showing the relations between: - vulnerability classes / exploitation techniques, - kernel defences, - bug detection means. Feedback is welcome. Link:

    Show this thread
    Undo
  2. Retweeted
    Jan 16
    Undo
  3. Jan 23

    And let me thank Mr1 once again! He is cool! I would not be able to become a QEMU contributor without his help :-) [n+1/n]

    Show this thread
    Undo
  4. Jan 23

    And now can you guess who created this bug back in 2015? Yes, it was Mr2. LOL! Maybe that is why he was delaying the fix that killed it. That was weird story. Hope you liked it. Happy end! ========================= [n/n]

    Show this thread
    Undo
  5. Jan 23

    [Jan 22] me: pinging in the ML again about this fix and unit-test! [Jan 22] Mr1: I asked Mr2. He promised to take a look very soon! [Jan 23] Mr2: merged. WOW! Really?!! [17/n]

    Show this thread
    Undo
  6. Jan 23

    [Jan 2] me: Happy New Year everyone! There is a CVE. How about review? /* 5 days passed */ [Jan 7] Mr1: okay, it's fine now. [Jan 8] me: thank you a lot! Let's wait for more reviews. /* 2 weeks passed */ [16/n]

    Show this thread
    Undo
  7. Jan 23

    Meanwhile my friends at 36C3 recommended to request a CVE to speed up the review process :-) Nice idea! Red Had likes CVEs! So MITRE allocated CVE-2019-20175 for this issue (with a DISPUTED tag). [15/n]

    Show this thread
    Undo
  8. Jan 23

    [Dec 23] me: new fast shiny unit-test and fix [Dec 24] Mr2: I've been out to lunch for a little while. I'll review these series before the end of the year. [Dec 28] me: hello anybody? /* Silence. Happy New Year! No review. LOL!!! */ [14/n]

    Show this thread
    Undo
  9. Jan 23

    [Dec 19] Mr1: No, your unit-test is slow. Make it faster. me: okay, I'll do that... /* More work done. Rrrrr! It must be finished! */ [13/n]

    Show this thread
    Undo
  10. Jan 23

    [Nov 27] me: okay, it looks like I can do that /* More work done. I developed a new IDE fix and a shiny unit-test that also found an extra DMA emulation bug */ [Dec 16] me: sent the patch series [12/n]

    Show this thread
    Undo
  11. Jan 23

    [Nov 7] me: huh, yes, I will take this task and return with a patch. /* Grr. Challenge accepted! A week of development. */ [Nov 14] me: new patch fixing IDE [Nov 21] Mr1: we have unit tests. First you improve them to cover all cases. Do according the IDE specification. [11/n]

    Show this thread
    Undo
  12. Jan 23

    [Nov 6] me: I'm pointing politely to this issue again. It crashes qemu during syzkaller fuzzing. Why don't you apply my commit and then do the refactoring later when you want? [Nov 7] somebody in ML: do you want to rework the code yourself? [10/n]

    Show this thread
    Undo
  13. Jan 23

    [Jul 26] Mr2: oh, this is fun. Not gonna take your fix. Whole code should be overwritten. I can worry about a proper fix for QEMU 4.2+. [Jul 27] me: hum, okay... Feel free to add me to CC, I can review the patches and test them with fuzzing! /* 3.5 months passed... */ [9/n]

    Show this thread
    Undo
  14. Jan 23

    [Jul 15] me: public friendly ping [Jul 16] Mr1: hey Mr2, it's for you! Mr2: I'm aware of the patch. It's on the list to investigate today. /* 10 days passed... Huh? */ [8/n]

    Show this thread
    Undo
  15. Jan 23

    [Jun 20] me: sent PoC and patch to QEMU security team [Jun 26] me: hey, friendly ping! [Jul 05] secteam: Please feel free to send the patch upstream me: no problem, sent PoC and patch to the public ML [7/n]

    Show this thread
    Undo
  16. Jan 23

    It looked like QEMU guest-to-host DoS, so I prepared the fixing patch and decided to send it to QEMU security team. Yes, I'm doing responsible disclosure, folks :-) Then the crawling fun began. [6/n]

    Show this thread
    Undo
  17. Jan 23

    One misty morning I logged into my fuzzing machine wondering why syzkaller hadn't given any useful results for several weeks. I've found QEMU crashed. Wow, syzkaller learned how to destroy its own environment :-/ [5/n]

    Show this thread
    Undo
  18. Jan 23

    This bug couldn't read or write (what a pity!). It only asserted that the size of successful DMA transfers handled in ide_dma_cb() should be multiple of 512 (the size of a sector). ... 4 years later... [4/n]

    Show this thread
    Undo
  19. Jan 23

    This bug was born in July 2015, in a lovely QEMU file called hw/ide/core.c. It was not very serious or critical like others. So you would not be very frustrated if you meet it on the way. I will not speak about its father. Let me keep the intrigue till the end. [3/n]

    Show this thread
    Undo
  20. Jan 23

    _Disclaimer_ That is not for trolling, that is for LOL. So here I omit the names of QEMU maintainers that were involved in these adventures. I will call them Mr1 and Mr2. Have fun! [2/n]

    Show this thread
    Undo
  21. Jan 23

    ========================= The Life and Incredible Adventures of One QEMU Bug (Which I Finally Fixed) ========================= A thread [1/n]

    Show this thread
    Undo

Loading seems to be taking a while.

Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.

    You may also like

    ·