[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260901133608.GU23438@brightrain.aerifal.cx>
Date: Tue, 1 Sep 2026 09:36:09 -0400
From: Rich Felker <dalias@...c.org>
To: Ricardo Barreira <rsf@...gle.com>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] ldso: increase buffer size to fix loading error
with long paths
On Tue, Sep 01, 2026 at 11:25:22AM +0000, Ricardo Barreira wrote:
> path_open_library fills this buffer with a path, so it needs to be
> sized accordingly with PATH_MAX+1.
>
> Signed-off-by: Ricardo Barreira <rsf@...gle.com>
> ---
> ldso/dynlink.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ldso/dynlink.c b/ldso/dynlink.c
> index 10471b23..32096f55 100644
> --- a/ldso/dynlink.c
> +++ b/ldso/dynlink.c
> @@ -1056,7 +1056,7 @@ static void makefuncdescs(struct dso *p)
>
> static struct dso *load_library(const char *name, struct dso *needed_by)
> {
> - char buf[2*NAME_MAX+2];
> + char buf[PATH_MAX+1];
> const char *pathname;
> unsigned char *map;
> struct dso *p, temp_dso = {0};
> --
> 2.55.0.897.gb25b4bd76c-goog
Is this an actual issue you are hitting in usage? The current size was
chosen to allow the filename of the library to be up to the full
NAME_MAX, and assuming you would not put prefixes longer than that
(which is already ridiculously large) in your library path.
The intent of not using PATH_MAX is to avoid clobbering a whole extra
page of stack that will never again be used at load-time in every
single dynamic-linked program. But I suppose we could do something
like pre-scan the search path for the longest component, and size a
VLA to fit the longest one, if it's really needed to support longer
path elements.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
