<feed xmlns='http://www.w3.org/2005/Atom'>
<title>glibc/misc, branch master</title>
<subtitle>Fork of glibc for development</subtitle>
<id>https://git.zx2c4.com/glibc/atom/misc?h=master</id>
<link rel='self' href='https://git.zx2c4.com/glibc/atom/misc?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/'/>
<updated>2024-07-01T15:20:30Z</updated>
<entry>
<title>Fix conditionals on mtrace-based tests (bug 31892)</title>
<updated>2024-07-01T15:20:30Z</updated>
<author>
<name>Carlos O'Donell</name>
<email>carlos@redhat.com</email>
</author>
<published>2024-06-19T15:48:05Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=a7fe3e805d2ee128ac5f43b2a24201726d41cc04'/>
<id>urn:sha1:a7fe3e805d2ee128ac5f43b2a24201726d41cc04</id>
<content type='text'>
The conditionals for several mtrace-based tests in catgets, elf, libio,
malloc, misc, nptl, posix, and stdio-common were incorrect leading to
test failures when bootstrapping glibc without perl.

The correct conditional for mtrace-based tests requires three checks:
first checking for run-built-tests, then build-shared, and lastly that
PERL is not equal to "no" (missing perl).
Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</content>
</entry>
<entry>
<title>socket: Use may_alias on sockaddr structs (bug 19622)</title>
<updated>2024-05-18T07:33:19Z</updated>
<author>
<name>Florian Weimer</name>
<email>fweimer@redhat.com</email>
</author>
<published>2024-05-18T07:33:19Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=8d7b6b4cb27d4dec1dd5f7960298c1699275f962'/>
<id>urn:sha1:8d7b6b4cb27d4dec1dd5f7960298c1699275f962</id>
<content type='text'>
This supports common coding patterns.  The GCC C front end before
version 7 rejects the may_alias attribute on a struct definition
if it was not present in a previous forward declaration, so this
attribute can only be conditionally applied.

This implements the spirit of the change in Austin Group issue 1641.

Suggested-by: Marek Polacek &lt;polacek@redhat.com&gt;
Suggested-by: Jakub Jelinek &lt;jakub@redhat.com&gt;
Reviewed-by: Sam James &lt;sam@gentoo.org&gt;
Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</content>
</entry>
<entry>
<title>misc: Add support for Linux uio.h RWF_NOAPPEND flag</title>
<updated>2024-04-04T08:41:27Z</updated>
<author>
<name>Stafford Horne</name>
<email>shorne@gmail.com</email>
</author>
<published>2024-04-03T05:40:37Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=3db9d208dd5f30b12900989c6d2214782b8e2011'/>
<id>urn:sha1:3db9d208dd5f30b12900989c6d2214782b8e2011</id>
<content type='text'>
In Linux 6.9 a new flag is added to allow for Per-io operations to
disable append mode even if a file was opened with the flag O_APPEND.
This is done with the new RWF_NOAPPEND flag.

This caused two test failures as these tests expected the flag 0x00000020
to be unused.  Adding the flag definition now fixes these tests on Linux
6.9 (v6.9-rc1).

  FAIL: misc/tst-preadvwritev2
  FAIL: misc/tst-preadvwritev64v2

This patch adds the flag, adjusts the test and adds details to
documentation.

Link: https://lore.kernel.org/all/20200831153207.GO3265@brightrain.aerifal.cx/
Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</content>
</entry>
<entry>
<title>Always define __USE_TIME_BITS64 when 64 bit time_t is used</title>
<updated>2024-04-02T18:28:36Z</updated>
<author>
<name>Adhemerval Zanella</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2024-01-18T13:18:01Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=a4ed0471d71739928a0d0fa3258b3ff3b158e9b9'/>
<id>urn:sha1:a4ed0471d71739928a0d0fa3258b3ff3b158e9b9</id>
<content type='text'>
It was raised on libc-help [1] that some Linux kernel interfaces expect
the libc to define __USE_TIME_BITS64 to indicate the time_t size for the
kABI.  Different than defined by the initial y2038 design document [2],
the __USE_TIME_BITS64 is only defined for ABIs that support more than
one time_t size (by defining the _TIME_BITS for each module).

The 64 bit time_t redirects are now enabled using a different internal
define (__USE_TIME64_REDIRECTS). There is no expected change in semantic
or code generation.

Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu, and
arm-linux-gnueabi

[1] https://sourceware.org/pipermail/libc-help/2024-January/006557.html
[2] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

Reviewed-by: DJ Delorie &lt;dj@redhat.com&gt;
</content>
</entry>
<entry>
<title>cdefs: Drop access attribute for _FORTIFY_SOURCE=3 (BZ #31383)</title>
<updated>2024-02-28T13:35:10Z</updated>
<author>
<name>Siddhesh Poyarekar</name>
<email>siddhesh@sourceware.org</email>
</author>
<published>2024-02-15T12:40:56Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=bf9688e623262c5fa9f91e4de0e84db45025076f'/>
<id>urn:sha1:bf9688e623262c5fa9f91e4de0e84db45025076f</id>
<content type='text'>
When passed a pointer to a zero-sized struct, the access attribute
without the third argument misleads -Wstringop-overflow diagnostics to
think that a function is writing 1 byte into the zero-sized structs.
The attribute doesn't add that much value in this context, so drop it
completely for _FORTIFY_SOURCE=3.

Resolves: BZ #31383
Signed-off-by: Siddhesh Poyarekar &lt;siddhesh@sourceware.org&gt;
Reviewed-by: Adhemerval Zanella  &lt;adhemerval.zanella@linaro.org&gt;
</content>
</entry>
<entry>
<title>debug: Improve fcntl.h fortify warnings with clang</title>
<updated>2024-02-27T13:52:59Z</updated>
<author>
<name>Adhemerval Zanella</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2024-02-08T18:46:21Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=86889e22db329abac618c6a41f86c84657a15324'/>
<id>urn:sha1:86889e22db329abac618c6a41f86c84657a15324</id>
<content type='text'>
It improves open, open64, openat, and openat64.  The compile and runtime
checks have similar coverage as with GCC.

Checked on aarch64, armhf, x86_64, and i686.
Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
Tested-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</content>
</entry>
<entry>
<title>syslog: Improve fortify with clang</title>
<updated>2024-02-27T13:52:59Z</updated>
<author>
<name>Adhemerval Zanella</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2024-02-08T18:46:19Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=471c3c7a4705f1a1852404959692b0ff2dbb4aaa'/>
<id>urn:sha1:471c3c7a4705f1a1852404959692b0ff2dbb4aaa</id>
<content type='text'>
It improve fortify checks for syslog and vsyslog.  The compile
and runtime hecks have similar coverage as with GCC.

The syslog fortify wrapper calls the va_arg version, since clang does
not support __va_arg_pack.

Checked on aarch64, armhf, x86_64, and i686.
Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
Tested-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</content>
</entry>
<entry>
<title>cdefs.h: Add clang fortify directives</title>
<updated>2024-02-27T13:52:57Z</updated>
<author>
<name>Adhemerval Zanella</name>
<email>adhemerval.zanella@linaro.org</email>
</author>
<published>2024-02-08T18:46:13Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=7a7093615c1b7ac937b1af7b76d0008f8e1ca189'/>
<id>urn:sha1:7a7093615c1b7ac937b1af7b76d0008f8e1ca189</id>
<content type='text'>
For instance, the read wrapper is currently expanded as:

  extern __inline
  __attribute__((__always_inline__))
  __attribute__((__artificial__))
  __attribute__((__warn_unused_result__))
  ssize_t read (int __fd, void *__buf, size_t __nbytes)
  {
     return __glibc_safe_or_unknown_len (__nbytes,
                                         sizeof (char),
                                         __glibc_objsize0 (__buf))
            ? __read_alias (__fd, __buf, __nbytes)
            : __glibc_unsafe_len (__nbytes,
                                  sizeof (char),
                                  __glibc_objsize0 (__buf))
              ? __read_chk_warn (__fd,
                                 __buf,
                                 __nbytes,
                                 __builtin_object_size (__buf, 0))
              : __read_chk (__fd,
                            __buf,
                            __nbytes,
                            __builtin_object_size (__buf, 0));
  }

The wrapper relies on __builtin_object_size call lowers to a constant at
compile-time and many other operations in the wrapper depends on
having a single, known value for parameters.   Because this is
impossible to have for function parameters, the wrapper depends heavily
on inlining to work and While this is an entirely viable approach on
GCC, it is not fully reliable on clang.  This is because by the time llvm
gets to inlining and optimizing, there is a minimal reliable source and
type-level information available (more information on a more deep
explanation on how to fortify wrapper works on clang [1]).

To allow the wrapper to work reliably and with the same functionality as
with GCC, clang requires a different approach:

  * __attribute__((diagnose_if(c, “str”, “warning”))) which is a function
    level attribute; if the compiler can determine that 'c' is true at
    compile-time, it will emit a warning with the text 'str1'.  If it would
    be better to emit an error, the wrapper can use "error" instead of
    "warning".

  * __attribute__((overloadable)) which is also a function-level attribute;
    and it allows C++-style overloading to occur on C functions.

  * __attribute__((pass_object_size(n))) which is a parameter-level
    attribute; and it makes the compiler evaluate
    __builtin_object_size(param, n) at each call site of the function
    that has the parameter, and passes it in as a hidden parameter.

    This attribute has two side-effects that are key to how FORTIFY works:

    1. It can overload solely on pass_object_size (e.g. there are two
       overloads of foo in

         void foo(char * __attribute__((pass_object_size(0))) c);
         void foo(char *);

      (The one with pass_object_size attribute has precende over the
      default one).

    2. A function with at least one pass_object_size parameter can never
       have its address taken (and overload resolution respects this).

Thus the read wrapper can be implemented as follows, without
hindering any fortify coverage compile and runtime:

  extern __inline
  __attribute__((__always_inline__))
  __attribute__((__artificial__))
  __attribute__((__overloadable__))
  __attribute__((__warn_unused_result__))
  ssize_t read (int __fd,
                 void *const __attribute__((pass_object_size (0))) __buf,
                 size_t __nbytes)
     __attribute__((__diagnose_if__ ((((__builtin_object_size (__buf, 0)) != -1ULL
                                        &amp;&amp; (__nbytes) &gt; (__builtin_object_size (__buf, 0)) / (1))),
                                     "read called with bigger length than size of the destination buffer",
                                     "warning")))
  {
    return (__builtin_object_size (__buf, 0) == (size_t) -1)
      ? __read_alias (__fd,
                      __buf,
                      __nbytes)
      : __read_chk (__fd,
                    __buf,
                    __nbytes,
                    __builtin_object_size (__buf, 0));
  }

To avoid changing the current semantic for GCC, a set of macros is
defined to enable the clang required attributes, along with some changes
on internal macros to avoid the need to issue the symbol_chk symbols
(which are done through the __diagnose_if__ attribute for clang).
The read wrapper is simplified as:

  __fortify_function __attribute_overloadable__ __wur
  ssize_t read (int __fd,
                __fortify_clang_overload_arg0 (void *, ,__buf),
                size_t __nbytes)
       __fortify_clang_warning_only_if_bos0_lt (__nbytes, __buf,
                                                "read called with bigger length than "
                                                "size of the destination buffer")

  {
    return __glibc_fortify (read, __nbytes, sizeof (char),
                            __glibc_objsize0 (__buf),
                            __fd, __buf, __nbytes);
  }

There is no expected semantic or code change when using GCC.

Also, clang does not support __va_arg_pack, so variadic functions are
expanded to call va_arg implementations.  The error function must not
have bodies (address takes are expanded to nonfortified calls), and
with the __fortify_function compiler might still create a body with the
C++ mangling name (due to the overload attribute).  In this case, the
function is defined with __fortify_function_error_function macro
instead.

[1] https://docs.google.com/document/d/1DFfZDICTbL7RqS74wJVIJ-YnjQOj1SaoqfhbgddFYSM/edit

Checked on aarch64, armhf, x86_64, and i686.
Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
Tested-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</content>
</entry>
<entry>
<title>syslog: Fix integer overflow in __vsyslog_internal (CVE-2023-6780)</title>
<updated>2024-01-30T14:53:37Z</updated>
<author>
<name>Arjun Shankar</name>
<email>arjun@redhat.com</email>
</author>
<published>2024-01-15T16:44:45Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=ddf542da94caf97ff43cc2875c88749880b7259b'/>
<id>urn:sha1:ddf542da94caf97ff43cc2875c88749880b7259b</id>
<content type='text'>
__vsyslog_internal calculated a buffer size by adding two integers, but
did not first check if the addition would overflow.  This commit fixes
that.

Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
Tested-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</content>
</entry>
<entry>
<title>syslog: Fix heap buffer overflow in __vsyslog_internal (CVE-2023-6779)</title>
<updated>2024-01-30T14:53:37Z</updated>
<author>
<name>Arjun Shankar</name>
<email>arjun@redhat.com</email>
</author>
<published>2024-01-15T16:44:44Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/glibc/commit/?id=7e5a0c286da33159d47d0122007aac016f3e02cd'/>
<id>urn:sha1:7e5a0c286da33159d47d0122007aac016f3e02cd</id>
<content type='text'>
__vsyslog_internal used the return value of snprintf/vsnprintf to
calculate buffer sizes for memory allocation.  If these functions (for
any reason) failed and returned -1, the resulting buffer would be too
small to hold output.  This commit fixes that.

All snprintf/vsnprintf calls are checked for negative return values and
the function silently returns upon encountering them.

Reviewed-by: Carlos O'Donell &lt;carlos@redhat.com&gt;
</content>
</entry>
</feed>
