Bug 1038676

Summary: execve does not return E2BIG for long parameters (broken Ruby test suite)
Product: [Fedora] Fedora Reporter: Vít Ondruch <vondruch>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: falonso, gansalmon, itamar, jcapik, jonathan, kernel-maint, kmcmartin, madhu.chinakonda
Target Milestone: ---Keywords: SecurityTracking
Target Release: ---   
Hardware: aarch64   
OS: Unspecified   
Whiteboard: fst_owner=falonsoe
Fixed In Version: Doc Type: Release Note
Doc Text:
Story Points: ---
Clone Of:
: 1052186 (view as bug list) Environment:
Last Closed: 2015-03-25 12:31:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1052186    
Attachments:
Description Flags
long-param.tgz
none
long-param.tgz none

Description Vít Ondruch 2013-12-05 15:43:16 UTC 
Trying to build Ruby on AArch64, the test_aspawn_too_long_path [1] fails. It tries to execute shell with long command. On my system, when the command exceeds 32 * PAGE_SIZE, i.e. 128kB, E2BIG error is reported as expected. On AArch64, this error is never raised. During my testing, I was able to get ENOMEM instead.

I was trying to debug the issue. The last call in Ruby is call to execl [2] kernel function, which subsequently calls execve. I suspect that the MAX_ARG_STRLEN is not applied for some reason, although I was not able to identify why.

Any help is appreciated.


[1] https://github.com/ruby/ruby/blob/trunk/test/ruby/test_process.rb#L1391
[2] https://github.com/ruby/ruby/blob/trunk/process.c#L1312
Comment 1 Jaromír Cápík 2014-01-13 15:41:36 UTC 
I just tried to reproduce the issue and it seems it doesn't matter what the agrument length is .... the execve command simply doesn't work even when short arguments are passed.
Comment 2 Jaromír Cápík 2014-01-13 16:06:25 UTC 
Sorry for confusion .... it seem we were both wrong.
We didn't call the execve command correctly in our reproducer. 
I fixed the reproducer and the ENOENT disappeared. Anyway it's still buggy.

Instead of returning E2BIG, the first argument argv[1] is truncated to 131072 bytes (=128kB) and concatenated with argv[0] so that the length is 131072 + strlen(argv[0]).

Strange, isn't it.
Comment 3 Jaromír Cápík 2014-01-13 16:40:17 UTC 
Even funnier the behaviour is when trying that with 2 arguments ... I'm going to attach the results ...
Comment 4 Jaromír Cápík 2014-01-13 16:40:53 UTC 
Created attachment 849480 [details]
long-param.tgz

This attachment contains a reproducer written in C. Just adjust the SIZE definition in 'long-param-test.c', type 'make' and then redirect output of the 'long-param-test' tool to a text file.
Comment 5 Jaromír Cápík 2014-01-13 16:54:02 UTC 
Created attachment 849495 [details]
long-param.tgz

... sorry ... ignore the previous attachment ... here's the right one ...
Comment 6 Jaromír Cápík 2014-01-13 18:13:25 UTC 
The arguments are correctly passed to the 
INLINE_SYSCALL (execve, 3, file, argv, envp);
Comment 7 Jaromír Cápík 2014-01-13 18:40:33 UTC 
Even the following glibc call is still ok ...
INTERNAL_SYSCALL_RAW(11, , 3, "myecho", newargv, newenviron);
Comment 8 Kyle McMartin 2014-01-22 22:31:34 UTC 
I believe all the koji builders have now been updated to fix this.
Comment 9 Vít Ondruch 2014-02-08 15:25:30 UTC 
Kyle, thanks for looking into this.


Jaromír, could you please check this, so we can resolve this issue? Thanks
Comment 10 Jaromír Cápík 2014-09-09 18:01:31 UTC 
The testing application now correctly accepts up to 1015796 characters per argument.
Longer arguments are rejected with errno=7 (Argument list too long).
The error message is a bit misleading, but the behaviour is ok now.

Tested with : kernel-3.16.0-0.42.sa2.aarch64
Comment 11 Jaroslav Reznik 2015-03-03 15:18:28 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22