[PATCH v3] intl: Restrict path traversal when using LANGUAGE env var [BZ #17142, CVE-2026-84243]

[Avinal Kumar]

On Tue, Sep 1, 2026 at 7:31 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Avinal Kumar:
>
> > diff --git a/intl/dcigettext.c b/intl/dcigettext.c
> > index 43b99c2dea..e9611dae7a 100644
> > --- a/intl/dcigettext.c
> > +++ b/intl/dcigettext.c
> > @@ -591,10 +591,10 @@ DCIGETTEXT (const char *domainname, const char *msgid1, const char *msgid2,
> >           *cp++ = *categoryvalue++;
> >         *cp = '\0';
> >
> > -       /* When this is a SUID binary we must not allow accessing files
> > -          outside the dedicated directories.  */
> > -       if (ENABLE_SECURE && IS_PATH_WITH_DIR (single_locale))
> > -         /* Ignore this entry.  */
> > +       /* Do not allow accessing files outside the dedicated
> > +          directories.  */
> > +       if (IS_PATH_WITH_DIR (single_locale)
> > +           || strcmp (single_locale, "..") == 0)
> >           continue;
> >       }
> >
>
> Is there an impact on SUID binaries because ".." was not skipped before?
>
> Thanks,
> Florian
>
Now that I think, yes, there may be some impact. IS_PATH_WITH_DIR
checks for '/' but a bare '..' has no slash, so it was never caught,
not even for SUID binaries where ENABLE_SECURE is true.

But any practical impact should be limited by the fact that
LANGUAGE=.. is just one level up, that path is generally not writable
by normal users. So it will reduces the possibility that a malicious
file could be there.