splice() should maybe generally refuse to operate on things you can't write to.

splice is documented to return EBADF if "One or both file descriptors are not valid, or do not have proper read-write mode."

So it seems surprising to me that you can call it when the out fd is not writable? But I didn't retain the information about the vulnerability, so I'm missing something. There was something about copy on write, IIRC?

▲

eqvinox an hour ago | parent [-]

"proper read-write mode" for the input fd is reading only. The exploit is writing to the splice() input fd.

Also, NB, I said permission check, not mode check. The input fd to splice can and will be open for only reading quite often. Doesn't mean the kernel can't still do a write permission check.

(Except I didn't say that here. Oops. Getting confused with my posts.)

▲

toast0 an hour ago | parent [-]

OK, I may likely have too much sleep debt to understand, but given the bug is that splice can write to the input fd, you're suggesting maybe splice should only let you use an input fd if the process has access to write to it?

But splice is a more or less a generalization of sendfile, and sendfile is often used for webserving where the serving process does not have ownership of the documents it is serving. It doesn't make sense to limit splice such that it can't do the task it was built for. Maybe splice should just not write to the input fd? :P

	▲	eqvinox 10 minutes ago \| parent \| next [-]
		Yes, it'd curtail splice() usage quite heavily. Maybe too much. But apparently we can't be trusted with the page cache… Maybe the kernel using supervisor-read-only flags could be made to work, only issue then is what happens if something does in fact need to write…
	▲	semiquaver 36 minutes ago \| parent \| prev [-]
		Aren’t you just saying “don’t write bugs?”