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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <202309291255.C5485E6811@keescook> Date: Fri, 29 Sep 2023 12:56:22 -0700 From: Kees Cook <keescook@...omium.org> To: Dean Luick <dean.luick@...nelisnetworks.com> Cc: Leon Romanovsky <leon@...nel.org>, Dennis Dalessandro <dennis.dalessandro@...nelisnetworks.com>, Jason Gunthorpe <jgg@...pe.ca>, Justin Stitt <justinstitt@...gle.com>, linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org Subject: Re: [PATCH] IB/hfi1: replace deprecated strncpy On Tue, Sep 26, 2023 at 07:56:34AM -0500, Dean Luick wrote: > On 9/23/2023 10:20 PM, Kees Cook wrote: > > On Fri, Sep 22, 2023 at 09:25:39AM -0500, Dean Luick wrote: > >> On 9/22/2023 5:29 AM, Leon Romanovsky wrote: > >>> > >>> On Thu, 21 Sep 2023 07:17:47 +0000, Justin Stitt wrote: > >>>> `strncpy` is deprecated for use on NUL-terminated destination strings > >>>> [1] and as such we should prefer more robust and less ambiguous string > >>>> interfaces. > >>>> > >>>> We see that `buf` is expected to be NUL-terminated based on it's use > >>>> within a trace event wherein `is_misc_err_name` and `is_various_name` > >>>> map to `is_name` through `is_table`: > >>>> | TRACE_EVENT(hfi1_interrupt, > >>>> | TP_PROTO(struct hfi1_devdata *dd, const struct is_table *is_entry, > >>>> | int src), > >>>> | TP_ARGS(dd, is_entry, src), > >>>> | TP_STRUCT__entry(DD_DEV_ENTRY(dd) > >>>> | __array(char, buf, 64) > >>>> | __field(int, src) > >>>> | ), > >>>> | TP_fast_assign(DD_DEV_ASSIGN(dd); > >>>> | is_entry->is_name(__entry->buf, 64, > >>>> | src - is_entry->start); > >>>> | __entry->src = src; > >>>> | ), > >>>> | TP_printk("[%s] source: %s [%d]", __get_str(dev), __entry->buf, > >>>> | __entry->src) > >>>> | ); > >>>> > >>>> [...] > >>> > >>> Applied, thanks! > >> > >> It is unfortunate that this and the qib patch was accepted so quickly. The replacement is functionally correct. However, I was going to suggest using strscpy() since the return value is never looked at and all use cases only require a NUL-terminated string. Padding is not needed. > > > > Is the trace buffer already guaranteed to be zeroed? Since this is > > defined as a fixed-size string in the buffer, it made sense to me to be > > sure that the unused bytes were 0 before copying them to userspace. > > I was not aware that binary trace records were exposed to user space. If so, and the event records are not zeroed (either the buffer as a whole, or individual records), then strscpy_pad() is the correct solution. My quick review of the tracing system suggests that nothing is zeroed and the record is embedded in a larger structure. However, this begs the question for all users of tracing: Aren't alignment holes in the fast assign record a leak? I thought they were passed over direct to userspace somehow, but I haven't looked at the details in a long time. I could very well be misunderstanding it. -- Kees Cook
Powered by blists - more mailing lists