![]() (The same pattern also appears for files as an optimization in _fdget_pos(), see this LKML thread. If they are equal, it assumes that the UNIX domain sockets subsystem effectively has exclusive access to the file because it owns all references. In the UNIX domain socket garbage collection code (which is needed to deal with reference loops formed by UNIX domain sockets that use SCM_RIGHTS file descriptor passing), the kernel tries to figure out whether it can account for all references to some file by comparing the file's refcount with the number of references from inflight SKBs (socket buffers). This also demonstrates that even very small race conditions can still be exploitable if someone sinks enough time into writing an exploit, so be careful if you dismiss very small race windows as unexploitable or don't treat such issues as security bugs. I didn't do a full exploit though, I stopped at getting evidence of use-after-free (UAF) accesses (with the help of a very large file descriptor table and userfaultfd, which might not be available to normal users depending on system configuration) because that's the part I was curious about. This is a writeup of how I managed to hit the race on a normal Linux desktop kernel, with a hit rate somewhere around 30% if the proof of concept has been tuned for the specific machine. (While trying to explain to someone how the fix for CVE-2021-0920 worked - I was explaining why the Unix GC is now safe, and then got confused because I couldn't actually figure out why it's safe after that fix, eventually realizing that it actually isn't safe.) It's a fairly narrow race window, so I was wondering whether it could be hit with a small number of attempts - especially on kernels that aren't built with CONFIG_PREEMPT, which would make it possible to preempt a thread with another thread, as I described at LSSEU2019. I recently discovered a race condition ( ) in the Linux kernel. On the other hand, it also means you now have to deal with how hardware timers actually work, which introduces its own flavors of weird timing variations. Racing one thread against a timer also avoids accumulating timing variations from two threads in each race attempt - hence the title. make sure that the wakeup triggered by the timerfd has to churn through 50000 waitqueue items created by epoll.make a timerfd expire in that window (which will run in an interrupt handler - in other words, in hardirq context).use a cache miss to widen the race window a little bit.How to make a tiny kernel race window really large even on kernels without CONFIG_PREEMPT :
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |