fs/jfs/namei.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
To avoid confusing the compiler about possible negative sizes, switch
"ssize" which can never be negative from int to u32. Seen with GCC 13:
../fs/jfs/namei.c: In function 'jfs_symlink': ../include/linux/fortify-string.h:57:33: warning: '__builtin_memcpy' pointer overflow between offset 0 and size [-2147483648, -1]
[-Warray-bounds=]
57 | #define __underlying_memcpy __builtin_memcpy
| ^
...
../fs/jfs/namei.c:950:17: note: in expansion of macro 'memcpy'
950 | memcpy(ip->i_link, name, ssize);
| ^~~~~~
Cc: Dave Kleikamp <shaggy@kernel.org>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: jfs-discussion@lists.sourceforge.net
Signed-off-by: Kees Cook <keescook@chromium.org>
---
fs/jfs/namei.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/jfs/namei.c b/fs/jfs/namei.c
index b29d68b5eec5..494b9f4043cf 100644
--- a/fs/jfs/namei.c
+++ b/fs/jfs/namei.c
@@ -876,7 +876,7 @@ static int jfs_symlink(struct mnt_idmap *idmap, struct inode *dip,
tid_t tid;
ino_t ino = 0;
struct component_name dname;
- int ssize; /* source pathname size */
+ u32 ssize; /* source pathname size */
struct btstack btstack;
struct inode *ip = d_inode(dentry);
s64 xlen = 0;
@@ -957,7 +957,7 @@ static int jfs_symlink(struct mnt_idmap *idmap, struct inode *dip,
if (ssize > sizeof (JFS_IP(ip)->i_inline))
JFS_IP(ip)->mode2 &= ~INLINEEA;
- jfs_info("jfs_symlink: fast symlink added ssize:%d name:%s ",
+ jfs_info("jfs_symlink: fast symlink added ssize:%u name:%s ",
ssize, name);
}
/*
@@ -987,7 +987,7 @@ static int jfs_symlink(struct mnt_idmap *idmap, struct inode *dip,
ip->i_size = ssize - 1;
while (ssize) {
/* This is kind of silly since PATH_MAX == 4K */
- int copy_size = min(ssize, PSIZE);
+ u32 copy_size = min_t(u32, ssize, PSIZE);
mp = get_metapage(ip, xaddr, PSIZE, 1);
--
2.34.1On Sat, 04 Feb 2023 10:33:56 -0800, Kees Cook wrote:
> To avoid confusing the compiler about possible negative sizes, switch
> "ssize" which can never be negative from int to u32. Seen with GCC 13:
>
> ../fs/jfs/namei.c: In function 'jfs_symlink': ../include/linux/fortify-string.h:57:33: warning: '__builtin_memcpy' pointer overflow between offset 0 and size [-2147483648, -1]
> [-Warray-bounds=]
> 57 | #define __underlying_memcpy __builtin_memcpy
> | ^
> ...
> ../fs/jfs/namei.c:950:17: note: in expansion of macro 'memcpy'
> 950 | memcpy(ip->i_link, name, ssize);
> | ^~~~~~
>
> [...]
Applied to the vfs.misc branch of the vfs/vfs.git tree.
Patches in the vfs.misc branch should appear in linux-next soon.
Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.
It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs.misc
[1/1] jfs: Use unsigned variable for length calculations
https://git.kernel.org/vfs/vfs/c/2d6e1895d440
I apologize to all of you for letting this one go so long. Acked-by: Dave Kleikamp <dave.kleikamp@oracle.com> On 6/2/23 3:32AM, Christian Brauner wrote: > On Sat, 04 Feb 2023 10:33:56 -0800, Kees Cook wrote: >> To avoid confusing the compiler about possible negative sizes, switch >> "ssize" which can never be negative from int to u32. Seen with GCC 13: >> >> ../fs/jfs/namei.c: In function 'jfs_symlink': ../include/linux/fortify-string.h:57:33: warning: '__builtin_memcpy' pointer overflow between offset 0 and size [-2147483648, -1] >> [-Warray-bounds=] >> 57 | #define __underlying_memcpy __builtin_memcpy >> | ^ >> ... >> ../fs/jfs/namei.c:950:17: note: in expansion of macro 'memcpy' >> 950 | memcpy(ip->i_link, name, ssize); >> | ^~~~~~ >> >> [...] > > Applied to the vfs.misc branch of the vfs/vfs.git tree. > Patches in the vfs.misc branch should appear in linux-next soon. > > Please report any outstanding bugs that were missed during review in a > new review to the original patch series allowing us to drop it. > > It's encouraged to provide Acked-bys and Reviewed-bys even though the > patch has now been applied. If possible patch trailers will be updated. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git > branch: vfs.misc > > [1/1] jfs: Use unsigned variable for length calculations > https://git.kernel.org/vfs/vfs/c/2d6e1895d440
* Kees Cook (keescook@chromium.org) wrote:
> To avoid confusing the compiler about possible negative sizes, switch
> "ssize" which can never be negative from int to u32. Seen with GCC 13:
>
> ../fs/jfs/namei.c: In function 'jfs_symlink': ../include/linux/fortify-string.h:57:33: warning: '__builtin_memcpy' pointer overflow between offset 0 and size [-2147483648, -1]
> [-Warray-bounds=]
> 57 | #define __underlying_memcpy __builtin_memcpy
> | ^
> ...
> ../fs/jfs/namei.c:950:17: note: in expansion of macro 'memcpy'
> 950 | memcpy(ip->i_link, name, ssize);
> | ^~~~~~
>
> Cc: Dave Kleikamp <shaggy@kernel.org>
> Cc: Christian Brauner <brauner@kernel.org>
> Cc: Dave Chinner <dchinner@redhat.com>
> Cc: jfs-discussion@lists.sourceforge.net
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> fs/jfs/namei.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/fs/jfs/namei.c b/fs/jfs/namei.c
> index b29d68b5eec5..494b9f4043cf 100644
> --- a/fs/jfs/namei.c
> +++ b/fs/jfs/namei.c
> @@ -876,7 +876,7 @@ static int jfs_symlink(struct mnt_idmap *idmap, struct inode *dip,
> tid_t tid;
> ino_t ino = 0;
> struct component_name dname;
> - int ssize; /* source pathname size */
> + u32 ssize; /* source pathname size */
Had you considered using size_t - this is set from a strlen and used by a memcpy
that both talk size_t.
Dave
> struct btstack btstack;
> struct inode *ip = d_inode(dentry);
> s64 xlen = 0;
> @@ -957,7 +957,7 @@ static int jfs_symlink(struct mnt_idmap *idmap, struct inode *dip,
> if (ssize > sizeof (JFS_IP(ip)->i_inline))
> JFS_IP(ip)->mode2 &= ~INLINEEA;
>
> - jfs_info("jfs_symlink: fast symlink added ssize:%d name:%s ",
> + jfs_info("jfs_symlink: fast symlink added ssize:%u name:%s ",
> ssize, name);
> }
> /*
> @@ -987,7 +987,7 @@ static int jfs_symlink(struct mnt_idmap *idmap, struct inode *dip,
> ip->i_size = ssize - 1;
> while (ssize) {
> /* This is kind of silly since PATH_MAX == 4K */
> - int copy_size = min(ssize, PSIZE);
> + u32 copy_size = min_t(u32, ssize, PSIZE);
>
> mp = get_metapage(ip, xaddr, PSIZE, 1);
>
> --
> 2.34.1
>
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
On Sat, Feb 04, 2023 at 08:25:45PM +0000, Dr. David Alan Gilbert wrote: > * Kees Cook (keescook@chromium.org) wrote: > > To avoid confusing the compiler about possible negative sizes, switch > > "ssize" which can never be negative from int to u32. Seen with GCC 13: > > > > ../fs/jfs/namei.c: In function 'jfs_symlink': ../include/linux/fortify-string.h:57:33: warning: '__builtin_memcpy' pointer overflow between offset 0 and size [-2147483648, -1] > > [-Warray-bounds=] > > 57 | #define __underlying_memcpy __builtin_memcpy > > | ^ > > ... > > ../fs/jfs/namei.c:950:17: note: in expansion of macro 'memcpy' > > 950 | memcpy(ip->i_link, name, ssize); > > | ^~~~~~ > > > > Cc: Dave Kleikamp <shaggy@kernel.org> > > Cc: Christian Brauner <brauner@kernel.org> > > Cc: Dave Chinner <dchinner@redhat.com> > > Cc: jfs-discussion@lists.sourceforge.net > > Signed-off-by: Kees Cook <keescook@chromium.org> > > --- > > fs/jfs/namei.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/fs/jfs/namei.c b/fs/jfs/namei.c > > index b29d68b5eec5..494b9f4043cf 100644 > > --- a/fs/jfs/namei.c > > +++ b/fs/jfs/namei.c > > @@ -876,7 +876,7 @@ static int jfs_symlink(struct mnt_idmap *idmap, struct inode *dip, > > tid_t tid; > > ino_t ino = 0; > > struct component_name dname; > > - int ssize; /* source pathname size */ > > + u32 ssize; /* source pathname size */ > > Had you considered using size_t - this is set from a strlen and used by a memcpy > that both talk size_t. I considered that, but I've had other maintainers upset about doubling the variable size. I opted to keep the variable 32-bit here, so the machine code would only change to lose signed-ness. -Kees -- Kees Cook
* Kees Cook (keescook@chromium.org) wrote: > On Sat, Feb 04, 2023 at 08:25:45PM +0000, Dr. David Alan Gilbert wrote: > > * Kees Cook (keescook@chromium.org) wrote: > > > To avoid confusing the compiler about possible negative sizes, switch > > > "ssize" which can never be negative from int to u32. Seen with GCC 13: > > > > > > ../fs/jfs/namei.c: In function 'jfs_symlink': ../include/linux/fortify-string.h:57:33: warning: '__builtin_memcpy' pointer overflow between offset 0 and size [-2147483648, -1] > > > [-Warray-bounds=] > > > 57 | #define __underlying_memcpy __builtin_memcpy > > > | ^ > > > ... > > > ../fs/jfs/namei.c:950:17: note: in expansion of macro 'memcpy' > > > 950 | memcpy(ip->i_link, name, ssize); > > > | ^~~~~~ > > > > > > Cc: Dave Kleikamp <shaggy@kernel.org> > > > Cc: Christian Brauner <brauner@kernel.org> > > > Cc: Dave Chinner <dchinner@redhat.com> > > > Cc: jfs-discussion@lists.sourceforge.net > > > Signed-off-by: Kees Cook <keescook@chromium.org> > > > --- > > > fs/jfs/namei.c | 6 +++--- > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git a/fs/jfs/namei.c b/fs/jfs/namei.c > > > index b29d68b5eec5..494b9f4043cf 100644 > > > --- a/fs/jfs/namei.c > > > +++ b/fs/jfs/namei.c > > > @@ -876,7 +876,7 @@ static int jfs_symlink(struct mnt_idmap *idmap, struct inode *dip, > > > tid_t tid; > > > ino_t ino = 0; > > > struct component_name dname; > > > - int ssize; /* source pathname size */ > > > + u32 ssize; /* source pathname size */ > > > > Had you considered using size_t - this is set from a strlen and used by a memcpy > > that both talk size_t. > > I considered that, but I've had other maintainers upset about doubling > the variable size. I bet at least on some platforms it's cheaper as the 64 bit. > I opted to keep the variable 32-bit here, so the > machine code would only change to lose signed-ness. Fair enough. Dave > -Kees > > -- > Kees Cook -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ dave @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/
On Mon, Feb 06, 2023 at 07:50:42PM +0000, Dr. David Alan Gilbert wrote: > * Kees Cook (keescook@chromium.org) wrote: > > On Sat, Feb 04, 2023 at 08:25:45PM +0000, Dr. David Alan Gilbert wrote: > > > * Kees Cook (keescook@chromium.org) wrote: > > > > To avoid confusing the compiler about possible negative sizes, switch > > > > "ssize" which can never be negative from int to u32. Seen with GCC 13: > > > > > > > > ../fs/jfs/namei.c: In function 'jfs_symlink': ../include/linux/fortify-string.h:57:33: warning: '__builtin_memcpy' pointer overflow between offset 0 and size [-2147483648, -1] > > > > [-Warray-bounds=] > > > > 57 | #define __underlying_memcpy __builtin_memcpy > > > > | ^ > > > > ... > > > > ../fs/jfs/namei.c:950:17: note: in expansion of macro 'memcpy' > > > > 950 | memcpy(ip->i_link, name, ssize); > > > > | ^~~~~~ > > > > > > > > Cc: Dave Kleikamp <shaggy@kernel.org> > > > > Cc: Christian Brauner <brauner@kernel.org> > > > > Cc: Dave Chinner <dchinner@redhat.com> > > > > Cc: jfs-discussion@lists.sourceforge.net > > > > Signed-off-by: Kees Cook <keescook@chromium.org> > > > > --- > > > > fs/jfs/namei.c | 6 +++--- > > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/fs/jfs/namei.c b/fs/jfs/namei.c > > > > index b29d68b5eec5..494b9f4043cf 100644 > > > > --- a/fs/jfs/namei.c > > > > +++ b/fs/jfs/namei.c > > > > @@ -876,7 +876,7 @@ static int jfs_symlink(struct mnt_idmap *idmap, struct inode *dip, > > > > tid_t tid; > > > > ino_t ino = 0; > > > > struct component_name dname; > > > > - int ssize; /* source pathname size */ > > > > + u32 ssize; /* source pathname size */ > > > > > > Had you considered using size_t - this is set from a strlen and used by a memcpy > > > that both talk size_t. > > > > I considered that, but I've had other maintainers upset about doubling > > the variable size. > > I bet at least on some platforms it's cheaper as the 64 bit. > > > I opted to keep the variable 32-bit here, so the > > machine code would only change to lose signed-ness. > > Fair enough. Thread ping. Can someone pick this up (or Ack it for my tree), please? Thanks! -Kees -- Kees Cook
From: Kees Cook > Sent: 01 June 2023 17:55 > > On Mon, Feb 06, 2023 at 07:50:42PM +0000, Dr. David Alan Gilbert wrote: > > * Kees Cook (keescook@chromium.org) wrote: > > > On Sat, Feb 04, 2023 at 08:25:45PM +0000, Dr. David Alan Gilbert wrote: ... > > > > > - int ssize; /* source pathname size */ > > > > > + u32 ssize; /* source pathname size */ > > > > > > > > Had you considered using size_t - this is set from a strlen and used by a memcpy > > > > that both talk size_t. > > > > > > I considered that, but I've had other maintainers upset about doubling > > > the variable size. > > > > I bet at least on some platforms it's cheaper as the 64 bit. > > > > > I opted to keep the variable 32-bit here, so the > > > machine code would only change to lose signed-ness. On x86-64 'unsigned int' and 'signed long' are likely to generate the best code. If you use 'signed int' it will to have to be sign extended if used in a 64-bit expression (eg as an array index). (That is probably true of most 64bit arch.) OTOH 'unsigned long' always requires a REX prefix - making the code that bit larger. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Thu, Jun 1, 2023 at 9:55 AM Kees Cook <keescook@chromium.org> wrote: > > On Mon, Feb 06, 2023 at 07:50:42PM +0000, Dr. David Alan Gilbert wrote: > > * Kees Cook (keescook@chromium.org) wrote: > > > On Sat, Feb 04, 2023 at 08:25:45PM +0000, Dr. David Alan Gilbert wrote: > > > > * Kees Cook (keescook@chromium.org) wrote: > > > > > To avoid confusing the compiler about possible negative sizes, switch > > > > > "ssize" which can never be negative from int to u32. Seen with GCC 13: > > > > > > > > > > ../fs/jfs/namei.c: In function 'jfs_symlink': ../include/linux/fortify-string.h:57:33: warning: '__builtin_memcpy' pointer overflow between offset 0 and size [-2147483648, -1] > > > > > [-Warray-bounds=] > > > > > 57 | #define __underlying_memcpy __builtin_memcpy > > > > > | ^ > > > > > ... > > > > > ../fs/jfs/namei.c:950:17: note: in expansion of macro 'memcpy' > > > > > 950 | memcpy(ip->i_link, name, ssize); > > > > > | ^~~~~~ > > > > > > > > > > Cc: Dave Kleikamp <shaggy@kernel.org> > > > > > Cc: Christian Brauner <brauner@kernel.org> > > > > > Cc: Dave Chinner <dchinner@redhat.com> > > > > > Cc: jfs-discussion@lists.sourceforge.net > > > > > Signed-off-by: Kees Cook <keescook@chromium.org> > > > > > --- > > > > > fs/jfs/namei.c | 6 +++--- > > > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > > > > > diff --git a/fs/jfs/namei.c b/fs/jfs/namei.c > > > > > index b29d68b5eec5..494b9f4043cf 100644 > > > > > --- a/fs/jfs/namei.c > > > > > +++ b/fs/jfs/namei.c > > > > > @@ -876,7 +876,7 @@ static int jfs_symlink(struct mnt_idmap *idmap, struct inode *dip, > > > > > tid_t tid; > > > > > ino_t ino = 0; > > > > > struct component_name dname; > > > > > - int ssize; /* source pathname size */ > > > > > + u32 ssize; /* source pathname size */ > > > > > > > > Had you considered using size_t - this is set from a strlen and used by a memcpy > > > > that both talk size_t. > > > > > > I considered that, but I've had other maintainers upset about doubling > > > the variable size. > > > > I bet at least on some platforms it's cheaper as the 64 bit. > > > > > I opted to keep the variable 32-bit here, so the > > > machine code would only change to lose signed-ness. > > > > Fair enough. > > Thread ping. Can someone pick this up (or Ack it for my tree), please? > Acked-by: Jeff Xu <jeffxu@chromium.org> In case you ask someone to look at code, which I did. Best -Jeff > Thanks! > > -Kees > > -- > Kees Cook
© 2016 - 2026 Red Hat, Inc.