On Thu, Feb 14, 2019 at 12:20:27PM -0800, Andrew Morton wrote:
On Thu, 14 Feb 2019 09:56:46 -0800 Linus Torvalds torvalds@linux-foundation.org wrote:
On Wed, Feb 13, 2019 at 3:37 PM Richard Weinberger richard.weinberger@gmail.com wrote:
Your shebang line exceeds BINPRM_BUF_SIZE. Before the said commit the kernel silently truncated the shebang line (and corrupted it), now it tells the user that the line is too long.
It doesn't matter if it "corrupted" things by truncating it. All that matters is "it used to work, now it doesn't"
Yes, maybe it never *should* have worked. And yes, it's sad that people apparently had cases that depended on this odd behavior, but there we are.
I see that Kees has a patch to fix it up.
Greg, I think we have a problem here.
8099b047ecc431518 ("exec: load_script: don't blindly truncate shebang string") wasn't marked for backporting. And, presumably as a consequence, Kees's fix "exec: load_script: allow interpreter argument truncation" was not marked for backporting.
8099b047ecc431518 hasn't even appeared in a Linus released kernel, yet it is now present in 4.9.x, 4.14.x, 4.19.x and 4.20.x.
It came in 5.0-rc1, so it fits the "in a Linus released kernel" requirement. If we are to wait until it shows up in a -final, that would be months too late for almost all of these types of patches that are picked up.
I don't know if Oleg considered backporting that patch. I certainly did (I always do), and I decided against doing so. Yet there it is.
This came in through Sasha's tools, which give people a week or so to say "hey, this isn't a stable patch!" and it seems everyone ignored that :(
Where is Kees's fix? I'll be glad to queue it up, or just revert the above commit, which ever people think is easiest.
thanks,
greg k-h