* A shift-out-of-bounds in minix_statfs in fs/minix/inode.c
@ 2021-07-21 17:14 butt3rflyh4ck
2021-07-21 17:37 ` Matthew Wilcox
0 siblings, 1 reply; 9+ messages in thread
From: butt3rflyh4ck @ 2021-07-21 17:14 UTC (permalink / raw)
To: LKML, linux-fsdevel, syzkaller-bugs
[-- Attachment #1: Type: text/plain, Size: 6617 bytes --]
Hi, there was a shift-out-bounds bug in minix_statfs in
fs/minix/inode.c founded by my custom syzkaller and reproduced in
linux-5.13.0-rc6+.
####
Simply analyze the vulnerability principle, First, mount a minix file
system by minix_fill_super() and initialize some custom basic data.
the code is as follows:
```
static int minix_fill_super(struct super_block *s, void *data, int silent)
{
struct buffer_head *bh;
struct buffer_head **map;
struct minix_super_block *ms;
struct minix3_super_block *m3s = NULL;
unsigned long i, block;
struct inode *root_inode;
struct minix_sb_info *sbi;
int ret = -EINVAL;
sbi = kzalloc(sizeof(struct minix_sb_info), GFP_KERNEL);
if (!sbi)
return -ENOMEM;
s->s_fs_info = sbi;
BUILD_BUG_ON(32 != sizeof (struct minix_inode));
BUILD_BUG_ON(64 != sizeof(struct minix2_inode));
if (!sb_set_blocksize(s, BLOCK_SIZE))
goto out_bad_hblock;
if (!(bh = sb_bread(s, 1))) /// -----------------> get
minix_super_block's data from super_block
goto out_bad_sb;
ms = (struct minix_super_block *) bh->b_data; /// --------------> set
minix_super_block pointer
sbi->s_ms = ms;
sbi->s_sbh = bh;
sbi->s_mount_state = ms->s_state;
sbi->s_ninodes = ms->s_ninodes;
sbi->s_nzones = ms->s_nzones;
sbi->s_imap_blocks = ms->s_imap_blocks;
sbi->s_zmap_blocks = ms->s_zmap_blocks;
sbi->s_firstdatazone = ms->s_firstdatazone;
sbi->s_log_zone_size = ms->s_log_zone_size; // ------------------>
set sbi->s_log_zone_size
s->s_maxbytes = ms->s_max_size;
s->s_magic = ms->s_magic;
```
Set bh->b_data to sbi. Initialize minix_sb_info by minix_super_block ’s data
After the file system is mounted, we can call the statfs syscall and
it could invoke the minix_statfs function. the code is as follows:
```
static int minix_statfs(struct dentry *dentry, struct kstatfs *buf)
{
struct super_block *sb = dentry->d_sb;
struct minix_sb_info *sbi = minix_sb(sb);
u64 id = huge_encode_dev(sb->s_bdev->bd_dev);
buf->f_type = sb->s_magic;
buf->f_bsize = sb->s_blocksize;
buf->f_blocks = (sbi->s_nzones - sbi->s_firstdatazone) <<
sbi->s_log_zone_size; // -----> shift left
buf->f_bfree = minix_count_free_blocks(sb);
buf->f_bavail = buf->f_bfree;
buf->f_files = sbi->s_ninodes;
buf->f_ffree = minix_count_free_inodes(sb);
buf->f_namelen = sbi->s_namelen;
buf->f_fsid = u64_to_fsid(id);
return 0;
}
```
if set sbi->s_log_zone_size as a lager num, the
(sbi->s_nzones-sbi->s_firstdatazone) will be shift left out of bounds
from the 64-bit type 'long unsigned int'.
####
crash logs is as follows:
```
[ 1512.826425][ T8010] loop0: detected capacity change from 0 to 16
[ 1512.829202][ T8010]
================================================================================
[ 1512.830892][ T8010] UBSAN: shift-out-of-bounds in fs/minix/inode.c:380:57
[ 1512.851019][ T8010] shift exponent 1024 is too large for 64-bit
type 'long unsigned int'
[ 1512.852875][ T8010] CPU: 0 PID: 8010 Comm: minix_statfs Not tainted
5.13.0-rc6+ #21
[ 1512.854333][ T8010] Hardware name: QEMU Standard PC (i440FX + PIIX,
1996), BIOS 1.13.0-1ubuntu1 04/01/2014
[ 1512.856165][ T8010] Call Trace:
[ 1512.856809][ T8010] dump_stack+0x7f/0xad
[ 1512.857629][ T8010] ubsan_epilogue+0x5/0x40
[ 1512.858417][ T8010] __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e
[ 1512.859634][ T8010] ? __lock_acquire+0x3b6/0x2680
[ 1512.860566][ T8010] minix_statfs.cold+0x16/0x1f
[ 1512.861453][ T8010] statfs_by_dentry+0x48/0x70
[ 1512.862314][ T8010] vfs_statfs+0x11/0xc0
[ 1512.863095][ T8010] fd_statfs+0x29/0x60
[ 1512.863860][ T8010] __do_sys_fstatfs+0x20/0x50
[ 1512.864733][ T8010] do_syscall_64+0x3a/0xb0
[ 1512.865820][ T8010] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 1512.866948][ T8010] RIP: 0033:0x44e74d
[ 1512.867804][ T8010] Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3
0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b
4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff 8
[ 1512.871739][ T8010] RSP: 002b:00007ffe06c55808 EFLAGS: 00000217
ORIG_RAX: 000000000000008a
[ 1512.873195][ T8010] RAX: ffffffffffffffda RBX: 0000000000400530
RCX: 000000000044e74d
[ 1512.874585][ T8010] RDX: 000000000044d9f7 RSI: 0000000000000000
RDI: 0000000000000005
[ 1512.875939][ T8010] RBP: 00007ffe06c55820 R08: 00007ffe06c55664
R09: 0000000000000000
[ 1512.877284][ T8010] R10: 00007ffe06c556e0 R11: 0000000000000217
R12: 0000000000403750
[ 1512.878665][ T8010] R13: 0000000000000000 R14: 00000000004c6018
R15: 0000000000000000
[ 1512.881676][ T8010]
================================================================================
[ 1512.883289][ T8010] Kernel panic - not syncing: panic_on_warn set ...
[ 1512.884457][ T8010] CPU: 0 PID: 8010 Comm: minix_statfs Not tainted
5.13.0-rc6+ #21
[ 1512.885851][ T8010] Hardware name: QEMU Standard PC (i440FX + PIIX,
1996), BIOS 1.13.0-1ubuntu1 04/01/2014
[ 1512.887598][ T8010] Call Trace:
[ 1512.888186][ T8010] dump_stack+0x7f/0xad
[ 1512.888935][ T8010] panic+0x147/0x31a
[ 1512.889623][ T8010] ubsan_epilogue+0x3f/0x40
[ 1512.890392][ T8010] __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e
[ 1512.891527][ T8010] ? __lock_acquire+0x3b6/0x2680
[ 1512.892353][ T8010] minix_statfs.cold+0x16/0x1f
[ 1512.893202][ T8010] statfs_by_dentry+0x48/0x70
[ 1512.894033][ T8010] vfs_statfs+0x11/0xc0
[ 1512.894759][ T8010] fd_statfs+0x29/0x60
[ 1512.895483][ T8010] __do_sys_fstatfs+0x20/0x50
[ 1512.896298][ T8010] do_syscall_64+0x3a/0xb0
[ 1512.897103][ T8010] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 1512.898136][ T8010] RIP: 0033:0x44e74d
[ 1512.898823][ T8010] Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3
0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b
4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff 8
[ 1512.902284][ T8010] RSP: 002b:00007ffe06c55808 EFLAGS: 00000217
ORIG_RAX: 000000000000008a
[ 1512.903771][ T8010] RAX: ffffffffffffffda RBX: 0000000000400530
RCX: 000000000044e74d
[ 1512.905263][ T8010] RDX: 000000000044d9f7 RSI: 0000000000000000
RDI: 0000000000000005
[ 1512.906723][ T8010] RBP: 00007ffe06c55820 R08: 00007ffe06c55664
R09: 0000000000000000
[ 1512.908181][ T8010] R10: 00007ffe06c556e0 R11: 0000000000000217
R12: 0000000000403750
[ 1512.909661][ T8010] R13: 0000000000000000 R14: 00000000004c6018
R15: 0000000000000000
[ 1512.911356][ T8010] Kernel Offset: disabled
[ 1512.912216][ T8010] Rebooting in 86400 seconds..
```
The attachment is a reproduction.
Regards,
butt3rflyh4ck
--
Active Defense Lab of Venustech
[-- Attachment #2: repro.cprog --]
[-- Type: application/octet-stream, Size: 14906 bytes --]
// autogenerated by syzkaller (https://github.com/google/syzkaller)
#define _GNU_SOURCE
#include <endian.h>
#include <errno.h>
#include <fcntl.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/mount.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>
#include <linux/loop.h>
static unsigned long long procid;
struct fs_image_segment {
void* data;
uintptr_t size;
uintptr_t offset;
};
#define IMAGE_MAX_SEGMENTS 4096
#define IMAGE_MAX_SIZE (129 << 20)
#define sys_memfd_create 319
static unsigned long fs_image_segment_check(unsigned long size, unsigned long nsegs, struct fs_image_segment* segs)
{
if (nsegs > IMAGE_MAX_SEGMENTS)
nsegs = IMAGE_MAX_SEGMENTS;
for (size_t i = 0; i < nsegs; i++) {
if (segs[i].size > IMAGE_MAX_SIZE)
segs[i].size = IMAGE_MAX_SIZE;
segs[i].offset %= IMAGE_MAX_SIZE;
if (segs[i].offset > IMAGE_MAX_SIZE - segs[i].size)
segs[i].offset = IMAGE_MAX_SIZE - segs[i].size;
if (size < segs[i].offset + segs[i].offset)
size = segs[i].offset + segs[i].offset;
}
if (size > IMAGE_MAX_SIZE)
size = IMAGE_MAX_SIZE;
return size;
}
static int setup_loop_device(long unsigned size, long unsigned nsegs, struct fs_image_segment* segs, const char* loopname, int* memfd_p, int* loopfd_p)
{
int err = 0, loopfd = -1;
size = fs_image_segment_check(size, nsegs, segs);
int memfd = syscall(sys_memfd_create, "syzkaller", 0);
if (memfd == -1) {
err = errno;
goto error;
}
if (ftruncate(memfd, size)) {
err = errno;
goto error_close_memfd;
}
for (size_t i = 0; i < nsegs; i++) {
if (pwrite(memfd, segs[i].data, segs[i].size, segs[i].offset) < 0) {
}
}
loopfd = open(loopname, O_RDWR);
if (loopfd == -1) {
err = errno;
goto error_close_memfd;
}
if (ioctl(loopfd, LOOP_SET_FD, memfd)) {
if (errno != EBUSY) {
err = errno;
goto error_close_loop;
}
ioctl(loopfd, LOOP_CLR_FD, 0);
usleep(1000);
if (ioctl(loopfd, LOOP_SET_FD, memfd)) {
err = errno;
goto error_close_loop;
}
}
*memfd_p = memfd;
*loopfd_p = loopfd;
return 0;
error_close_loop:
close(loopfd);
error_close_memfd:
close(memfd);
error:
errno = err;
return -1;
}
static long syz_mount_image(volatile long fsarg, volatile long dir, volatile unsigned long size, volatile unsigned long nsegs, volatile long segments, volatile long flags, volatile long optsarg)
{
struct fs_image_segment* segs = (struct fs_image_segment*)segments;
int res = -1, err = 0, loopfd = -1, memfd = -1, need_loop_device = !!segs;
char* mount_opts = (char*)optsarg;
char* target = (char*)dir;
char* fs = (char*)fsarg;
char* source = NULL;
char loopname[64];
if (need_loop_device) {
memset(loopname, 0, sizeof(loopname));
snprintf(loopname, sizeof(loopname), "/dev/loop%llu", procid);
if (setup_loop_device(size, nsegs, segs, loopname, &memfd, &loopfd) == -1)
return -1;
source = loopname;
}
mkdir(target, 0777);
char opts[256];
memset(opts, 0, sizeof(opts));
if (strlen(mount_opts) > (sizeof(opts) - 32)) {
}
strncpy(opts, mount_opts, sizeof(opts) - 32);
if (strcmp(fs, "iso9660") == 0) {
flags |= MS_RDONLY;
} else if (strncmp(fs, "ext", 3) == 0) {
if (strstr(opts, "errors=panic") || strstr(opts, "errors=remount-ro") == 0)
strcat(opts, ",errors=continue");
} else if (strcmp(fs, "xfs") == 0) {
strcat(opts, ",nouuid");
}
res = mount(source, target, fs, flags, opts);
if (res == -1) {
err = errno;
goto error_clear_loop;
}
res = open(target, O_RDONLY | O_DIRECTORY);
if (res == -1) {
err = errno;
}
error_clear_loop:
if (need_loop_device) {
ioctl(loopfd, LOOP_CLR_FD, 0);
close(loopfd);
close(memfd);
}
errno = err;
return res;
}
uint64_t r[1] = {0xffffffffffffffff};
int main(void)
{
syscall(__NR_mmap, 0x1ffff000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 7ul, 0x32ul, -1, 0ul);
syscall(__NR_mmap, 0x21000000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul);
intptr_t res = 0;
memcpy((void*)0x20000000, "minix\000", 6);
memcpy((void*)0x20000100, "./file0\000", 8);
*(uint64_t*)0x20000200 = 0x20000e80;
memcpy((void*)0x20000e80, "\x10\x00\x00\x00\x00\x00\x01\x00\x01\x00\x05\x00",12);
memcpy((void*)(0x20000e80+0xc),"\x00\x04",2);// set minix_super_block->s_log_zone_size as 1024
memcpy((void*)(0x20000e80+0xc+0x2),"\x00\x00\xff\xff\xff\x7f\x20\x00\x00\x00\x5a\x4d\x44\xb9\xaa\x59\xa0\x95\x5e\x22\x03\xb4\x11\xab\xcc\x28\x47\xe7\xf6\x09\x7a\x14\xd5\xe1\x55\x55\xf9\xbd\x36\xdd\x6c\x5f\x04\x1e\x3c\x73\x0d\xd0\x9a\xdb\xe6\x03\xdc\x35\x35\x5b\x0b\x2e\x4c\x7f\xa3\x25\xff\xe1\xf9\x56\xa9\x0d\xb7\x4b\x6d\x83\x04\xd1\xdd\x3e\x6e\x06\x41\x62\x91\x38\x3f\xf2\x48\xc8\xb6\x28\x85\x1a\x20\x88\x97\xb7\xa1\x0f\xd3\x9f\xeb\x9e\x72\x8a\x86\x80\x09\x0d\xb9\x1e\x55\x30\xb0\x53\x10\x2d\x87\xa3\x4e\x66\xe6\xfb\x56\xf4\x30\xdd\x3f\x53\x9d\xff\x22\x31\xc3\xfa\xbb\xe1\xc3\xc7\x72\x7c\x39\xdc\xab\xaa\x03\x98\x24\xd5\x47\xfb\x80\x8e\xc8\xda\x26\xa0\x46\xfe\x52\x22\x59\x26\x94\x3c\x21\x5a\xcf\x88\x91\x1f\x71\x0b\xee\x54\x28\xed\xe7\x7e\xd9\x0e\x4a\xc6\x3a\x8c\x78\x4d\xcb\x85\x9f\x54\x19\xf4\x53\x87\x5b\xbd\xb5\x2a\xc6\x90\x8d\x6e\xe6\xac\xa1\x6d\x18\x28\xa1\xcf\xd6\x23\x7c\xe5\xbc\x82\x1d\x8f\x29\xa1\x62\x20\xb4\x09\xa5\xb3\x0c\xcf\x42\x81\x6b\xcb\x40\xe9\x64\xb5\x01\x59\x13\x0d\x19\x1e\x79\xb8\x1d\xa9\xa9\x5c\xa6\x02\x87\x90\x6a\x43\x36\xee\x62\xa4\x4b\x57\x9c\x30\x9d\xb9\x98\x4c\x21\xde\xf4\x6c\x4e\xf4\x3b\x24\xb7\x88\x2f\xb9\x00\x51\x31\x33\xa7\xc1\x51\xb2\xf6\xaf\xb4\xe3\xc7\x36\x24\x5c\xdc\xce\x71\xb7\x35\xdd\xc4\x22\xa7\x66\x59\x8c\x4a\x79\x96\x85\x7e\x1d\xa9\x4c\x03\xbe\x2c\x50\xb6\xbd\x85\xac\x1c\xd2\x0e\x85\xd9\xdc\x67\x9a\x64\xc7\x92\x52\xc8\x07\x79\xb9\x24\x93\xa2\x53\x0c\x23\x97\x2d\xbb\xe3\xae\x3e\xeb\x02\x81\x4d\x8f\xff\xbd\xf0\xce\x98\xed\xd0\xc5\xf8\x35\xba\xba\x10\x6d\x3e\xe2\xaa\x4d\xf6\xdc\x1f\x48\xe3\xca\x80\xd6\x48\x19\xfb\xe6\x54\xb0\xf0\xb8\xa8\xbc\x50\xe5\xaa\x03\x3e\xcd\x14\x51\x20\x99\x00\xed\x76\x20\x97\x3a\xf9\x11\xc6\x68\x4c\x22\x68\xf2\x2e\x36\xf9\xd6\xcb\x99\x89\x74\x10\xd6\x72\x19\xb0\xab\x72\x9d\x3a\x18\x5f\xa7\x22\x99\xe5\x6c\x32\x00\x85\x11\x2e\xe4\x13\x7e\xa5\xbd\x8a\x1e\x13\xca\x0e\x7f\x0c\xf5\x28\x24\x35\xeb\xaf", 474-12-2);
*(uint64_t*)0x20000208 = 0x1da;
*(uint64_t*)0x20000210 = 0x400;
*(uint64_t*)0x20000218 = 0x200005c0;
memcpy((void*)0x200005c0, "\xff\x00\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x03\xf0\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xed\x41\x03", 2051);
*(uint64_t*)0x20000220 = 0x803;
*(uint64_t*)0x20000228 = 0x800;//
*(uint64_t*)0x20000230 = 0;
*(uint64_t*)0x20000238 = 0;
*(uint64_t*)0x20000240 = 0x1000;
res = -1;
res = syz_mount_image(0x20000000, 0x20000100, 0, 3, 0x20000200, 0, 0x20000e00);
if (res != -1)
r[0] = res;
syscall(__NR_fstatfs, r[0], 0ul);
return 0;
}
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: A shift-out-of-bounds in minix_statfs in fs/minix/inode.c
2021-07-21 17:14 A shift-out-of-bounds in minix_statfs in fs/minix/inode.c butt3rflyh4ck
@ 2021-07-21 17:37 ` Matthew Wilcox
2021-07-21 19:14 ` Darrick J. Wong
` (3 more replies)
0 siblings, 4 replies; 9+ messages in thread
From: Matthew Wilcox @ 2021-07-21 17:37 UTC (permalink / raw)
To: butt3rflyh4ck; +Cc: LKML, linux-fsdevel, syzkaller-bugs
On Thu, Jul 22, 2021 at 01:14:06AM +0800, butt3rflyh4ck wrote:
> ms = (struct minix_super_block *) bh->b_data; /// --------------> set
> minix_super_block pointer
> sbi->s_ms = ms;
> sbi->s_sbh = bh;
> sbi->s_mount_state = ms->s_state;
> sbi->s_ninodes = ms->s_ninodes;
> sbi->s_nzones = ms->s_nzones;
> sbi->s_imap_blocks = ms->s_imap_blocks;
> sbi->s_zmap_blocks = ms->s_zmap_blocks;
> sbi->s_firstdatazone = ms->s_firstdatazone;
> sbi->s_log_zone_size = ms->s_log_zone_size; // ------------------>
> set sbi->s_log_zone_size
So what you're saying is that if you construct a malicious minix image,
you can produce undefined behaviour? That's not something we're
traditionally interested in, unless the filesystem is one customarily
used for data interchange (like FAT or iso9660).
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: A shift-out-of-bounds in minix_statfs in fs/minix/inode.c
2021-07-21 17:37 ` Matthew Wilcox
@ 2021-07-21 19:14 ` Darrick J. Wong
2021-07-22 2:43 ` butt3rflyh4ck
` (2 subsequent siblings)
3 siblings, 0 replies; 9+ messages in thread
From: Darrick J. Wong @ 2021-07-21 19:14 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: butt3rflyh4ck, LKML, linux-fsdevel, syzkaller-bugs
On Wed, Jul 21, 2021 at 06:37:23PM +0100, Matthew Wilcox wrote:
> On Thu, Jul 22, 2021 at 01:14:06AM +0800, butt3rflyh4ck wrote:
> > ms = (struct minix_super_block *) bh->b_data; /// --------------> set
> > minix_super_block pointer
> > sbi->s_ms = ms;
> > sbi->s_sbh = bh;
> > sbi->s_mount_state = ms->s_state;
> > sbi->s_ninodes = ms->s_ninodes;
> > sbi->s_nzones = ms->s_nzones;
> > sbi->s_imap_blocks = ms->s_imap_blocks;
> > sbi->s_zmap_blocks = ms->s_zmap_blocks;
> > sbi->s_firstdatazone = ms->s_firstdatazone;
> > sbi->s_log_zone_size = ms->s_log_zone_size; // ------------------>
> > set sbi->s_log_zone_size
>
> So what you're saying is that if you construct a malicious minix image,
> you can produce undefined behaviour? That's not something we're
> traditionally interested in, unless the filesystem is one customarily
> used for data interchange (like FAT or iso9660).
Sounds to me like butt3rflyh4ck is volunteering to rebuild fs/minix with
proper ondisk metadata buffer verifiers.
--D
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: A shift-out-of-bounds in minix_statfs in fs/minix/inode.c
2021-07-21 17:37 ` Matthew Wilcox
2021-07-21 19:14 ` Darrick J. Wong
@ 2021-07-22 2:43 ` butt3rflyh4ck
2021-07-22 2:52 ` Matthew Wilcox
2021-07-22 8:09 ` Dan Carpenter
2021-07-22 21:58 ` Theodore Ts'o
3 siblings, 1 reply; 9+ messages in thread
From: butt3rflyh4ck @ 2021-07-22 2:43 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: LKML, linux-fsdevel, syzkaller-bugs, djwong
On Thu, Jul 22, 2021 at 1:37 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Thu, Jul 22, 2021 at 01:14:06AM +0800, butt3rflyh4ck wrote:
> > ms = (struct minix_super_block *) bh->b_data; /// --------------> set
> > minix_super_block pointer
> > sbi->s_ms = ms;
> > sbi->s_sbh = bh;
> > sbi->s_mount_state = ms->s_state;
> > sbi->s_ninodes = ms->s_ninodes;
> > sbi->s_nzones = ms->s_nzones;
> > sbi->s_imap_blocks = ms->s_imap_blocks;
> > sbi->s_zmap_blocks = ms->s_zmap_blocks;
> > sbi->s_firstdatazone = ms->s_firstdatazone;
> > sbi->s_log_zone_size = ms->s_log_zone_size; // ------------------>
> > set sbi->s_log_zone_size
>
> So what you're saying is that if you construct a malicious minix image,
> you can produce undefined behaviour?
Yes, the attachment is a reproduction. just compile it and run.
>That's not something we're
> traditionally interested in, unless the filesystem is one customarily
> used for data interchange (like FAT or iso9660).
>
These file systems are my fuzzing targets.
Regards,
butt3rflyh4ck.
--
Active Defense Lab of Venustech
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: A shift-out-of-bounds in minix_statfs in fs/minix/inode.c
2021-07-22 2:43 ` butt3rflyh4ck
@ 2021-07-22 2:52 ` Matthew Wilcox
0 siblings, 0 replies; 9+ messages in thread
From: Matthew Wilcox @ 2021-07-22 2:52 UTC (permalink / raw)
To: butt3rflyh4ck; +Cc: LKML, linux-fsdevel, syzkaller-bugs, djwong
On Thu, Jul 22, 2021 at 10:43:10AM +0800, butt3rflyh4ck wrote:
> On Thu, Jul 22, 2021 at 1:37 AM Matthew Wilcox <willy@infradead.org> wrote:
> >That's not something we're
> > traditionally interested in, unless the filesystem is one customarily
> > used for data interchange (like FAT or iso9660).
>
> These file systems are my fuzzing targets.
You're not the first.
https://lore.kernel.org/linux-fsdevel/6A96C62E-1D01-44AD-B2C5-7A2258BADC0D@schumilo.de/T/#u
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: A shift-out-of-bounds in minix_statfs in fs/minix/inode.c
2021-07-21 17:37 ` Matthew Wilcox
2021-07-21 19:14 ` Darrick J. Wong
2021-07-22 2:43 ` butt3rflyh4ck
@ 2021-07-22 8:09 ` Dan Carpenter
2021-07-22 21:58 ` Theodore Ts'o
3 siblings, 0 replies; 9+ messages in thread
From: Dan Carpenter @ 2021-07-22 8:09 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: butt3rflyh4ck, LKML, linux-fsdevel, syzkaller-bugs
On Wed, Jul 21, 2021 at 06:37:23PM +0100, Matthew Wilcox wrote:
> On Thu, Jul 22, 2021 at 01:14:06AM +0800, butt3rflyh4ck wrote:
> > ms = (struct minix_super_block *) bh->b_data; /// --------------> set
> > minix_super_block pointer
> > sbi->s_ms = ms;
> > sbi->s_sbh = bh;
> > sbi->s_mount_state = ms->s_state;
> > sbi->s_ninodes = ms->s_ninodes;
> > sbi->s_nzones = ms->s_nzones;
> > sbi->s_imap_blocks = ms->s_imap_blocks;
> > sbi->s_zmap_blocks = ms->s_zmap_blocks;
> > sbi->s_firstdatazone = ms->s_firstdatazone;
> > sbi->s_log_zone_size = ms->s_log_zone_size; // ------------------>
> > set sbi->s_log_zone_size
>
> So what you're saying is that if you construct a malicious minix image,
> you can produce undefined behaviour? That's not something we're
> traditionally interested in, unless the filesystem is one customarily
> used for data interchange (like FAT or iso9660).
Someone had the idea what we should make these things only compile for
usermode linux. It's kind of a hassle to copy things from UML but if
people really wanted to we could write a program to handle it.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: A shift-out-of-bounds in minix_statfs in fs/minix/inode.c
2021-07-21 17:37 ` Matthew Wilcox
` (2 preceding siblings ...)
2021-07-22 8:09 ` Dan Carpenter
@ 2021-07-22 21:58 ` Theodore Ts'o
2021-07-22 22:34 ` Randy Dunlap
2021-07-23 9:22 ` Christian Brauner
3 siblings, 2 replies; 9+ messages in thread
From: Theodore Ts'o @ 2021-07-22 21:58 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: butt3rflyh4ck, LKML, linux-fsdevel, syzkaller-bugs
On Wed, Jul 21, 2021 at 06:37:23PM +0100, Matthew Wilcox wrote:
> On Thu, Jul 22, 2021 at 01:14:06AM +0800, butt3rflyh4ck wrote:
> > ms = (struct minix_super_block *) bh->b_data; /// --------------> set
> > minix_super_block pointer
> > sbi->s_ms = ms;
> > sbi->s_sbh = bh;
> > sbi->s_mount_state = ms->s_state;
> > sbi->s_ninodes = ms->s_ninodes;
> > sbi->s_nzones = ms->s_nzones;
> > sbi->s_imap_blocks = ms->s_imap_blocks;
> > sbi->s_zmap_blocks = ms->s_zmap_blocks;
> > sbi->s_firstdatazone = ms->s_firstdatazone;
> > sbi->s_log_zone_size = ms->s_log_zone_size; // ------------------>
> > set sbi->s_log_zone_size
>
> So what you're saying is that if you construct a malicious minix image,
> you can produce undefined behaviour? That's not something we're
> traditionally interested in, unless the filesystem is one customarily
> used for data interchange (like FAT or iso9660).
It's going to depend on the file system maintainer. The traditional
answer is that block device is part of the Trusted Computing Base, and
malicious file system images are not considered part of the threat
model. A system adminstration or developer which allows potentially
malicious agents to mount file system agents are cray-cray.
Unfortunately, those developers are also known as "Linux desktop devs"
(who implement unprivileged mounts of USB cards) or "container
evangelists" who think containers should be treated as being Just As
Good as VM's From A Security Perspective.
So I do care about this for ext4, although I don't guarantee immediate
response, as it's something that I usually end up doing on my own
time. I do get cranky that Syzkaller makes it painful to extract out
the fuzzed file system image, and I much prefer those fuzzing systems
which provide the file system image and the C program used to trigger
the failre as two seprate files. Or failing that, if there was some
trivial way to get the syzkaller reproducer program to disgorge the
file system image to a specified output file. As a result, if I have
a choice of spending time investigating fuzzing report from a more
file-system friendly fuzzing program and syzkaller, I'll tend choose
to spend my time dealing with other file system fuzzing reports first.
The problem for Minix is that it does not have an active maintainer.
So if you submit fuzzing reports for Minix, it's unlikely anyone will
spend time working on it. But if you submit a patch, it can go in,
probably via Andrew Morton. (Recent Minix fixes that have gone in
this way: 0a12c4a8069 and 32ac86efff9)
Cheers,
- Ted
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: A shift-out-of-bounds in minix_statfs in fs/minix/inode.c
2021-07-22 21:58 ` Theodore Ts'o
@ 2021-07-22 22:34 ` Randy Dunlap
2021-07-23 9:22 ` Christian Brauner
1 sibling, 0 replies; 9+ messages in thread
From: Randy Dunlap @ 2021-07-22 22:34 UTC (permalink / raw)
To: Theodore Ts'o, Matthew Wilcox
Cc: butt3rflyh4ck, LKML, linux-fsdevel, syzkaller-bugs
On 7/22/21 2:58 PM, Theodore Ts'o wrote:
...
>
> So I do care about this for ext4, although I don't guarantee immediate
> response, as it's something that I usually end up doing on my own
> time. I do get cranky that Syzkaller makes it painful to extract out
> the fuzzed file system image, and I much prefer those fuzzing systems
> which provide the file system image and the C program used to trigger
> the failre as two seprate files. Or failing that, if there was some
gosh yes. I have added a patch to the syzkaller C reproducer multiple times
so that it would write out the fs image and then I could just use that
with 'mount' etc. instead of running the (unreadable) C reproducer.
> trivial way to get the syzkaller reproducer program to disgorge the
> file system image to a specified output file. As a result, if I have
> a choice of spending time investigating fuzzing report from a more
> file-system friendly fuzzing program and syzkaller, I'll tend choose
> to spend my time dealing with other file system fuzzing reports first.
--
~Randy
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: A shift-out-of-bounds in minix_statfs in fs/minix/inode.c
2021-07-22 21:58 ` Theodore Ts'o
2021-07-22 22:34 ` Randy Dunlap
@ 2021-07-23 9:22 ` Christian Brauner
1 sibling, 0 replies; 9+ messages in thread
From: Christian Brauner @ 2021-07-23 9:22 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Matthew Wilcox, butt3rflyh4ck, LKML, linux-fsdevel, syzkaller-bugs
On Thu, Jul 22, 2021 at 05:58:23PM -0400, Theodore Ts'o wrote:
> On Wed, Jul 21, 2021 at 06:37:23PM +0100, Matthew Wilcox wrote:
> > On Thu, Jul 22, 2021 at 01:14:06AM +0800, butt3rflyh4ck wrote:
> > > ms = (struct minix_super_block *) bh->b_data; /// --------------> set
> > > minix_super_block pointer
> > > sbi->s_ms = ms;
> > > sbi->s_sbh = bh;
> > > sbi->s_mount_state = ms->s_state;
> > > sbi->s_ninodes = ms->s_ninodes;
> > > sbi->s_nzones = ms->s_nzones;
> > > sbi->s_imap_blocks = ms->s_imap_blocks;
> > > sbi->s_zmap_blocks = ms->s_zmap_blocks;
> > > sbi->s_firstdatazone = ms->s_firstdatazone;
> > > sbi->s_log_zone_size = ms->s_log_zone_size; // ------------------>
> > > set sbi->s_log_zone_size
> >
> > So what you're saying is that if you construct a malicious minix image,
> > you can produce undefined behaviour? That's not something we're
> > traditionally interested in, unless the filesystem is one customarily
> > used for data interchange (like FAT or iso9660).
>
> It's going to depend on the file system maintainer. The traditional
> answer is that block device is part of the Trusted Computing Base, and
> malicious file system images are not considered part of the threat
> model. A system adminstration or developer which allows potentially
> malicious agents to mount file system agents are cray-cray.
>
> Unfortunately, those developers are also known as "Linux desktop devs"
> (who implement unprivileged mounts of USB cards) or "container
That has always been a weird approach for sure.
> evangelists" who think containers should be treated as being Just As
> Good as VM's From A Security Perspective.
Mounting virtual filesystems like procfs, sysfs, cgroupfs, devpts,
binderfs and so on in unprivileged containers makes a lot of sense but
for filesystems like ext4, xfs, or btrfs making them mountable inside
unprivileged containers aka user namespaces never made a lot of sense to
me.
Most users don't really want to or need to expose a whole filesystem
image to their containers anyway. It's much more common that they want
to expose a part of an existing filesystem that has been mounted by an
administrator before. Which means they create bind mounts of the
directories that they want to expose. And as soon as the filesystem
supports idmapped mounts like ext4 does you can then serve all of those
use-cases including creating an idmapped mount of the whole filesystem
itself. And then you shouldn't need to require that the filesystem must
be able to mount untrusted images.
>
> So I do care about this for ext4, although I don't guarantee immediate
> response, as it's something that I usually end up doing on my own
> time. I do get cranky that Syzkaller makes it painful to extract out
> the fuzzed file system image, and I much prefer those fuzzing systems
> which provide the file system image and the C program used to trigger
> the failre as two seprate files. Or failing that, if there was some
> trivial way to get the syzkaller reproducer program to disgorge the
> file system image to a specified output file. As a result, if I have
> a choice of spending time investigating fuzzing report from a more
> file-system friendly fuzzing program and syzkaller, I'll tend choose
> to spend my time dealing with other file system fuzzing reports first.
>
> The problem for Minix is that it does not have an active maintainer.
> So if you submit fuzzing reports for Minix, it's unlikely anyone will
> spend time working on it. But if you submit a patch, it can go in,
> probably via Andrew Morton. (Recent Minix fixes that have gone in
> this way: 0a12c4a8069 and 32ac86efff9)
>
> Cheers,
>
> - Ted>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-07-23 9:23 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-21 17:14 A shift-out-of-bounds in minix_statfs in fs/minix/inode.c butt3rflyh4ck
2021-07-21 17:37 ` Matthew Wilcox
2021-07-21 19:14 ` Darrick J. Wong
2021-07-22 2:43 ` butt3rflyh4ck
2021-07-22 2:52 ` Matthew Wilcox
2021-07-22 8:09 ` Dan Carpenter
2021-07-22 21:58 ` Theodore Ts'o
2021-07-22 22:34 ` Randy Dunlap
2021-07-23 9:22 ` Christian Brauner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).