GeezerVison is showing github.com — Avoid using unsafe `realpath` · Issue #42400 · python/cpython
Avoid using unsafe realpath #42400Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2005-09-22.14:54:06.000>
labels = ['type-security', 'interpreter-core']
title = 'sysmodule.c: realpath() is unsafe'
updated_at = <Date 2016-09-08.23:49:28.131>
user = 'https://bugs.python.org/misa' bugs.python.org fields:
activity = <Date 2016-09-08.23:49:28.131>
actor = 'christian.heimes'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2005-09-22.14:54:06.000>
creator = 'misa'
dependencies = []
files = ['6791']
hgrepos = []
issue_num = 1298813
keywords = ['patch']
message_count = 13.0
messages = ['48753', '48754', '48755', '48756', '48757', '86585', '87090', '87446', '114627', '142586', '142664', '142927', '275217']
nosy_count = 10.0
nosy_names = ['misa', 'spektrum', 'pitrou', 'vstinner', 'christian.heimes', 'ajaksu2', 'pjones', 'matejcik', 'Arfrever', 'mibanescu']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'pending'
superseder = None
type = 'security'
url = 'https://bugs.python.org/issue1298813'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3', 'Python 3.4'] Linked PRs
Activitymisa commented on Sep 22, 2005 MannequinAuthor More actions realpath() will dereference all symlinks and resolve
references to /./ and /../ (and so on). realpath
accepts a source buffer and a destination buffer to
copy the resolved path into. On certain systems
PATH_MAX can be of arbitrary size, while the buffer
passed in would be of a limiited size.
There is no way to specify how long your "resolved"
buffer is, therefore it is possible for one to overflow it.
According to the man page:
BUGS
Never use this function. It is broken by design since it is impossible
to determine a suitable size for the output buffer. According to POSIX
a buffer of size PATH_MAX suffices, but PATH_MAX need not be a defined
constant, and may have to be obtained using pathconf(). And asking
pathconf() does not really help, since on the one hand POSIX warns that
the result of pathconf() may be huge and unsuitable for mallocing mem-
ory. And on the other hand pathconf() may return -1 to signify that
PATH_MAX is not bounded.
glibc has certain extensions to avoid the buffer
overflow. One option is to use
canonicalize_file_name(), another is to specify a NULL
as the second argument to realpath() (which essentially
makes it behave like canonicalize_file_name(). Relevant
documentation:
info libc
http://www.delorie.com/gnu/docs/glibc/libc_279.html
Attached is a patch to use canonicalize_file_name if
available. spektrum commented on Sep 26, 2005 Logged In: YES
user_id=631694
there are two bugs in the patch: one is explained on
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169046
the other one is that with this patch, the value of n
(length to be copied) stays zero all the time, so no copy
occurs and various things happen.
i have a patch, but don't know how to attach it - should i
mail it to you? pjones commented on Sep 26, 2005 Logged In: YES
user_id=27350
There are actually a few more, very subtle problems with the
new patch as well. I'll get misa to update a patch once
I've worked through them.
In general, regarding Red Hat's bz# 169046, there's no
reason to do readlink() or realpath() if you've got
canonicalize_file_name; it should provide both sets of
functionality just fine. pjones commented on Sep 26, 2005 Logged In: YES
user_id=27350
... but I see you meant the condition different than I
parsed your explanation. Anyway, I'll get misa to upload a
new patch once I've figured out what's going wrong entirely. spektrum commented on Sep 1, 2006 devdanzin commented on Apr 26, 2009 vstinner commented on May 4, 2009 The patch introduces a memory leak, canonicalize_file_name() returns a
new allocated string which is not freed later. mibanescu commented on May 8, 2009 Disclaimer: this bug is more than 3 years old, I don't remember all the
details.
Victor, solely reading the patch I see:
+#ifdef HAVE_CANONICALIZE_FILE_NAME
+ free(argv0);
+#endif /* HAVE_CANONICALIZE_FILE_NAME */ so argv0 (the string where the results of canonicalize_file_name() is
stored) should be freed.
Is there another branch that does not hit this code, that would create
the memory leak? BreamoreBoy commented on Aug 22, 2010 Surely this security issue should be addressed? pitrou commented on Aug 20, 2011 The latest POSIX versions (*) allow NULL to be passed for the target memory area, meaning that realpath() will allocate as much memory as necessary by itself. This essentially does the same thing as canonicalize_file_name(), but in a standard way rather than by relying on a GNU extension.
I suppose that possibility could be checked at configure time.
(*) http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html mibanescu commented on Aug 22, 2011 It's a real shame the original patch was not applied before py3k was branched, the code is now different.
Antoine, my autoconf knowledge is limited, I don't know how you'd test for realpath accepting a NULL argument (and doing the right thing) at compile time.
My involvement with this bug is fairly limited at this point, I would like to see it fixed, but having seen no movement on it for almost 6 years now, maybe it's not as critical as I thought it was. JelleZijlstra commented on Oct 5, 2022 We do still use realpath(3), now inside the _Py_wrealpath function in fileutils.c, so I think the original issue still applies. changed the title [-]sysmodule.c: realpath() is unsafe[/-] [+]Avoid using unsafe `realpath`[/+] on May 20, 2025ashm-dev commented on Nov 13, 2025 Ping. Is this issue still relevant? vstinner commented on Nov 13, 2025 _Py_wrealpath() calls realpath().
getpath_realpath() in Modules/getpath.c (if HAVE_READLINK macro is not defined) and _PyPathConfig_ComputeSysPath0() in Python/pathconfig.c still call _Py_wrealpath().
So yeah, this issue is still relevant.
By the way, "Ping. Is this issue still relevant?" doesn't bring much value to the issue. You should investigate by yourself to check if an issue is still relevant. Reacted by Jelle Zijlstra and Shamil ashm-dev commented on Nov 13, 2025
By the way, "Ping. Is this issue still relevant?" doesn't bring much value to the issue. You should investigate by yourself to check if an issue is still relevant.
Thanks for the note. I’ll avoid noise in the future and only comment when I have something concrete.
I checked the current main branch, and the issue is still present. I’m preparing a PR with a fix. Reacted by Victor Stinner added a commit that references this issue on Nov 18, 2025gh-42400: Fix buffer overflow in _Py_wrealpath() for very long paths (#…
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|