On Fri, May 10, 2024 at 03:26:08AM +, Justin Stitt wrote:
> This feels like a case of accidental correctness. You demonstrated that
> even with overflow we end up going down a control path that returns an
> error code so all is good.
No. It's about a very simple arithmetical fact: the
Hi,
On Fri, May 10, 2024 at 02:04:51AM +0100, Al Viro wrote:
> On Fri, May 10, 2024 at 01:49:06AM +0100, Al Viro wrote:
> > On Fri, May 10, 2024 at 12:35:51AM +, Justin Stitt wrote:
> > > @@ -147,7 +147,9 @@ loff_t dcache_dir_lseek(struct file *file, loff_t
> > > offset, int whence)
> > >
On Fri, May 10, 2024 at 01:49:06AM +0100, Al Viro wrote:
> On Fri, May 10, 2024 at 12:35:51AM +, Justin Stitt wrote:
> > @@ -147,7 +147,9 @@ loff_t dcache_dir_lseek(struct file *file, loff_t
> > offset, int whence)
> > struct dentry *dentry = file->f_path.dentry;
> > switch (whence) {
On Fri, May 10, 2024 at 12:35:51AM +, Justin Stitt wrote:
> @@ -147,7 +147,9 @@ loff_t dcache_dir_lseek(struct file *file, loff_t offset,
> int whence)
> struct dentry *dentry = file->f_path.dentry;
> switch (whence) {
> case 1:
> - offset +=
LOW;
fallthrough;
case SEEK_SET:
if (offset >= 0)
---
base-commit: 0106679839f7c69632b3b9833c3268c316c0a9fc
change-id: 20240509-b4-sio-libfs-67947244a4a3
Best regards,
--
Justin Stitt
rg
Signed-off-by: Justin Stitt
---
Changes in v2:
- fix some more cases syzkaller found in read_write.c
- use min over min_t as the types are the same
- Link to v1:
https://lore.kernel.org/r/20240509-b4-sio-read_write-v1-1-06bec2022...@google.com
---
Here's the syzkaller reproducer:
| # {Thr
On Thu, May 9, 2024 at 8:53 AM Jan Kara wrote:
> > @@ -319,8 +320,12 @@ int vfs_fallocate(struct file *file, int mode, loff_t
> > offset, loff_t len)
> > if (!S_ISREG(inode->i_mode) && !S_ISBLK(inode->i_mode))
> > return -ENODEV;
> >
> > - /* Check for wrap through zero
in_t(loff_t, offset, maxsize - eof) + eof;
break;
case SEEK_CUR:
/*
---
base-commit: 0106679839f7c69632b3b9833c3268c316c0a9fc
change-id: 20240509-b4-sio-read_write-04a17d40620e
Best regards,
--
Justin Stitt
...
> I think that would be a completely different area that might be worth
> looking at: instrumenting implicit casts for "drops bits". I'm afraid
> that it's just *so* common than we might not be able to do that
> sanely.
Things like:
buf[0] = val;
buf[1] = val >>= 8;
...
> Going the other way is similar:
>
> all_bits = low_bits + ((u64) high_bits << 16) << 16);
>
> and again, the compiler will recognize this idiom and do the right
> thing (and if 'all_bits' is only 32-bit, the compiler will optimize
> the high bit noise away).
On a 32bit system the
On Thu, 9 May 2024 23:24:20 +0300
Mike Rapoport wrote:
> On Thu, May 09, 2024 at 01:31:22PM -0400, Steven Rostedt wrote:
> > On Thu, 9 May 2024 00:00:23 -0400
> > Steven Rostedt wrote:
> >
> > > I tried this approach and it unfortunately picks a different physical
> > > location every time
On Thu, May 09, 2024 at 01:31:22PM -0400, Steven Rostedt wrote:
> On Thu, 9 May 2024 00:00:23 -0400
> Steven Rostedt wrote:
>
> > I tried this approach and it unfortunately picks a different physical
> > location every time :-(
> >
> > So it is either adding to e820 tables or we create a new
On Thu, May 09, 2024 at 12:15:40PM -0700, Linus Torvalds wrote:
> On Thu, 9 May 2024 at 11:48, Al Viro wrote:
> >
> > FWIW, the thing that somewhat worries me about having a helper along
> > the lines of combine_to_u64(low, high) is that
> > foo->splat = combine_to_u64(something,
On Thu, 9 May 2024 at 11:48, Al Viro wrote:
>
> FWIW, the thing that somewhat worries me about having a helper along
> the lines of combine_to_u64(low, high) is that
> foo->splat = combine_to_u64(something, something_else);
> would be inviting hard-to-catch brainos -
> foo->splat
On Thu, May 09, 2024 at 11:39:04AM -0700, Linus Torvalds wrote:
> .. it might also actually be a good idea *IF* we were to have some
> kind of "implicit cast drops bits" warning, in that the compiler for
> that case wouldn't remove the upper bits calculation, but would
> trigger a warning if they
On Thu, 9 May 2024 at 11:08, Linus Torvalds
wrote:
>
> Any half-way decent compiler will end up optimizing away the shifts
> and adds for the high bits because they see the assignment to
> 'all_bits'. There's no point in generating high bits that just get
> thrown away.
.. it might also
On Thu, 9 May 2024 at 10:54, Al Viro wrote:
>
> On Thu, May 09, 2024 at 08:38:28AM -0700, Linus Torvalds wrote:
>
> > Going the other way is similar:
> >
> > all_bits = low_bits + ((u64) high_bits << 16) << 16);
> >
> > and again, the compiler will recognize this idiom and do the right
>
On Thu, May 09, 2024 at 08:38:28AM -0700, Linus Torvalds wrote:
> Going the other way is similar:
>
> all_bits = low_bits + ((u64) high_bits << 16) << 16);
>
> and again, the compiler will recognize this idiom and do the right
> thing (and if 'all_bits' is only 32-bit, the compiler will
Hi Kees and Christophe,
First of all, thanks for the reviews, comments and advices.
On Mon, May 06, 2024 at 09:23:15AM -0700, Kees Cook wrote:
> On Sun, May 05, 2024 at 07:31:24PM +0200, Erick Archer wrote:
> > On Sun, May 05, 2024 at 05:24:55PM +0200, Christophe JAILLET wrote:
> > > Le
On Thu, 9 May 2024 00:00:23 -0400
Steven Rostedt wrote:
> I tried this approach and it unfortunately picks a different physical
> location every time :-(
>
> So it is either adding to e820 tables or we create a new way to
> allocate memory at early boot up.
>
Hmm, now I'm testing it more and
On Tue 07-05-24 23:17:57, Justin Stitt wrote:
> Running syzkaller with the newly enabled signed integer overflow
> sanitizer produces this report:
>
> [ 195.401651] [ cut here ]
> [ 195.404808] UBSAN: signed-integer-overflow in ../fs/open.c:321:15
> [ 195.408739]
On Thu, 9 May 2024 at 07:09, Theodore Ts'o wrote:
>
> struct ext2_super {
>...
>__u32time_lo;
>__u32time_high;
>...
> }
>
> time_t now;
>
> sb->time_low = now;
> sb->time_high = now >> 32;
>
> This is obviously (to a human) correct,
On Wed, May 08, 2024 at 11:11:35PM -0700, Kees Cook wrote:
> > I think it would be interesting in general to have some kind of
> > warning for "implicit cast drops bits".
> >
> > I fear that we'd have an enormous about of them, and maybe they'd be
> > unsolvable without making the code *much*
On Wed, May 08, 2024 at 04:47:25PM -0700, Linus Torvalds wrote:
> For example, the most common case of overflow we've ever had has very
> much been array indexing. Now, sometimes that has actually been actual
> undefined behavior, because it's been overflow in signed variables,
> and those are
24 matches
Mail list logo
