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
| ||
|
Date: Sun, 9 Oct 2022 15:05:17 +1300 From: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@...il.com> To: Kees Cook <keescook@...omium.org> Cc: Christine Caulfield <ccaulfie@...hat.com>, David Teigland <teigland@...hat.com>, cluster-devel@...hat.com, linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org Subject: Re: [PATCH v2][next] dlm: Replace one-element array with flexible-array member On Sat, Oct 08, 2022 at 05:18:35PM -0700, Kees Cook wrote: > >$ diff <(objdump -M intel -j .text -D dlm.old) <(objdump -M intel -j > >.text -D dlm.new) > > I'd suggest different options here, this is harder to map back to the source line. > See https://outflux.net/blog/archives/2022/06/24/finding-binary-differences/ > for lots of details. :) > Just read the blog entry, it's really interesting. I will be using it from now onwards :) > > > >13778c13778 > >< c693: 49 8d bc 24 c0 08 00 lea rdi,[r12+0x8c0] > >--- > >> c693: 49 8d bc 24 c1 08 00 lea rdi,[r12+0x8c1] > > This implies something unexpected changed. > I will add more details about this line at the other point you made below to avoid repeating myself. But to cut a long story, short.. this [reg + displacement + 1] difference is caused because I deliberately add the NUL-terminator space to the kzalloc() call. > This has trailing padding, so the struct size didn't actually change. > > >- ls = kzalloc(sizeof(struct dlm_ls) + namelen, GFP_NOFS); > >+ ls = kzalloc(sizeof(struct dlm_ls) + namelen + 1, GFP_NOFS); > > This is allocating 1 more byte than before, since the struct size didn't change. But this has always allocated too much space, due to the struct padding. For a "no binary changes" patch, the above "+ 1" needs to be left off. That's true. I agree that leaving "+ 1" would work and produce a no-binary-changes patch due to the existing padding that the structure has. OTOH, I thought that relying on that space could bite us in the future if anyone tweaks the struct again...so my reaction was to ensure that the NUL-terminator space was always guaranteed to be there. Hence, the change on c693 (objdump above). What do you think? Should we keep or leave the above "+ 1" after the rationale above? > > I would expect the correct allocation size to be: > offsetof(typeof(*ls), ls_name) + namelen Fair point, I will make this change. > > Question, though: is ls_name _expected_ to be %NUL terminated Yes, it is. I tracked down ls_name's utilisations and it is passed down to a bunch of routines that expects it to be NUL-terminated such as snprintf and vsnprintf. >, and was the prior 3 bytes of extra allocation accidentally required? > I am assuming that you are refering to ls_namelen in the struct dlm_ls (please correct me if this isn't what you meant). ls_namelen member is only used within the routine which kzalloc the space for the struct (fs/dlm/lockspace.c:new_lockspace). There are no external references to this member outside of that method in the kernel. One could say that ls_namelen can be removed without side effects but I wouldn't suggest doing it in this patch, that's why I didn't touch it :) Paulo A.
Powered by blists - more mailing lists