[Bug build/26874] -Warray-bounds in _IO_wdefault_doallocate

["siddhesh at sourceware dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=26874

Siddhesh Poyarekar <siddhesh at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |siddhesh at sourceware dot org
              Flags|                            |security-
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED
   Target Milestone|---                         |2.34

--- Comment #2 from Siddhesh Poyarekar <siddhesh at sourceware dot org> ---
Fixed in main:

https://sourceware.org/git/?p=glibc.git;a=commit;h=764e9a0334350f52ab6953bef1db97f9b2e89ca5

commit 764e9a0334350f52ab6953bef1db97f9b2e89ca5 (HEAD -> master, origin/master,
origin/HEAD)
Author: Martin Sebor <msebor@gmail.com>
Date:   Mon Mar 1 10:35:39 2021 +0530

    Correct buffer end pointer in IO_wdefault_doallocate (BZ #26874)

    An experimental build of GCC 11 with an enhanced -Warray-bounds
    reports a bug in IO_wdefault_doallocate where the function forms
    an invalid past-the-end pointer to an allocated wchar_t buffer
    by failingf to consider the scaling by sizeof (wchar_t).

    The fix path below corrects this problem.  It keeps the buffer
    size the same as opposed to increasing it according to what other
    code like it does.

Marking this security- with the following rationale I posted on list:

I spent some time following those vtable setups and I don't think
_IO_wdefault_doallocate gets called at all.  The only instances it is set as
the doallocate callback are in strops, wmemstream and in vswprintf.  In all
those cases, the backing buffer is either user supplied or is sized without
using doallocate (as in the case of strops overflow).

The only time libio needs to allocate buffers in the wide context is in
wfileops when it's actually using the underlying buffer.  In that case however,
the doallocate callback is different.

-- 
You are receiving this mail because:
You are on the CC list for the bug.