July 2021 - Linux-stable-mirror

FAILED: patch "[PATCH] can: raw: raw_setsockopt(): fix raw_rcv panic for sock UAF" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 54f93336d000229f72c26d8a3f69dd256b744528 Mon Sep 17 00:00:00 2001 From: Ziyang Xuan <william.xuanziyang(a)huawei.com> Date: Thu, 22 Jul 2021 15:08:19 +0800 Subject: [PATCH] can: raw: raw_setsockopt(): fix raw_rcv panic for sock UAF We get a bug during ltp can_filter test as following. =========================================== [60919.264984] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [60919.265223] PGD 8000003dda726067 P4D 8000003dda726067 PUD 3dda727067 PMD 0 [60919.265443] Oops: 0000 [#1] SMP PTI [60919.265550] CPU: 30 PID: 3638365 Comm: can_filter Kdump: loaded Tainted: G W 4.19.90+ #1 [60919.266068] RIP: 0010:selinux_socket_sock_rcv_skb+0x3e/0x200 [60919.293289] RSP: 0018:ffff8d53bfc03cf8 EFLAGS: 00010246 [60919.307140] RAX: 0000000000000000 RBX: 000000000000001d RCX: 0000000000000007 [60919.320756] RDX: 0000000000000001 RSI: ffff8d5104a8ed00 RDI: ffff8d53bfc03d30 [60919.334319] RBP: ffff8d9338056800 R08: ffff8d53bfc29d80 R09: 0000000000000001 [60919.347969] R10: ffff8d53bfc03ec0 R11: ffffb8526ef47c98 R12: ffff8d53bfc03d30 [60919.350320] perf: interrupt took too long (3063 > 2500), lowering kernel.perf_event_max_sample_rate to 65000 [60919.361148] R13: 0000000000000001 R14: ffff8d53bcf90000 R15: 0000000000000000 [60919.361151] FS: 00007fb78b6b3600(0000) GS:ffff8d53bfc00000(0000) knlGS:0000000000000000 [60919.400812] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [60919.413730] CR2: 0000000000000010 CR3: 0000003e3f784006 CR4: 00000000007606e0 [60919.426479] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [60919.439339] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [60919.451608] PKRU: 55555554 [60919.463622] Call Trace: [60919.475617] <IRQ> [60919.487122] ? update_load_avg+0x89/0x5d0 [60919.498478] ? update_load_avg+0x89/0x5d0 [60919.509822] ? account_entity_enqueue+0xc5/0xf0 [60919.520709] security_sock_rcv_skb+0x2a/0x40 [60919.531413] sk_filter_trim_cap+0x47/0x1b0 [60919.542178] ? kmem_cache_alloc+0x38/0x1b0 [60919.552444] sock_queue_rcv_skb+0x17/0x30 [60919.562477] raw_rcv+0x110/0x190 [can_raw] [60919.572539] can_rcv_filter+0xbc/0x1b0 [can] [60919.582173] can_receive+0x6b/0xb0 [can] [60919.591595] can_rcv+0x31/0x70 [can] [60919.600783] __netif_receive_skb_one_core+0x5a/0x80 [60919.609864] process_backlog+0x9b/0x150 [60919.618691] net_rx_action+0x156/0x400 [60919.627310] ? sched_clock_cpu+0xc/0xa0 [60919.635714] __do_softirq+0xe8/0x2e9 [60919.644161] do_softirq_own_stack+0x2a/0x40 [60919.652154] </IRQ> [60919.659899] do_softirq.part.17+0x4f/0x60 [60919.667475] __local_bh_enable_ip+0x60/0x70 [60919.675089] __dev_queue_xmit+0x539/0x920 [60919.682267] ? finish_wait+0x80/0x80 [60919.689218] ? finish_wait+0x80/0x80 [60919.695886] ? sock_alloc_send_pskb+0x211/0x230 [60919.702395] ? can_send+0xe5/0x1f0 [can] [60919.708882] can_send+0xe5/0x1f0 [can] [60919.715037] raw_sendmsg+0x16d/0x268 [can_raw] It's because raw_setsockopt() concurrently with unregister_netdevice_many(). Concurrent scenario as following. cpu0 cpu1 raw_bind raw_setsockopt unregister_netdevice_many unlist_netdevice dev_get_by_index raw_notifier raw_enable_filters ...... can_rx_register can_rcv_list_find(..., net->can.rx_alldev_list) ...... sock_close raw_release(sock_a) ...... can_receive can_rcv_filter(net->can.rx_alldev_list, ...) raw_rcv(skb, sock_a) BUG After unlist_netdevice(), dev_get_by_index() return NULL in raw_setsockopt(). Function raw_enable_filters() will add sock and can_filter to net->can.rx_alldev_list. Then the sock is closed. Followed by, we sock_sendmsg() to a new vcan device use the same can_filter. Protocol stack match the old receiver whose sock has been released on net->can.rx_alldev_list in can_rcv_filter(). Function raw_rcv() uses the freed sock. UAF BUG is triggered. We can find that the key issue is that net_device has not been protected in raw_setsockopt(). Use rtnl_lock to protect net_device in raw_setsockopt(). Fixes: c18ce101f2e4 ("[CAN]: Add raw protocol") Link: https://lore.kernel.org/r/20210722070819.1048263-1-william.xuanziyang@huawe… Cc: linux-stable <stable(a)vger.kernel.org> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> Acked-by: Oliver Hartkopp <socketcan(a)hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> diff --git a/net/can/raw.c b/net/can/raw.c index ed4fcb7ab0c3..cd5a49380116 100644 --- a/net/can/raw.c +++ b/net/can/raw.c @@ -546,10 +546,18 @@ static int raw_setsockopt(struct socket *sock, int level, int optname, return -EFAULT; } + rtnl_lock(); lock_sock(sk); - if (ro->bound && ro->ifindex) + if (ro->bound && ro->ifindex) { dev = dev_get_by_index(sock_net(sk), ro->ifindex); + if (!dev) { + if (count > 1) + kfree(filter); + err = -ENODEV; + goto out_fil; + } + } if (ro->bound) { /* (try to) register the new filters */ @@ -588,6 +596,7 @@ static int raw_setsockopt(struct socket *sock, int level, int optname, dev_put(dev); release_sock(sk); + rtnl_unlock(); break; @@ -600,10 +609,16 @@ static int raw_setsockopt(struct socket *sock, int level, int optname, err_mask &= CAN_ERR_MASK; + rtnl_lock(); lock_sock(sk); - if (ro->bound && ro->ifindex) + if (ro->bound && ro->ifindex) { dev = dev_get_by_index(sock_net(sk), ro->ifindex); + if (!dev) { + err = -ENODEV; + goto out_err; + } + } /* remove current error mask */ if (ro->bound) { @@ -627,6 +642,7 @@ static int raw_setsockopt(struct socket *sock, int level, int optname, dev_put(dev); release_sock(sk); + rtnl_unlock(); break;

3 years, 4 months

1
0
0 0

stable-rc/queue/4.19 baseline: 120 runs, 3 regressions (v4.19.199-3-g72fd65069bfc)

by kernelci.org bot

stable-rc/queue/4.19 baseline: 120 runs, 3 regressions (v4.19.199-3-g72fd65069bfc) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ---------------------+------+---------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-baylibre | gcc-8 | versatile_defconfig | 1 qemu_arm-versatilepb | arm | lab-cip | gcc-8 | versatile_defconfig | 1 qemu_arm-versatilepb | arm | lab-collabora | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.19/kernel/v4.19.19… Test: baseline Tree: stable-rc Branch: queue/4.19 Describe: v4.19.199-3-g72fd65069bfc URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 72fd65069bfc6f13130e7c1c778a5569732ca180 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ---------------------+------+---------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-baylibre | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/6104b7493a4a05411285f463 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.199-3-g72fd65069bf… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.199-3-g72fd65069bf… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b7… * baseline.login: https://kernelci.org/test/case/id/6104b7493a4a05411285f464 failing since 259 days (last pass: v4.19.157-26-gd59f3161b3a0, first fail: v4.19.157-27-g5543cc2c41d55) platform | arch | lab | compiler | defconfig | regressions ---------------------+------+---------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-cip | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/6104b739664240971b85f45a Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.199-3-g72fd65069bf… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.199-3-g72fd65069bf… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b7… * baseline.login: https://kernelci.org/test/case/id/6104b739664240971b85f45b failing since 259 days (last pass: v4.19.157-26-gd59f3161b3a0, first fail: v4.19.157-27-g5543cc2c41d55) platform | arch | lab | compiler | defconfig | regressions ---------------------+------+---------------+----------+---------------------+------------ qemu_arm-versatilepb | arm | lab-collabora | gcc-8 | versatile_defconfig | 1 Details: https://kernelci.org/test/plan/id/6104c42df64ade7cff85f45a Results: 0 PASS, 1 FAIL, 0 SKIP Full config: versatile_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.199-3-g72fd65069bf… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.199-3-g72fd65069bf… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b7… * baseline.login: https://kernelci.org/test/case/id/6104c42df64ade7cff85f45b failing since 259 days (last pass: v4.19.157-26-gd59f3161b3a0, first fail: v4.19.157-27-g5543cc2c41d55)

3 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: fix lost inode on log replay after mix of fsync, " failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From ecc64fab7d49c678e70bd4c35fe64d2ab3e3d212 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Tue, 27 Jul 2021 11:24:43 +0100 Subject: [PATCH] btrfs: fix lost inode on log replay after mix of fsync, rename and inode eviction When checking if we need to log the new name of a renamed inode, we are checking if the inode and its parent inode have been logged before, and if not we don't log the new name. The check however is buggy, as it directly compares the logged_trans field of the inodes versus the ID of the current transaction. The problem is that logged_trans is a transient field, only stored in memory and never persisted in the inode item, so if an inode was logged before, evicted and reloaded, its logged_trans field is set to a value of 0, meaning the check will return false and the new name of the renamed inode is not logged. If the old parent directory was previously fsynced and we deleted the logged directory entries corresponding to the old name, we end up with a log that when replayed will delete the renamed inode. The following example triggers the problem: $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt $ mkdir /mnt/A $ mkdir /mnt/B $ echo -n "hello world" > /mnt/A/foo $ sync # Add some new file to A and fsync directory A. $ touch /mnt/A/bar $ xfs_io -c "fsync" /mnt/A # Now trigger inode eviction. We are only interested in triggering # eviction for the inode of directory A. $ echo 2 > /proc/sys/vm/drop_caches # Move foo from directory A to directory B. # This deletes the directory entries for foo in A from the log, and # does not add the new name for foo in directory B to the log, because # logged_trans of A is 0, which is less than the current transaction ID. $ mv /mnt/A/foo /mnt/B/foo # Now make an fsync to anything except A, B or any file inside them, # like for example create a file at the root directory and fsync this # new file. This syncs the log that contains all the changes done by # previous rename operation. $ touch /mnt/baz $ xfs_io -c "fsync" /mnt/baz <power fail> # Mount the filesystem and replay the log. $ mount /dev/sdc /mnt # Check the filesystem content. $ ls -1R /mnt /mnt/: A B baz /mnt/A: bar /mnt/B: $ # File foo is gone, it's neither in A/ nor in B/. Fix this by using the inode_logged() helper at btrfs_log_new_name(), which safely checks if an inode was logged before in the current transaction. A test case for fstests will follow soon. CC: stable(a)vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c index 9fd0348be7f5..e6430ac9bbe8 100644 --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -6503,8 +6503,8 @@ void btrfs_log_new_name(struct btrfs_trans_handle *trans, * if this inode hasn't been logged and directory we're renaming it * from hasn't been logged, we don't need to log it */ - if (inode->logged_trans < trans->transid && - (!old_dir || old_dir->logged_trans < trans->transid)) + if (!inode_logged(trans, inode) && + (!old_dir || !inode_logged(trans, old_dir))) return; /*

3 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: fix lost inode on log replay after mix of fsync, " failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From ecc64fab7d49c678e70bd4c35fe64d2ab3e3d212 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Tue, 27 Jul 2021 11:24:43 +0100 Subject: [PATCH] btrfs: fix lost inode on log replay after mix of fsync, rename and inode eviction When checking if we need to log the new name of a renamed inode, we are checking if the inode and its parent inode have been logged before, and if not we don't log the new name. The check however is buggy, as it directly compares the logged_trans field of the inodes versus the ID of the current transaction. The problem is that logged_trans is a transient field, only stored in memory and never persisted in the inode item, so if an inode was logged before, evicted and reloaded, its logged_trans field is set to a value of 0, meaning the check will return false and the new name of the renamed inode is not logged. If the old parent directory was previously fsynced and we deleted the logged directory entries corresponding to the old name, we end up with a log that when replayed will delete the renamed inode. The following example triggers the problem: $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt $ mkdir /mnt/A $ mkdir /mnt/B $ echo -n "hello world" > /mnt/A/foo $ sync # Add some new file to A and fsync directory A. $ touch /mnt/A/bar $ xfs_io -c "fsync" /mnt/A # Now trigger inode eviction. We are only interested in triggering # eviction for the inode of directory A. $ echo 2 > /proc/sys/vm/drop_caches # Move foo from directory A to directory B. # This deletes the directory entries for foo in A from the log, and # does not add the new name for foo in directory B to the log, because # logged_trans of A is 0, which is less than the current transaction ID. $ mv /mnt/A/foo /mnt/B/foo # Now make an fsync to anything except A, B or any file inside them, # like for example create a file at the root directory and fsync this # new file. This syncs the log that contains all the changes done by # previous rename operation. $ touch /mnt/baz $ xfs_io -c "fsync" /mnt/baz <power fail> # Mount the filesystem and replay the log. $ mount /dev/sdc /mnt # Check the filesystem content. $ ls -1R /mnt /mnt/: A B baz /mnt/A: bar /mnt/B: $ # File foo is gone, it's neither in A/ nor in B/. Fix this by using the inode_logged() helper at btrfs_log_new_name(), which safely checks if an inode was logged before in the current transaction. A test case for fstests will follow soon. CC: stable(a)vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c index 9fd0348be7f5..e6430ac9bbe8 100644 --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -6503,8 +6503,8 @@ void btrfs_log_new_name(struct btrfs_trans_handle *trans, * if this inode hasn't been logged and directory we're renaming it * from hasn't been logged, we don't need to log it */ - if (inode->logged_trans < trans->transid && - (!old_dir || old_dir->logged_trans < trans->transid)) + if (!inode_logged(trans, inode) && + (!old_dir || !inode_logged(trans, old_dir))) return; /*

3 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: fix lost inode on log replay after mix of fsync, " failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From ecc64fab7d49c678e70bd4c35fe64d2ab3e3d212 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Tue, 27 Jul 2021 11:24:43 +0100 Subject: [PATCH] btrfs: fix lost inode on log replay after mix of fsync, rename and inode eviction When checking if we need to log the new name of a renamed inode, we are checking if the inode and its parent inode have been logged before, and if not we don't log the new name. The check however is buggy, as it directly compares the logged_trans field of the inodes versus the ID of the current transaction. The problem is that logged_trans is a transient field, only stored in memory and never persisted in the inode item, so if an inode was logged before, evicted and reloaded, its logged_trans field is set to a value of 0, meaning the check will return false and the new name of the renamed inode is not logged. If the old parent directory was previously fsynced and we deleted the logged directory entries corresponding to the old name, we end up with a log that when replayed will delete the renamed inode. The following example triggers the problem: $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt $ mkdir /mnt/A $ mkdir /mnt/B $ echo -n "hello world" > /mnt/A/foo $ sync # Add some new file to A and fsync directory A. $ touch /mnt/A/bar $ xfs_io -c "fsync" /mnt/A # Now trigger inode eviction. We are only interested in triggering # eviction for the inode of directory A. $ echo 2 > /proc/sys/vm/drop_caches # Move foo from directory A to directory B. # This deletes the directory entries for foo in A from the log, and # does not add the new name for foo in directory B to the log, because # logged_trans of A is 0, which is less than the current transaction ID. $ mv /mnt/A/foo /mnt/B/foo # Now make an fsync to anything except A, B or any file inside them, # like for example create a file at the root directory and fsync this # new file. This syncs the log that contains all the changes done by # previous rename operation. $ touch /mnt/baz $ xfs_io -c "fsync" /mnt/baz <power fail> # Mount the filesystem and replay the log. $ mount /dev/sdc /mnt # Check the filesystem content. $ ls -1R /mnt /mnt/: A B baz /mnt/A: bar /mnt/B: $ # File foo is gone, it's neither in A/ nor in B/. Fix this by using the inode_logged() helper at btrfs_log_new_name(), which safely checks if an inode was logged before in the current transaction. A test case for fstests will follow soon. CC: stable(a)vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c index 9fd0348be7f5..e6430ac9bbe8 100644 --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -6503,8 +6503,8 @@ void btrfs_log_new_name(struct btrfs_trans_handle *trans, * if this inode hasn't been logged and directory we're renaming it * from hasn't been logged, we don't need to log it */ - if (inode->logged_trans < trans->transid && - (!old_dir || old_dir->logged_trans < trans->transid)) + if (!inode_logged(trans, inode) && + (!old_dir || !inode_logged(trans, old_dir))) return; /*

3 years, 4 months

1
0
0 0

FAILED: patch "[PATCH] btrfs: fix lost inode on log replay after mix of fsync, " failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From ecc64fab7d49c678e70bd4c35fe64d2ab3e3d212 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Tue, 27 Jul 2021 11:24:43 +0100 Subject: [PATCH] btrfs: fix lost inode on log replay after mix of fsync, rename and inode eviction When checking if we need to log the new name of a renamed inode, we are checking if the inode and its parent inode have been logged before, and if not we don't log the new name. The check however is buggy, as it directly compares the logged_trans field of the inodes versus the ID of the current transaction. The problem is that logged_trans is a transient field, only stored in memory and never persisted in the inode item, so if an inode was logged before, evicted and reloaded, its logged_trans field is set to a value of 0, meaning the check will return false and the new name of the renamed inode is not logged. If the old parent directory was previously fsynced and we deleted the logged directory entries corresponding to the old name, we end up with a log that when replayed will delete the renamed inode. The following example triggers the problem: $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt $ mkdir /mnt/A $ mkdir /mnt/B $ echo -n "hello world" > /mnt/A/foo $ sync # Add some new file to A and fsync directory A. $ touch /mnt/A/bar $ xfs_io -c "fsync" /mnt/A # Now trigger inode eviction. We are only interested in triggering # eviction for the inode of directory A. $ echo 2 > /proc/sys/vm/drop_caches # Move foo from directory A to directory B. # This deletes the directory entries for foo in A from the log, and # does not add the new name for foo in directory B to the log, because # logged_trans of A is 0, which is less than the current transaction ID. $ mv /mnt/A/foo /mnt/B/foo # Now make an fsync to anything except A, B or any file inside them, # like for example create a file at the root directory and fsync this # new file. This syncs the log that contains all the changes done by # previous rename operation. $ touch /mnt/baz $ xfs_io -c "fsync" /mnt/baz <power fail> # Mount the filesystem and replay the log. $ mount /dev/sdc /mnt # Check the filesystem content. $ ls -1R /mnt /mnt/: A B baz /mnt/A: bar /mnt/B: $ # File foo is gone, it's neither in A/ nor in B/. Fix this by using the inode_logged() helper at btrfs_log_new_name(), which safely checks if an inode was logged before in the current transaction. A test case for fstests will follow soon. CC: stable(a)vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c index 9fd0348be7f5..e6430ac9bbe8 100644 --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -6503,8 +6503,8 @@ void btrfs_log_new_name(struct btrfs_trans_handle *trans, * if this inode hasn't been logged and directory we're renaming it * from hasn't been logged, we don't need to log it */ - if (inode->logged_trans < trans->transid && - (!old_dir || old_dir->logged_trans < trans->transid)) + if (!inode_logged(trans, inode) && + (!old_dir || !inode_logged(trans, old_dir))) return; /*

3 years, 4 months

1
0
0 0

Patch "Kernel oopses on ext2 filesystems after 782b76d7abdf"

by Javier Pello

Dear list, The current 5.13 stable kernel branch oopses when handling ext2 filesystems, and the filesystem is not usable, sometimes leading to a panic. The bug was introduced during the 5.13 development cycle. A complete analysis can be found here: https://lore.kernel.org/linux-ext4/20210713165821.8a268e2c1db4fd5cf452acd2@… A fix for this bug has been recently merged into the mainline kernel, with commit id 728d392f8a799f037812d0f2b254fb3b5e115fcf. The 5.13 branch is the only one affected by this bug. Best regards, Javier

3 years, 4 months

2
1
0 0

stable-rc/queue/4.14 baseline: 90 runs, 1 regressions (v4.14.241-16-g69e247082971)

by kernelci.org bot

stable-rc/queue/4.14 baseline: 90 runs, 1 regressions (v4.14.241-16-g69e247082971) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ----------+------+---------+----------+--------------------+------------ imx7d-sdb | arm | lab-nxp | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.14/kernel/v4.14.24… Test: baseline Tree: stable-rc Branch: queue/4.14 Describe: v4.14.241-16-g69e247082971 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 69e247082971400fcb7164b1f39580e0e0c8cf3c Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ----------+------+---------+----------+--------------------+------------ imx7d-sdb | arm | lab-nxp | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/6104b07d846cca810e85f478 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.241-16-g69e2470829… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.241-16-g69e2470829… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-6-g8983f3b7… * baseline.login: https://kernelci.org/test/case/id/6104b07d846cca810e85f479 new failure (last pass: v4.14.241-13-g64ab6520c0fe)

3 years, 4 months

1
0
0 0

[PATCH 5.13 00/22] 5.13.7-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.13.7 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat, 31 Jul 2021 13:51:22 +0000. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.13.7-rc1… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.13.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 5.13.7-rc1 Vasily Averin <vvs(a)virtuozzo.com> ipv6: ip6_finish_output2: set sk into newly allocated nskb Sudeep Holla <sudeep.holla(a)arm.com> ARM: dts: versatile: Fix up interrupt controller node names Christoph Hellwig <hch(a)lst.de> iomap: remove the length variable in iomap_seek_hole Christoph Hellwig <hch(a)lst.de> iomap: remove the length variable in iomap_seek_data Hyunchul Lee <hyc.lee(a)gmail.com> cifs: fix the out of range assignment to bit fields in parse_server_interfaces Cristian Marussi <cristian.marussi(a)arm.com> firmware: arm_scmi: Fix range check for the maximum number of pending messages Sudeep Holla <sudeep.holla(a)arm.com> firmware: arm_scmi: Fix possible scmi_linux_errmap buffer overflow Desmond Cheong Zhi Xi <desmondcheongzx(a)gmail.com> hfs: add lock nesting notation to hfs_find_init Desmond Cheong Zhi Xi <desmondcheongzx(a)gmail.com> hfs: fix high memory mapping in hfs_bnode_read Desmond Cheong Zhi Xi <desmondcheongzx(a)gmail.com> hfs: add missing clean-up in hfs_fill_super Zheyu Ma <zheyuma97(a)gmail.com> drm/ttm: add a check against null pointer dereference Casey Chen <cachen(a)purestorage.com> nvme-pci: fix multiple races in nvme_setup_io_queues Vasily Averin <vvs(a)virtuozzo.com> ipv6: allocate enough headroom in ip6_finish_output2() Paul E. McKenney <paulmck(a)kernel.org> rcu-tasks: Don't delete holdouts within trc_wait_for_one_reader() Paul E. McKenney <paulmck(a)kernel.org> rcu-tasks: Don't delete holdouts within trc_inspect_reader() Xin Long <lucien.xin(a)gmail.com> sctp: move 198 addresses from unusable to private scope Eric Dumazet <edumazet(a)google.com> net: annotate data race around sk_ll_usec Yang Yingliang <yangyingliang(a)huawei.com> net/802/garp: fix memleak in garp_request_join() Yang Yingliang <yangyingliang(a)huawei.com> net/802/mrp: fix memleak in mrp_request_join() Paul Gortmaker <paul.gortmaker(a)windriver.com> cgroup1: fix leaked context root causing sporadic NULL deref in LTP Yang Yingliang <yangyingliang(a)huawei.com> workqueue: fix UAF in pwq_unbound_release_workfn() Miklos Szeredi <mszeredi(a)redhat.com> af_unix: fix garbage collect vs MSG_PEEK ------------- Diffstat: Makefile | 4 +- arch/arm/boot/dts/versatile-ab.dts | 5 +-- arch/arm/boot/dts/versatile-pb.dts | 2 +- drivers/firmware/arm_scmi/driver.c | 12 +++--- drivers/gpu/drm/ttm/ttm_range_manager.c | 3 ++ drivers/nvme/host/pci.c | 66 +++++++++++++++++++++++++++++---- fs/cifs/smb2ops.c | 4 +- fs/hfs/bfind.c | 14 ++++++- fs/hfs/bnode.c | 25 ++++++++++--- fs/hfs/btree.h | 7 ++++ fs/hfs/super.c | 10 ++--- fs/internal.h | 1 - fs/iomap/seek.c | 25 +++++-------- include/linux/fs_context.h | 1 + include/net/busy_poll.h | 2 +- include/net/sctp/constants.h | 4 +- kernel/cgroup/cgroup-v1.c | 4 +- kernel/rcu/tasks.h | 6 +-- kernel/workqueue.c | 20 ++++++---- net/802/garp.c | 14 +++++++ net/802/mrp.c | 14 +++++++ net/core/sock.c | 2 +- net/ipv6/ip6_output.c | 28 ++++++++++++++ net/sctp/protocol.c | 3 +- net/unix/af_unix.c | 51 ++++++++++++++++++++++++- 25 files changed, 256 insertions(+), 71 deletions(-)

3 years, 4 months

8
29
0 0

[PATCH 5.4 00/21] 5.4.137-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.4.137 release. There are 21 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat, 31 Jul 2021 13:51:22 +0000. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.137-rc… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 5.4.137-rc1 Vasily Averin <vvs(a)virtuozzo.com> ipv6: ip6_finish_output2: set sk into newly allocated nskb Sudeep Holla <sudeep.holla(a)arm.com> ARM: dts: versatile: Fix up interrupt controller node names Christoph Hellwig <hch(a)lst.de> iomap: remove the length variable in iomap_seek_hole Christoph Hellwig <hch(a)lst.de> iomap: remove the length variable in iomap_seek_data Hyunchul Lee <hyc.lee(a)gmail.com> cifs: fix the out of range assignment to bit fields in parse_server_interfaces Cristian Marussi <cristian.marussi(a)arm.com> firmware: arm_scmi: Fix range check for the maximum number of pending messages Sudeep Holla <sudeep.holla(a)arm.com> firmware: arm_scmi: Fix possible scmi_linux_errmap buffer overflow Desmond Cheong Zhi Xi <desmondcheongzx(a)gmail.com> hfs: add lock nesting notation to hfs_find_init Desmond Cheong Zhi Xi <desmondcheongzx(a)gmail.com> hfs: fix high memory mapping in hfs_bnode_read Desmond Cheong Zhi Xi <desmondcheongzx(a)gmail.com> hfs: add missing clean-up in hfs_fill_super Vasily Averin <vvs(a)virtuozzo.com> ipv6: allocate enough headroom in ip6_finish_output2() Xin Long <lucien.xin(a)gmail.com> sctp: move 198 addresses from unusable to private scope Eric Dumazet <edumazet(a)google.com> net: annotate data race around sk_ll_usec Yang Yingliang <yangyingliang(a)huawei.com> net/802/garp: fix memleak in garp_request_join() Yang Yingliang <yangyingliang(a)huawei.com> net/802/mrp: fix memleak in mrp_request_join() Paul Gortmaker <paul.gortmaker(a)windriver.com> cgroup1: fix leaked context root causing sporadic NULL deref in LTP Yang Yingliang <yangyingliang(a)huawei.com> workqueue: fix UAF in pwq_unbound_release_workfn() Miklos Szeredi <mszeredi(a)redhat.com> af_unix: fix garbage collect vs MSG_PEEK Maxim Levitsky <mlevitsk(a)redhat.com> KVM: x86: determine if an exception has an error code only when injecting it. Yonghong Song <yhs(a)fb.com> tools: Allow proper CC/CXX/... override with LLVM=1 in Makefile.include Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> selftest: fix build error in tools/testing/selftests/vm/userfaultfd.c ------------- Diffstat: Makefile | 4 +-- arch/arm/boot/dts/versatile-ab.dts | 5 ++-- arch/arm/boot/dts/versatile-pb.dts | 2 +- arch/x86/kvm/x86.c | 13 +++++--- drivers/firmware/arm_scmi/driver.c | 12 ++++---- fs/cifs/smb2ops.c | 4 +-- fs/hfs/bfind.c | 14 ++++++++- fs/hfs/bnode.c | 25 ++++++++++++---- fs/hfs/btree.h | 7 +++++ fs/hfs/super.c | 10 +++---- fs/internal.h | 1 - fs/iomap/seek.c | 25 ++++++---------- include/linux/fs_context.h | 1 + include/net/busy_poll.h | 2 +- include/net/sctp/constants.h | 4 +-- kernel/cgroup/cgroup-v1.c | 4 +-- kernel/workqueue.c | 20 ++++++++----- net/802/garp.c | 14 +++++++++ net/802/mrp.c | 14 +++++++++ net/core/sock.c | 2 +- net/ipv6/ip6_output.c | 28 ++++++++++++++++++ net/sctp/protocol.c | 3 +- net/unix/af_unix.c | 51 ++++++++++++++++++++++++++++++-- tools/scripts/Makefile.include | 12 ++++++-- tools/testing/selftests/vm/userfaultfd.c | 2 +- 25 files changed, 213 insertions(+), 66 deletions(-)

3 years, 4 months

7
27
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2021