diff mbox series

[v2] xfs_repair: detect null buf passed to duration

Message ID 20240601175853.GY52987@frogsfrogsfrogs (mailing list archive)
State Accepted, archived
Headers show
Series [v2] xfs_repair: detect null buf passed to duration | expand

Commit Message

Darrick J. Wong June 1, 2024, 5:58 p.m. UTC 
From: Darrick J. Wong <djwong@kernel.org>

gcc 12.2 with ubsan and fortify turned on complains about this:

In file included from /usr/include/stdio.h:906,
                 from ../include/platform_defs.h:9,
                 from ../include/libxfs.h:16,
                 from progress.c:3:
In function ‘sprintf’,
    inlined from ‘duration’ at progress.c:443:4:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:30:10: error: null destination pointer [-Werror=format-overflow=]
   30 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   31 |                                   __glibc_objsize (__s), __fmt,
      |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   32 |                                   __va_arg_pack ());
      |                                   ~~~~~~~~~~~~~~~~~

I think this is a false negative since all callers are careful not to
pass in a null pointer.  Unfortunately the compiler cannot detect that
since this isn't a static function and complains.  Fix this by adding an
explicit declaration that buf isn't null.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 repair/progress.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Carlos Maiolino June 3, 2024, 12:42 p.m. UTC | #1 
> diff --git a/repair/progress.h b/repair/progress.h
> index 0b06b2c4f43f..c09aa69413ac 100644
> --- a/repair/progress.h
> +++ b/repair/progress.h
> @@ -38,7 +38,7 @@ extern void summary_report(void);
>  extern int  set_progress_msg(int report, uint64_t total);
>  extern uint64_t print_final_rpt(void);
>  extern char *timestamp(struct xfs_mount *mp, int end, int phase, char *buf);
> -extern char *duration(time_t val, char *buf);
> +char *duration(time_t val, char *buf) __attribute__((nonnull(2)));

Once nonnull() is used here, shouldn't we also set -Wnonnull to CFLAGS?

Please don't take it as a review, it's just a question that came to my mind as I don't fully
understand the implications of using nonnull here.

Carlos
Darrick J. Wong June 3, 2024, 4:14 p.m. UTC | #2 
On Mon, Jun 03, 2024 at 02:42:20PM +0200, Carlos Maiolino wrote:
> 
> > diff --git a/repair/progress.h b/repair/progress.h
> > index 0b06b2c4f43f..c09aa69413ac 100644
> > --- a/repair/progress.h
> > +++ b/repair/progress.h
> > @@ -38,7 +38,7 @@ extern void summary_report(void);
> >  extern int  set_progress_msg(int report, uint64_t total);
> >  extern uint64_t print_final_rpt(void);
> >  extern char *timestamp(struct xfs_mount *mp, int end, int phase, char *buf);
> > -extern char *duration(time_t val, char *buf);
> > +char *duration(time_t val, char *buf) __attribute__((nonnull(2)));
> 
> Once nonnull() is used here, shouldn't we also set -Wnonnull to CFLAGS?

Already set via -Wall, at least if you're using gcc 12.2:

       -Wnonnull
           Warn about passing a null pointer for arguments marked as
           requiring a non-null value by the "nonnull" function
           attribute.

           -Wnonnull is included in -Wall and -Wformat.  It can be
           disabled with the -Wno-nonnull option.

https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/tree/include/builddefs.in?h=for-next#n113

> Please don't take it as a review, it's just a question that came to my mind as I don't fully
> understand the implications of using nonnull here.

<nod>

--D

> Carlos
>
Christoph Hellwig June 4, 2024, 4:09 a.m. UTC | #3 
Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>
Carlos Maiolino June 5, 2024, 2:17 p.m. UTC | #4 
On Mon, Jun 03, 2024 at 09:14:46AM GMT, Darrick J. Wong wrote:
> On Mon, Jun 03, 2024 at 02:42:20PM +0200, Carlos Maiolino wrote:
> >
> > > diff --git a/repair/progress.h b/repair/progress.h
> > > index 0b06b2c4f43f..c09aa69413ac 100644
> > > --- a/repair/progress.h
> > > +++ b/repair/progress.h
> > > @@ -38,7 +38,7 @@ extern void summary_report(void);
> > >  extern int  set_progress_msg(int report, uint64_t total);
> > >  extern uint64_t print_final_rpt(void);
> > >  extern char *timestamp(struct xfs_mount *mp, int end, int phase, char *buf);
> > > -extern char *duration(time_t val, char *buf);
> > > +char *duration(time_t val, char *buf) __attribute__((nonnull(2)));
> >
> > Once nonnull() is used here, shouldn't we also set -Wnonnull to CFLAGS?
> 
> Already set via -Wall, at least if you're using gcc 12.2:
> 
>        -Wnonnull
>            Warn about passing a null pointer for arguments marked as
>            requiring a non-null value by the "nonnull" function
>            attribute.
> 
>            -Wnonnull is included in -Wall and -Wformat.  It can be
>            disabled with the -Wno-nonnull option.

Ok, thanks for letting me know :) feel free to add:

Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>

> 
> https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/tree/include/builddefs.in?h=for-next#n113
> 
> > Please don't take it as a review, it's just a question that came to my mind as I don't fully
> > understand the implications of using nonnull here.
> 
> <nod>
> 
> --D
> 
> > Carlos
> >
diff mbox series

Patch

diff --git a/repair/progress.h b/repair/progress.h
index 0b06b2c4f43f..c09aa69413ac 100644
--- a/repair/progress.h
+++ b/repair/progress.h
@@ -38,7 +38,7 @@  extern void summary_report(void);
 extern int  set_progress_msg(int report, uint64_t total);
 extern uint64_t print_final_rpt(void);
 extern char *timestamp(struct xfs_mount *mp, int end, int phase, char *buf);
-extern char *duration(time_t val, char *buf);
+char *duration(time_t val, char *buf) __attribute__((nonnull(2)));
 extern int do_parallel;
 
 #define	PROG_RPT_INC(a,b) if (ag_stride && prog_rpt_done) (a) += (b)