From: Richard Palethorpe <rpalethorpe@suse.de>
To: Petr Vorel <pvorel@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 0/3] safe_macros: Fix undefined behaviour in vararg handling
Date: Tue, 29 Nov 2022 11:11:24 +0000 [thread overview]
Message-ID: <87mt8at3md.fsf@suse.de> (raw)
In-Reply-To: <Y4Xnt+OsEt94aZRr@pevik>
Hello,
Petr Vorel <pvorel@suse.cz> writes:
>> Hi Tudor,
>
>> > Accessing elements in an empty va_list results in undefined behaviour[0]
>> > that can include accessing arbitrary stack memory. While typically this
>> > doesn't raise a fault, some new more security-oriented architectures
>> > (e.g. CHERI[1] or Morello[2]) don't allow it.
>
>> > Therefore, remove the variadicness from safe_* wrappers that always call
>> > the functions with the optional argument included.
>
>> > Adapt the respective SAFE_* macros to handle the change by passing a
>> > default argument if they're omitted.
>
>> Thanks for an interesting patchset!
>
>> I wonder if it's a correct approach as C API allows
Perhaps, muslc does the following for open()
if ((flags & O_CREAT) || (flags & O_TMPFILE) == O_TMPFILE) {
va_list ap;
va_start(ap, flags);
mode = va_arg(ap, mode_t);
va_end(ap);
}
So it's only accessed if we need the mode. If the error below can be
fixed with the current approach I'd also be happy.
>> int open(const char *pathname, int flags);
>> we will replace it
>> int open(const char *pathname, int flags, mode_t mode);
>> where mode is 0.
>> But as it's only in safe_* it should be ok.
>> We still have some open() tests without mode, i.e.
>> testcases/kernel/syscalls/open/open06.c
>
>> Unfortunately some tests need to be adjusted, at least all tests in
>> testcases/kernel/syscalls/fgetxattr will fail due int-conversion,
>> as they use NULL as the third parameter:
>
>> $ export CFLAGS="-Werror=conversion"
>> $ ./configure
>> $ cd testcases/kernel/syscalls/fgetxattr
>> $ make clean
>> $ make V=1
>> gcc -I../../../../include -I../../../../include -I../../../../include/old/ -Werror=int-conversion -g -O2 -fno-strict-aliasing -pipe -Wall -W -Wold-style-definition -std=gnu99 -L../../../../lib fgetxattr01.c -lltp -o fgetxattr01
>> In file included from ../../../../include/tst_test.h:98,
>> from fgetxattr01.c:34:
>> fgetxattr01.c: In function ‘setup’:
>> ../../../../include/tst_safe_macros.h:90:67: error: passing argument 6 of ‘safe_open’ makes integer from pointer without a cast [-Werror=int-conversion]
>> 90 | safe_open(__FILE__, __LINE__, NULL, (pathname), (oflags), (mode))
>> | ^~~~~~
>
>> | void *
>> ../../../../include/tst_safe_macros.h:93:9: note: in expansion of macro ‘__SAFE_OPEN’
>> 93 | __SAFE_OPEN((pathname), (oflags), ##__VA_ARGS__, 0)
>> | ^~~~~~~~~~~
>> fgetxattr01.c:114:14: note: in expansion of macro ‘SAFE_OPEN’
>> 114 | fd = SAFE_OPEN(FNAME, O_RDONLY, NULL);
>> | ^~~~~~~~~
>> In file included from ../../../../include/tst_safe_macros.h:24:
>> ../../../../include/safe_macros_fn.h:78:22: note: expected ‘mode_t’ {aka ‘unsigned int’} but argument is of type ‘void *’
>> 78 | mode_t mode);
>> | ~~~~~~~^~~~
>> cc1: some warnings being treated as errors
>> make: *** [../../../../include/mk/rules.mk:43: fgetxattr01] Error 1
>
> NOTE: this is from gcc, but obviously also clang has the same problem,
> even without -Werror=int-conversion in CFLAGS, obviously it's the default.
> That's why it was found on Fedora, which we test with clang.
>
> Kind regards,
> Petr
>
>> Found on recent openSUSE Tumbleweed which has 2.36. Also our CI has caught it on
>> Fedora (which also uses 2.36):
>> https://github.com/pevik/ltp/actions/runs/3573215390/jobs/6007016572
>
>> Kind regards,
>> Petr
>
>> > [0]: [ISO/IEC 9899:2011] Programming Languages—C, 3rd ed, paragraph 7.16.1.1
>> > [1]: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
>> > [2]: https://www.morello-project.org/
>
>> > Tudor Cretu (3):
>> > safe_open: Fix undefined behaviour in vararg handling
>> > safe_openat: Fix undefined behaviour in vararg handling
>> > safe_semctl: Fix undefined behaviour in vararg handling
>
>> > include/old/safe_macros.h | 6 ++++--
>> > include/safe_macros_fn.h | 3 ++-
>> > include/tst_safe_file_at.h | 10 ++++++----
>> > include/tst_safe_macros.h | 6 ++++--
>> > include/tst_safe_sysv_ipc.h | 14 +++++++++-----
>> > lib/safe_macros.c | 13 +------------
>> > lib/tst_cgroup.c | 2 +-
>> > lib/tst_safe_file_at.c | 11 +++--------
>> > lib/tst_safe_sysv_ipc.c | 10 +---------
>> > 9 files changed, 31 insertions(+), 44 deletions(-)
--
Thank you,
Richard.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2022-11-29 11:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 14:47 [LTP] [PATCH 0/3] safe_macros: Fix undefined behaviour in vararg handling Tudor Cretu
2022-11-23 14:47 ` [LTP] [PATCH 1/3] safe_open: " Tudor Cretu
2022-11-23 14:47 ` [LTP] [PATCH 2/3] safe_openat: " Tudor Cretu
2022-11-23 14:47 ` [LTP] [PATCH 3/3] safe_semctl: " Tudor Cretu
2022-11-29 11:01 ` [LTP] [PATCH 0/3] safe_macros: " Petr Vorel
2022-11-29 11:06 ` Petr Vorel
2022-11-29 11:11 ` Richard Palethorpe [this message]
2022-11-29 11:27 ` Richard Palethorpe
2022-11-29 11:32 ` Petr Vorel
2022-11-29 11:46 ` Tudor Cretu
2022-11-29 12:01 ` Richard Palethorpe
2022-11-29 11:45 ` Tudor Cretu
2022-11-29 11:48 ` Cyril Hrubis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mt8at3md.fsf@suse.de \
--to=rpalethorpe@suse.de \
--cc=ltp@lists.linux.it \
--cc=pvorel@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.