On Thu 09-05-24 15:10:07, Justin Stitt wrote:
> 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
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
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 Tue, May 07, 2024 at 11:17:57PM +, 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
> [
On Tue, May 07, 2024 at 11:17:57PM +, Justin Stitt wrote:
> I wonder, though, why isn't loff_t an unsigned type?
Consider
lseek(fd, -10, SEEK_CUR)
PS: the above is *not* an endorsement of the proposed patch or
KASAN overflow nonsense in general.
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] 9223372036854775807 + 562984447377399 cannot be represented in
