> Oops, I was just doing some testing and thought that correct behavior
> for crafted FS is to return arbitrary valid error code (like -EIO) or
> some arbitrary data, say, not larger than FS (not disclosing the
> kernel memory, of course). Please excuse me if I was wrong. If fixing
> this would
> Oops, I was just doing some testing and thought that correct behavior
> for crafted FS is to return arbitrary valid error code (like -EIO) or
> some arbitrary data, say, not larger than FS (not disclosing the
> kernel memory, of course). Please excuse me if I was wrong. If fixing
> this would
Thanks for explanation!
Best regards,
Anatoly
вс, 15 июл. 2018 г. в 18:26, OGAWA Hirofumi :
>
> Anatoly Trosinenko writes:
>
> >> This patch returns better error (-EIO) for me.
> >
> > This works for me likewise.
>
> Thanks for testing.
>
> >> (But note, the corrupted FS image doesn't guarantee
Thanks for explanation!
Best regards,
Anatoly
вс, 15 июл. 2018 г. в 18:26, OGAWA Hirofumi :
>
> Anatoly Trosinenko writes:
>
> >> This patch returns better error (-EIO) for me.
> >
> > This works for me likewise.
>
> Thanks for testing.
>
> >> (But note, the corrupted FS image doesn't guarantee
Anatoly Trosinenko writes:
>> This patch returns better error (-EIO) for me.
>
> This works for me likewise.
Thanks for testing.
>> (But note, the corrupted FS image doesn't guarantee POSIX behavior.)
>
> Oops, I was just doing some testing and thought that correct behavior
> for crafted FS is
Anatoly Trosinenko writes:
>> This patch returns better error (-EIO) for me.
>
> This works for me likewise.
Thanks for testing.
>> (But note, the corrupted FS image doesn't guarantee POSIX behavior.)
>
> Oops, I was just doing some testing and thought that correct behavior
> for crafted FS is
Thank you!
> This patch returns better error (-EIO) for me.
This works for me likewise.
> (But note, the corrupted FS image doesn't guarantee POSIX behavior.)
Oops, I was just doing some testing and thought that correct behavior
for crafted FS is to return arbitrary valid error code (like
Thank you!
> This patch returns better error (-EIO) for me.
This works for me likewise.
> (But note, the corrupted FS image doesn't guarantee POSIX behavior.)
Oops, I was just doing some testing and thought that correct behavior
for crafted FS is to return arbitrary valid error code (like
Al Viro writes:
> On Sun, Jul 15, 2018 at 11:20:06PM +0900, OGAWA Hirofumi wrote:
>> +static inline bool fat_valid_entry(struct msdos_sb_info *sbi, int entry)
>> +{
>> +if (entry < FAT_START_ENT || sbi->max_cluster <= entry)
>> +return false;
>> +return true;
>> +}
>
> Pet
Al Viro writes:
> On Sun, Jul 15, 2018 at 11:20:06PM +0900, OGAWA Hirofumi wrote:
>> +static inline bool fat_valid_entry(struct msdos_sb_info *sbi, int entry)
>> +{
>> +if (entry < FAT_START_ENT || sbi->max_cluster <= entry)
>> +return false;
>> +return true;
>> +}
>
> Pet
On Sun, Jul 15, 2018 at 11:20:06PM +0900, OGAWA Hirofumi wrote:
> +static inline bool fat_valid_entry(struct msdos_sb_info *sbi, int entry)
> +{
> + if (entry < FAT_START_ENT || sbi->max_cluster <= entry)
> + return false;
> + return true;
> +}
Pet peeve: if (...) return
On Sun, Jul 15, 2018 at 11:20:06PM +0900, OGAWA Hirofumi wrote:
> +static inline bool fat_valid_entry(struct msdos_sb_info *sbi, int entry)
> +{
> + if (entry < FAT_START_ENT || sbi->max_cluster <= entry)
> + return false;
> + return true;
> +}
Pet peeve: if (...) return
Anatoly Trosinenko writes:
> How to reproduce:
> 1) Compile v4.18-rc4 kernel with the attached config
> 1) Unpack the attached FS image (128 Mb) and mount it as vfat to /mnt
> 2) Compile and run vfat-bug.c
>
> What is expected:
> `write` returns either -1 or small positive number.
>
> What
Anatoly Trosinenko writes:
> How to reproduce:
> 1) Compile v4.18-rc4 kernel with the attached config
> 1) Unpack the attached FS image (128 Mb) and mount it as vfat to /mnt
> 2) Compile and run vfat-bug.c
>
> What is expected:
> `write` returns either -1 or small positive number.
>
> What
14 matches
Mail list logo
