Re: WARNING in notify_change
On Tue 16-04-19 00:54:28, Al Viro wrote: > On Mon, Apr 15, 2019 at 04:20:17PM -0700, Khazhismel Kumykov wrote: > > I was able to reproduce this by setting security.capability xattr on a > > blockdev file, then writing to it - when writing to the blockdev we > > never lock the inode, so when we clear the capability we hit this > > lockdep warning. > > > > Is the issue here that we can set this xattr in the first place so we > > have to clear it at all? Or should we really be locking the inode for > > blockdevs after all? I'm not too familiar, but my gut says former > > More interesting question is, WTF do we even touch that thing for > bdev? The thing is, mknod will cheerfully create any number of > different filesystem objects, all giving access to the same block > device. Which of them should have that xattr removed? It makes > no sense whatsoever; moreover, who *cares* about caps for block > device in the first place? > > And if we did, what of another way to modify the block device? > You know, mount it read-write... Yes, Alexander Lochman has sent a patch to silence this warning back in February [1] by just bailing out from file_remove_privs() for non-regular files. But so far you've ignored that patch... Will you pick it up please? Honza [1] https://lore.kernel.org/lkml/cbdc8071-de76-bb0a-6890-15ef21023...@tu-dortmund.de -- Jan Kara SUSE Labs, CR
Re: WARNING in notify_change
On Mon, Apr 15, 2019 at 04:20:17PM -0700, Khazhismel Kumykov wrote: > I was able to reproduce this by setting security.capability xattr on a > blockdev file, then writing to it - when writing to the blockdev we > never lock the inode, so when we clear the capability we hit this > lockdep warning. > > Is the issue here that we can set this xattr in the first place so we > have to clear it at all? Or should we really be locking the inode for > blockdevs after all? I'm not too familiar, but my gut says former More interesting question is, WTF do we even touch that thing for bdev? The thing is, mknod will cheerfully create any number of different filesystem objects, all giving access to the same block device. Which of them should have that xattr removed? It makes no sense whatsoever; moreover, who *cares* about caps for block device in the first place? And if we did, what of another way to modify the block device? You know, mount it read-write...
Re: WARNING in notify_change
I was able to reproduce this by setting security.capability xattr on a
blockdev file, then writing to it - when writing to the blockdev we
never lock the inode, so when we clear the capability we hit this
lockdep warning.
Is the issue here that we can set this xattr in the first place so we
have to clear it at all? Or should we really be locking the inode for
blockdevs after all? I'm not too familiar, but my gut says former
this reproducer is able to immediately crash machine running
linux-next-20190415:
#include
#include
#include
#include
#include
#include
#include
#include
#include
char *disk = "/dev/loop0";
int main(void) {
int fd = open(disk, 0);
if (fd < 0)
printf("open: %d\n", errno);
system("dd if=/dev/zero of=a_file count=51200");
system("losetup /dev/loop0 a_file");
uint32_t value[5] = {
0x200,
7,
0x20d0,
6,
4
};
int res = fsetxattr(fd, "security.capability", ,
sizeof(value), XATTR_CREATE);
if (res < 0)
printf ("xattr: %d\n", errno);
int fd2 = open(disk, O_RDWR);
write(fd2, "hello", 5);
return 0;
}
smime.p7s
Description: S/MIME Cryptographic Signature
Re: WARNING in notify_change
I haven't succeeded reproducing this bug using original C reproducer.
Instead, I'm observing XFS warning using modified reproducer shown below.
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
#include
#include
#include
#include
struct thread_t {
int created, running, call;
pthread_t th;
};
static struct thread_t threads[16];
static void execute_call(int call);
static int running;
static int collide;
static void* thr(void* arg)
{
struct thread_t* th = (struct thread_t*)arg;
for (;;) {
while (!__atomic_load_n(>running, __ATOMIC_ACQUIRE))
syscall(SYS_futex, >running, FUTEX_WAIT, 0, 0);
execute_call(th->call);
__atomic_fetch_sub(, 1, __ATOMIC_RELAXED);
__atomic_store_n(>running, 0, __ATOMIC_RELEASE);
syscall(SYS_futex, >running, FUTEX_WAKE);
}
return 0;
}
static void execute(int num_calls)
{
int call, thread;
running = 0;
for (call = 0; call < num_calls; call++) {
for (thread = 0; thread < sizeof(threads) / sizeof(threads[0]);
thread++) {
struct thread_t* th = [thread];
if (!th->created) {
th->created = 1;
pthread_attr_t attr;
pthread_attr_init();
pthread_attr_setstacksize(, 128 << 10);
pthread_create(>th, , thr, th);
}
if (!__atomic_load_n(>running, __ATOMIC_ACQUIRE)) {
th->call = call;
__atomic_fetch_add(, 1,
__ATOMIC_RELAXED);
__atomic_store_n(>running, 1,
__ATOMIC_RELEASE);
syscall(SYS_futex, >running, FUTEX_WAKE);
if (collide && call % 2)
break;
struct timespec ts;
ts.tv_sec = 0;
ts.tv_nsec = 20 * 1000 * 1000;
syscall(SYS_futex, >running, FUTEX_WAIT, 1,
);
if (running)
usleep((call == num_calls - 1) ? 1
: 1000);
break;
}
}
}
}
static void execute_call(int call)
{
switch (call) {
case 0:
creat("file0", 0x2080);
break;
case 1:
lsetxattr("file0", "security.capability",
"\x00\x00\x00\x02\x01\x00\x00\x00\x00\x00\x00\x01"
"\x04\x00\x00\x00\x00\x00\x00\x00", 20, 0);
break;
}
}
int main(int argc, char *argv[])
{
execute_call(0);
execute_call(1);
execute(2);
return 0;
}
When lsetxattr() is called in parallel (with CONFIG_XFS_WARN=y),
XFS emits below warning due to ATTR_KILL_PRIV not cleared yet.
[ 33.347151] XFS: Assertion failed: (iattr->ia_valid &
(ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
ATTR_MTIME_SET|ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0, file: fs/xfs/xfs_iops.c,
line: 792
[ 33.353353] [ cut here ]
[ 33.355376] WARNING: CPU: 0 PID: 5355 at fs/xfs/xfs_message.c:105
asswarn+0x2c/0x30 [xfs]
[ 33.358501] Modules linked in: ip6t_rpfilter ipt_REJECT nf_reject_ipv4
ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat
ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
nf_nat_ipv6 ip6table_mangle ip6table_raw iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_raw
ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter vmw_balloon
intel_powerclamp pcspkr vmw_vmci i2c_piix4 sg ppdev parport_pc parport
ip_tables xfs libcrc32c sd_mod sr_mod cdrom ata_generic pata_acpi serio_raw
vmwgfx drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops mptspi
e1000 ttm scsi_transport_spi ahci mptscsih libahci drm ata_piix mptbase
i2c_core libata
[ 33.385636] CPU: 0 PID: 5355 Comm: a.out Not tainted 4.9.0-rc1+ #55
[ 33.389051] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 05/19/2017
[ 33.393952] ae56d0dafb78 8f30c3ed
[ 33.398032] ae56d0dafbb8 8f075431 0069d0dafbd8
9e5ca0ea1040
[ 33.401454] ae56d0dafcd8 9e5ca0e9f778
9e5ca0ea1318
[ 33.404603] Call Trace:
[ 33.406183] [] dump_stack+0x8e/0xd1
[ 33.408541] [] __warn+0xc1/0xe0
[
Re: WARNING in notify_change
I haven't succeeded reproducing this bug using original C reproducer.
Instead, I'm observing XFS warning using modified reproducer shown below.
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
#include
#include
#include
#include
struct thread_t {
int created, running, call;
pthread_t th;
};
static struct thread_t threads[16];
static void execute_call(int call);
static int running;
static int collide;
static void* thr(void* arg)
{
struct thread_t* th = (struct thread_t*)arg;
for (;;) {
while (!__atomic_load_n(>running, __ATOMIC_ACQUIRE))
syscall(SYS_futex, >running, FUTEX_WAIT, 0, 0);
execute_call(th->call);
__atomic_fetch_sub(, 1, __ATOMIC_RELAXED);
__atomic_store_n(>running, 0, __ATOMIC_RELEASE);
syscall(SYS_futex, >running, FUTEX_WAKE);
}
return 0;
}
static void execute(int num_calls)
{
int call, thread;
running = 0;
for (call = 0; call < num_calls; call++) {
for (thread = 0; thread < sizeof(threads) / sizeof(threads[0]);
thread++) {
struct thread_t* th = [thread];
if (!th->created) {
th->created = 1;
pthread_attr_t attr;
pthread_attr_init();
pthread_attr_setstacksize(, 128 << 10);
pthread_create(>th, , thr, th);
}
if (!__atomic_load_n(>running, __ATOMIC_ACQUIRE)) {
th->call = call;
__atomic_fetch_add(, 1,
__ATOMIC_RELAXED);
__atomic_store_n(>running, 1,
__ATOMIC_RELEASE);
syscall(SYS_futex, >running, FUTEX_WAKE);
if (collide && call % 2)
break;
struct timespec ts;
ts.tv_sec = 0;
ts.tv_nsec = 20 * 1000 * 1000;
syscall(SYS_futex, >running, FUTEX_WAIT, 1,
);
if (running)
usleep((call == num_calls - 1) ? 1
: 1000);
break;
}
}
}
}
static void execute_call(int call)
{
switch (call) {
case 0:
creat("file0", 0x2080);
break;
case 1:
lsetxattr("file0", "security.capability",
"\x00\x00\x00\x02\x01\x00\x00\x00\x00\x00\x00\x01"
"\x04\x00\x00\x00\x00\x00\x00\x00", 20, 0);
break;
}
}
int main(int argc, char *argv[])
{
execute_call(0);
execute_call(1);
execute(2);
return 0;
}
When lsetxattr() is called in parallel (with CONFIG_XFS_WARN=y),
XFS emits below warning due to ATTR_KILL_PRIV not cleared yet.
[ 33.347151] XFS: Assertion failed: (iattr->ia_valid &
(ATTR_UID|ATTR_GID|ATTR_ATIME|ATTR_ATIME_SET|
ATTR_MTIME_SET|ATTR_KILL_PRIV|ATTR_TIMES_SET)) == 0, file: fs/xfs/xfs_iops.c,
line: 792
[ 33.353353] [ cut here ]
[ 33.355376] WARNING: CPU: 0 PID: 5355 at fs/xfs/xfs_message.c:105
asswarn+0x2c/0x30 [xfs]
[ 33.358501] Modules linked in: ip6t_rpfilter ipt_REJECT nf_reject_ipv4
ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat
ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
nf_nat_ipv6 ip6table_mangle ip6table_raw iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_raw
ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter vmw_balloon
intel_powerclamp pcspkr vmw_vmci i2c_piix4 sg ppdev parport_pc parport
ip_tables xfs libcrc32c sd_mod sr_mod cdrom ata_generic pata_acpi serio_raw
vmwgfx drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops mptspi
e1000 ttm scsi_transport_spi ahci mptscsih libahci drm ata_piix mptbase
i2c_core libata
[ 33.385636] CPU: 0 PID: 5355 Comm: a.out Not tainted 4.9.0-rc1+ #55
[ 33.389051] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 05/19/2017
[ 33.393952] ae56d0dafb78 8f30c3ed
[ 33.398032] ae56d0dafbb8 8f075431 0069d0dafbd8
9e5ca0ea1040
[ 33.401454] ae56d0dafcd8 9e5ca0e9f778
9e5ca0ea1318
[ 33.404603] Call Trace:
[ 33.406183] [] dump_stack+0x8e/0xd1
[ 33.408541] [] __warn+0xc1/0xe0
[
WARNING in notify_change
Hello, syzbot hit the following crash on upstream commit 3fd14cdcc05a682b03743683ce3a726898b20555 (Fri Apr 6 19:15:41 2018 +) Merge tag 'mtd/for-4.17' of git://git.infradead.org/linux-mtd syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=2b74da47f048a5046135 So far this crash happened 3 times on upstream. C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5084712116682752 syzkaller reproducer: https://syzkaller.appspot.com/x/repro.syz?id=6394049002995712 Raw console output: https://syzkaller.appspot.com/x/log.txt?id=4711531803574272 Kernel config: https://syzkaller.appspot.com/x/.config?id=-5813481738265533882 compiler: gcc (GCC) 8.0.1 20180301 (experimental) IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+2b74da47f048a5046...@syzkaller.appspotmail.com It will help syzbot understand when the bug is fixed. See footer for details. If you forward the report, please keep this part and the footer. WARNING: CPU: 1 PID: 4470 at fs/attr.c:213 notify_change+0xd94/0x10c0 fs/attr.c:213 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 4470 Comm: syzkaller570118 Not tainted 4.16.0+ #4 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b9/0x294 lib/dump_stack.c:113 panic+0x22f/0x4de kernel/panic.c:183 __warn.cold.8+0x163/0x1a3 kernel/panic.c:547 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315 invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:991 RIP: 0010:notify_change+0xd94/0x10c0 fs/attr.c:213 RSP: 0018:8801ad76f860 EFLAGS: 00010293 RAX: 8801d9f66680 RBX: 8801d32d4630 RCX: 81c36578 RDX: RSI: 81c371b4 RDI: 0007 RBP: 8801ad76f930 R08: 8801d9f66680 R09: ed003a65a8e2 R10: ed003a65a8e2 R11: 8801d32d4717 R12: 4200 R13: 8801ad76f970 R14: 8801d5260ce0 R15: 110035aedf18 __remove_privs fs/inode.c:1813 [inline] file_remove_privs+0x2bf/0x530 fs/inode.c:1835 __generic_file_write_iter+0x169/0x5e0 mm/filemap.c:3209 blkdev_write_iter+0x233/0x420 fs/block_dev.c:1908 call_write_iter include/linux/fs.h:1782 [inline] new_sync_write fs/read_write.c:474 [inline] __vfs_write+0x5bc/0x880 fs/read_write.c:487 vfs_write+0x1f8/0x560 fs/read_write.c:549 ksys_write+0xf9/0x250 fs/read_write.c:598 SYSC_write fs/read_write.c:610 [inline] SyS_write+0x24/0x30 fs/read_write.c:607 do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 RIP: 0033:0x445c59 RSP: 002b:7f76203b7d38 EFLAGS: 0293 ORIG_RAX: 0001 RAX: ffda RBX: 006dac24 RCX: 00445c59 RDX: 0050 RSI: 2400 RDI: 0008 RBP: 0005 R08: R09: R10: R11: 0293 R12: 006dac20 R13: 0006 R14: 0030656c69662f2e R15: Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a dumb bot. It may contain errors. See https://goo.gl/tpsmEJ for details. Direct all questions to syzkal...@googlegroups.com. syzbot will keep track of this bug report. If you forgot to add the Reported-by tag, once the fix for this bug is merged into any tree, please reply to this email with: #syz fix: exact-commit-title If you want to test a patch for this bug, please reply with: #syz test: git://repo/address.git branch and provide the patch inline or as an attachment. To mark this as a duplicate of another syzbot report, please reply with: #syz dup: exact-subject-of-another-report If it's a one-off invalid bug report, please reply with: #syz invalid Note: if the crash happens again, it will cause creation of a new bug report. Note: all commands must start from beginning of the line in the email body.
WARNING in notify_change
Hello, syzbot hit the following crash on upstream commit 3fd14cdcc05a682b03743683ce3a726898b20555 (Fri Apr 6 19:15:41 2018 +) Merge tag 'mtd/for-4.17' of git://git.infradead.org/linux-mtd syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=2b74da47f048a5046135 So far this crash happened 3 times on upstream. C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5084712116682752 syzkaller reproducer: https://syzkaller.appspot.com/x/repro.syz?id=6394049002995712 Raw console output: https://syzkaller.appspot.com/x/log.txt?id=4711531803574272 Kernel config: https://syzkaller.appspot.com/x/.config?id=-5813481738265533882 compiler: gcc (GCC) 8.0.1 20180301 (experimental) IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+2b74da47f048a5046...@syzkaller.appspotmail.com It will help syzbot understand when the bug is fixed. See footer for details. If you forward the report, please keep this part and the footer. WARNING: CPU: 1 PID: 4470 at fs/attr.c:213 notify_change+0xd94/0x10c0 fs/attr.c:213 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 4470 Comm: syzkaller570118 Not tainted 4.16.0+ #4 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b9/0x294 lib/dump_stack.c:113 panic+0x22f/0x4de kernel/panic.c:183 __warn.cold.8+0x163/0x1a3 kernel/panic.c:547 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315 invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:991 RIP: 0010:notify_change+0xd94/0x10c0 fs/attr.c:213 RSP: 0018:8801ad76f860 EFLAGS: 00010293 RAX: 8801d9f66680 RBX: 8801d32d4630 RCX: 81c36578 RDX: RSI: 81c371b4 RDI: 0007 RBP: 8801ad76f930 R08: 8801d9f66680 R09: ed003a65a8e2 R10: ed003a65a8e2 R11: 8801d32d4717 R12: 4200 R13: 8801ad76f970 R14: 8801d5260ce0 R15: 110035aedf18 __remove_privs fs/inode.c:1813 [inline] file_remove_privs+0x2bf/0x530 fs/inode.c:1835 __generic_file_write_iter+0x169/0x5e0 mm/filemap.c:3209 blkdev_write_iter+0x233/0x420 fs/block_dev.c:1908 call_write_iter include/linux/fs.h:1782 [inline] new_sync_write fs/read_write.c:474 [inline] __vfs_write+0x5bc/0x880 fs/read_write.c:487 vfs_write+0x1f8/0x560 fs/read_write.c:549 ksys_write+0xf9/0x250 fs/read_write.c:598 SYSC_write fs/read_write.c:610 [inline] SyS_write+0x24/0x30 fs/read_write.c:607 do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 RIP: 0033:0x445c59 RSP: 002b:7f76203b7d38 EFLAGS: 0293 ORIG_RAX: 0001 RAX: ffda RBX: 006dac24 RCX: 00445c59 RDX: 0050 RSI: 2400 RDI: 0008 RBP: 0005 R08: R09: R10: R11: 0293 R12: 006dac20 R13: 0006 R14: 0030656c69662f2e R15: Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a dumb bot. It may contain errors. See https://goo.gl/tpsmEJ for details. Direct all questions to syzkal...@googlegroups.com. syzbot will keep track of this bug report. If you forgot to add the Reported-by tag, once the fix for this bug is merged into any tree, please reply to this email with: #syz fix: exact-commit-title If you want to test a patch for this bug, please reply with: #syz test: git://repo/address.git branch and provide the patch inline or as an attachment. To mark this as a duplicate of another syzbot report, please reply with: #syz dup: exact-subject-of-another-report If it's a one-off invalid bug report, please reply with: #syz invalid Note: if the crash happens again, it will cause creation of a new bug report. Note: all commands must start from beginning of the line in the email body.
