Direct-leak in execvpe |
|||||
Issue descriptionDetailed report: https://cluster-fuzz.appspot.com/testcase?key=6396955840479232 Fuzzer: v8_builtins_generator Job Type: linux_asan_d8 Platform Id: linux Crash Type: Direct-leak Crash Address: Crash State: execvpe v8::ExecSubprocess v8::Shell::System Minimized Testcase (0.07 Kb): Download: https://cluster-fuzz.appspot.com/download/AMIfv96JfgbaajxRUtW6KG8icz07m9HgfKnu1Nh2u7BjFP6Xe5ja7vYWMpNjhuIOzON5KsQcPf4L7Y7veNUsLhurGjkZwPzi0gR5_dfbWIkNwf1zwdCdMbKqHVMw4K85aaaoAw4ZgCBVASB1Kmn9xF8vuJ9TadTGIQ var v4 = new Array(); v4[0x80000] = 1; var v33 = os.system(v4); Filer: tjbecker See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.
,
Jun 8 2016
Detailed report: https://cluster-fuzz.appspot.com/testcase?key=4580506931036160 Fuzzer: v8_builtins_generator Job Type: linux_asan_d8_v8_arm64_dbg Platform Id: linux Crash Type: Direct-leak Crash Address: Crash State: execvpe v8::Shell::System v8::internal::FunctionCallbackArguments::Call Minimized Testcase (0.07 Kb): Download: https://cluster-fuzz.appspot.com/download/AMIfv94jIXN23_oBZLvrv6wi409pRvS--hOoIjOfVU3gh0urXVe0RqgfDQU8ep_Hh9fV5wRrslR5p3EXRZDP5jv7brsUwjzlTcD6U-WDxCuO6RX-wG4hqH0Z52ILyttmY99NkXSRQhN8yK2tH3varjvZ0kVwAj21LA var v9 = new Array(); v9[0x80000] = 1; var v29 = os.system(v9); Filer: ishell See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.
,
Jun 8 2016
Good question. My first guess is that we don't care all too much because these functions (e.g. the {os.*} family) is only provided by d8 (our debugging shell) and not exposed via Chrome or any other embedder.
danno@, yangguo@: WDYT?
,
Jun 8 2016
d8 is not shipped in production, and is only used for testing. Let's blacklist os.*.
,
Jun 8 2016
This particular issue could be a sanitizer issue. As far as I understand it should handle calls to "exec" is a special way.
,
Jun 8 2016
(+kcc, eugenis FYI) This looks like a eglibc bug. See https://ghostbin.com/paste/xcvfh for the up-to-date posix/execvpe.c source from eglibc-2.19 (taken from Ubuntu Trusty) At line 110 (https://ghostbin.com/paste/xcvfh#L110) execvpe() allocates memory for the path and then calls __execve(). If both calls to __execve() fail with ENAMETOOLONG, we return -1 from the switch statement without freeing the memory. IIUC the problem is already fixed in glibc (https://github.molgen.mpg.de/git-mirror/glibc/commit/1eb8930608705702d5746e5491bab4e4429fcb83), but not in eglibc.
,
Jun 20 2016
Marking as WontFix according to #4 and #6.
,
Nov 22 2016
Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by tjbecker@google.com
, Jun 7 2016