linux-hardening - Re: [RFC PATCH] xfs: fix FORTIFY_SOURCE complaints about log item memcpy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 25 Oct 2022 11:40:32 -0700
From:   Kees Cook <keescook@...omium.org>
To:     "Darrick J. Wong" <djwong@...nel.org>
Cc:     h@...nolia, xfs <linux-xfs@...r.kernel.org>,
        Zorro Lang <zlang@...hat.com>, linux-hardening@...r.kernel.org
Subject: Re: [RFC PATCH] xfs: fix FORTIFY_SOURCE complaints about log item
 memcpy

On Mon, Oct 24, 2022 at 02:38:14PM -0700, Darrick J. Wong wrote:
> <nod> I realized that these helpers introducing unsafe memcpy weren't
> needed.  Later on after chatting with dchinner a bit I came to the
> conclusion that we might as well convert most of the _copy_format
> functions to memcpy the structure head and flex array separately since
> that function is converting an ondisk log item into its in-memory
> representation, and some day we'll make those struct fields endian safe.
> They aren't now, and that's one of the (many) gaping holes that need
> fixing.

Ah, perfect! Yeah, this is one of the other standard solutions -- header
and flex array handled separately. I'm still working on APIs to handle
the common cases, though. XFS probably will want to keep it separate as
you've done.

> I sent my candidate fixes series to the list just now.

Thanks! I'll go check them out.

-- 
Kees Cook