Bug #2383
closedwindows - calling FreeEnvironmentStrings on envarea invalidates memory in use
Description
=begin
In win32.c, in rb_w32_getenv, the code calls FreeEnvironmentStrings(envarea). By doing this, it invalidates memory that's currently in use.
see env_fetch in hash.c:
...
env = getenv(nam);
...
if (ENVMATCH(nam, PATH_ENV) && !rb_env_path_tainted())
return rb_str_new2(env);
and in rb_env_path_tainted:
if (path_tainted < 0) {
path_tainted_p(getenv(PATH_ENV));
}
the getenv call in rb_env_path_tainted frees envarea, but there's still an outstanding reference to memory in envarea: env, from env_fetch. Then we try to create a new string from env and dereference freed memory.
The repro is very simple:
print "#{ENV["path"]}\n"
run this under the debugger with pageheap on.
=end
Updated by ujihisa (Tatsuhiro Ujihisa) over 14 years ago
- Status changed from Open to Assigned
- Assignee set to usa (Usaku NAKAMURA)
=begin
=end
Updated by usa (Usaku NAKAMURA) over 14 years ago
- Status changed from Assigned to Open
- Assignee deleted (
usa (Usaku NAKAMURA))
=begin
See the definition of getenv in posix.
This is not a problem of Windows but a bug of the main body of ruby in clearness.
=end
Updated by jeremyevans0 (Jeremy Evans) over 4 years ago
- Description updated (diff)
- Status changed from Open to Rejected