On Tuesday, 19 May 2020 14:45:20 PDT Al Viro wrote: > ... and here's not getting the things copied. Which means that pointer > is left uninitialized and the damn thing might very well be a security > problem - you'd lucked out and ran into NULL, but had there been a pointer > to something, you would've gotten a memory corruptor. Not sure I'd call it a security issue. Only root (CAP_SYS_RESOURCE) can cause it by raising the file descriptor limit from the defaults. The kernel still defaults to 4096 and systemd raises it on boot to 512k, which is 3 orders of magnitude less than what is needed to cause the issue. > I really wonder about the missing couple of syscalls in your strace, though; > could you verify that they _are_ missing and see what the fix above does to > your testcase? Looking at my terminal backtrace, I might have made a copy & paste mistake of the trace while flipping pages. Unfortunately, the trace file I had in /tmp was lost because I needed to reboot the machine. The other traces I have in my terminal show: fcntl(2, F_DUPFD, 134217728) = 134217728 close(134217728) = 0 fcntl(2, F_DUPFD, 268435456) = 268435456 close(268435456) = 0 fcntl(2, F_DUPFD, 536870912) = 536870912 close(536870912) = 0 write(1, "success\n", 8) = ? ^C^Czsh: killed sudo strace ./dupfd-bug I had to killall -9 strace at this point. See the attached oops. Then I insisted: fcntl(2, F_DUPFD, 67108864) = 67108864 close(67108864) = 0 fcntl(2, F_DUPFD, 134217728) = 134217728 close(134217728) = 0 fcntl(2, F_DUPFD, 268435456Shared connection to closed. At this point, I need to drive to the office to reboot the machine. Building the kernel and testing will take a few days. Note to self: don't play with possible kernel bugs without a VM. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products