News for hackers. Stuff that matters.
Re:Epoll vs. Io_uring in Linux by Asmod4n on Sunday June 21, 2026 @04:25PM (#48622288)
Then just disable that singular function which causes the issue instead of a whole kernel subsystem. The current release can do that.
Re:Epoll vs. Io_uring in Linux by mort96 on Sunday June 21, 2026 @04:31PM (#48622336)
What's the singular function that has a chance of turning out to be exploitable in the future?
Re:Epoll vs. Io_uring in Linux by Asmod4n on Monday June 22, 2026 @06:00AM (#48628079)
With seccomp you can disable a single syscall which might be exploitable since you didn’t get around to patch your kernel, with cBPF you can now do the same for io_uring
Re:Epoll vs. Io_uring in Linux by mort96 on Monday June 22, 2026 @06:03AM (#48628110)
And which single syscall might be exploitable? I don't wanna wait until after an exploit to disable it
Re:Epoll vs. Io_uring in Linux by Asmod4n on Monday June 22, 2026 @07:50AM (#48628911)
Nothing stops you from disabling everything you don’t need and now io_uring offers that per OP too.
Re:Epoll vs. Io_uring in Linux by mort96 on Monday June 22, 2026 @08:05AM (#48629028)
Yes, but what parts of io_uring are safe to not disable?
Re:Epoll vs. Io_uring in Linux by Asmod4n on Monday June 22, 2026 @08:21AM (#48629200)
I don’t get what you mean, in the past it was all or nothing, now you can disable every single operation selectively.

Gotta read the usual sources to find out what you gotta disable on your machines, like you have to for every single syscall since forever.

Re:Epoll vs. Io_uring in Linux by mort96 on Monday June 22, 2026 @09:19AM (#48629748)
I mean exactly what I said. How do I know which parts of io_uring won't have security vulnerabilities discovered in the future?