Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sun, 8 Jan 2023 13:45:09 +0000
From: "(GalaxyMaster)" <galaxy@...nwall.com.au>
To: musl@...ts.openwall.com
Subject: is fnmatch() a bit broken?

Hello,

I haven't analysed the fnmatch.c in musl yet, but I wrote a quick test to
demonstrate the issue:
===
#include <fnmatch.h>
#include <stdio.h>

#define TEST_FNMATCH(pattern, haystack, expect) \
        ({ \
                printf("fnmatch(\"%s\", \"%s\", 0) = %d (expected: %d)\n", \
                                pattern, haystack, \
                                fnmatch(pattern, haystack, 0), expect); \
        })

int main()
{
        TEST_FNMATCH("abc", "abc", 0);
        TEST_FNMATCH("[1\\]] [1\\]]", "1 ]", 0);
        TEST_FNMATCH("[a-c-f] [a-c-f] [a-c-f] [a-c-f] [a-c-f]", "a b c - f", 0);
        TEST_FNMATCH("[a-c-f]", "e", 1);
        TEST_FNMATCH("[a\\-z]", "b", 1);
        return 0;
}
===

Below is a session on a box with musl 1.2.3:
===
galaxy@...llo:~/musl-fnmatch $ gcc -o musl-fnmatch musl-fnmatch.c
galaxy@...llo:~/musl-fnmatch $ ./musl-fnmatch
fnmatch("abc", "abc", 0) = 0 (expected: 0)
fnmatch("[1\]] [1\]]", "1 ]", 0) = 1 (expected: 0)
fnmatch("[a-c-f] [a-c-f] [a-c-f] [a-c-f] [a-c-f]", "a b c - f", 0) = 1 (expected: 0)
fnmatch("[a-c-f]", "e", 0) = 0 (expected: 1)
fnmatch("[a\-z]", "b", 0) = 0 (expected: 1)
galaxy@...llo:~/musl-fnmatch $ ldd ./musl-fnmatch
	/lib/ld-musl-x86_64.so.1 (0x7f25af652000)
	libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f25af652000)
galaxy@...llo:~/musl-fnmatch $ rpm -q musl
musl-1.2.3-owl0.x86_64
galaxy@...llo:~/musl-fnmatch $
===

As you may see from above the patterns are not that crazy (they were actually
taken from the systemd test case, since I am trying to build the latest systemd
with musl correctly, but this is offtopic).  The most concerning are the last
three patterns, since obviously musl's fnmatch() seems to be greedy and also
does not respect escape character in some cases, e.g. in "[a\-z]" it is common
sense to treat it as 'a', '-', or 'z'.

A test on a glibc system has no issues:
===
[galaxy@...llo musl-fnmatch]$ gcc -o glibc-fnmatch musl-fnmatch.c
[galaxy@...llo musl-fnmatch]$ ./glibc-fnmatch
fnmatch("abc", "abc", 0) = 0 (expected: 0)
fnmatch("[1\]] [1\]]", "1 ]", 0) = 0 (expected: 0)
fnmatch("[a-c-f] [a-c-f] [a-c-f] [a-c-f] [a-c-f]", "a b c - f", 0) = 0 (expected: 0)
fnmatch("[a-c-f]", "e", 0) = 1 (expected: 1)
fnmatch("[a\-z]", "b", 0) = 1 (expected: 1)
[galaxy@...llo musl-fnmatch]$ ldd glibc-fnmatch
	linux-vdso.so.1 (0x00007ffc301c4000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f44bf93a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f44bfb5c000)
[galaxy@...llo musl-fnmatch]$ rpm -q glibc
glibc-2.35.0.6.491f2e-alt2.x86_64
[galaxy@...llo musl-fnmatch]$
===

Am I missing something or os this behaviour is not expected?

-- 
(GM)

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.