11:31 a.m.
Hello,
the function path_norm() from libauparse.so in audit-4.1.1 still reads one
byte below the allocated "working" buffer and triggers AddressSanitizer and
valgrind reports for inputs like "a/../.." or "a/.././..".
Attached is a test that produces the asan report.
Process paths like these were generated when processing audit syscall
events for clone and probably others.
Most of the read underruns in path_norm() were fixed in 2025 and the issue
mentioned above is apparently the only one remaining in that code.
Would replacing the while loop with the code below ensure that path_norm
does not read below the "working" buffer ?
- while (dest > rpath && (--dest)[-1] != '/');
+ char *slash = (char *)memrchr(rpath, '/', dest - rpath);
+ if (slash)
+ dest = (slash == rpath) ? (rpath + 1) : slash;
+ else
+ dest = rpath;
Regards,
Bogdan Harjoc
5:14 p.m.
New subject: ASAN still reports a one-byte read underrun in path_norm() from
libauparse
Hello,
On Thursday, August 7, 2025 12:31:24 PM Eastern Daylight Time Bogdan Harjoc
wrote:
the function path_norm() from libauparse.so in audit-4.1.1 still
reads one
byte below the allocated "working" buffer and triggers AddressSanitizer and
valgrind reports for inputs like "a/../.." or "a/.././..".
Attached is a test that produces the asan report.
Thanks. I added something like that to the auparse self tests.
Process paths like these were generated when processing audit
syscall
events for clone and probably others.
Most of the read underruns in path_norm() were fixed in 2025 and the issue
mentioned above is apparently the only one remaining in that code.
Would replacing the while loop with the code below ensure that path_norm
does not read below the "working" buffer ?
- while (dest > rpath && (--dest)[-1] != '/');
+ char *slash = (char *)memrchr(rpath, '/', dest - rpath);
+ if (slash)
+ dest = (slash == rpath) ? (rpath + 1) : slash;
+ else
+ dest = rpath;
The fix is simple, see commit 4f01ca0. I want to keep this mostly "as is"
since it mirrors code from glibc's realpath.
-Steve
7:52 a.m.
Thanks!
Would it make sense to add a similar fix to the 3.1 branch as well ? On
3.1.x the dest pointer can go below rpath until it reaches a "/" character.
Bogdan
On Fri, Aug 8, 2025 at 1:14 AM Steve Grubb <sgrubb(a)redhat.com> wrote:
Hello,
On Thursday, August 7, 2025 12:31:24 PM Eastern Daylight Time Bogdan
Harjoc
wrote:
> the function path_norm() from libauparse.so in audit-4.1.1 still reads
one
> byte below the allocated "working" buffer and triggers AddressSanitizer
and
> valgrind reports for inputs like "a/../.." or "a/.././..".
>
> Attached is a test that produces the asan report.
Thanks. I added something like that to the auparse self tests.
> Process paths like these were generated when processing audit syscall
> events for clone and probably others.
>
> Most of the read underruns in path_norm() were fixed in 2025 and the
issue
> mentioned above is apparently the only one remaining in that code.
>
> Would replacing the while loop with the code below ensure that path_norm
> does not read below the "working" buffer ?
>
> - while (dest > rpath && (--dest)[-1] != '/');
>
> + char *slash = (char *)memrchr(rpath, '/', dest - rpath);
> + if (slash)
> + dest = (slash == rpath) ? (rpath + 1) : slash;
> + else
> + dest = rpath;
The fix is simple, see commit 4f01ca0. I want to keep this mostly "as is"
since it mirrors code from glibc's realpath.
-Steve
10 a.m.
New subject: ASAN still reports a one-byte read underrun in path_norm() from
libauparse
Hello,
On Tuesday, August 12, 2025 8:52:06 AM Eastern Daylight Time Bogdan Harjoc
wrote:
Would it make sense to add a similar fix to the 3.1 branch as well ?
On
3.1.x the dest pointer can go below rpath until it reaches a "/" character.
March a year ago I made an announcement for the 3.1.3 release here:
https://lists.linux-audit.osci.io/archives/list/linux-audit@lists.linux-a...
It announced that this was the end of the 3.X series. The main reason is that
release was a collection of cherry picked patches that had no OS on which to
see if the combination of patches even work. Fedora had long since migrated
to the 4.x series, so I had no platform to test on.
To sum it up, audit 3.X is not maintained via github. It is up to
distributions that still carry it to decide what patches from the 4.x branch
they would like to backport.
-Steve
On Fri, Aug 8, 2025 at 1:14 AM Steve Grubb <sgrubb(a)redhat.com>
wrote:
> Hello,
>
> On Thursday, August 7, 2025 12:31:24 PM Eastern Daylight Time Bogdan
> Harjoc
>
> wrote:
> > the function path_norm() from libauparse.so in audit-4.1.1 still reads
>
> one
>
> > byte below the allocated "working" buffer and triggers
AddressSanitizer
>
> and
>
> > valgrind reports for inputs like "a/../.." or "a/.././..".
> >
> > Attached is a test that produces the asan report.
>
> Thanks. I added something like that to the auparse self tests.
>
> > Process paths like these were generated when processing audit syscall
> > events for clone and probably others.
> >
> > Most of the read underruns in path_norm() were fixed in 2025 and the
>
> issue
>
> > mentioned above is apparently the only one remaining in that code.
> >
> > Would replacing the while loop with the code below ensure that
> > path_norm
> > does not read below the "working" buffer ?
> >
> > - while (dest > rpath && (--dest)[-1] != '/');
> >
> > + char *slash = (char *)memrchr(rpath, '/', dest - rpath);
> > + if (slash)
> > + dest = (slash == rpath) ? (rpath + 1) : slash;
> > + else
> > + dest = rpath;
>
> The fix is simple, see commit 4f01ca0. I want to keep this mostly "as is"
> since it mirrors code from glibc's realpath.
>
> -Steve
277
days inactive
282
days old
linux-audit@lists.linux-audit.osci.io
3 comments
2 participants
participants (2)
-
Bogdan Harjoc -
Steve Grubb