- Kernel - mailweb.openeuler.org

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2023-52676
by Pu Lehui 21 May '24

21 May '24

Andrei Matei (2): bpf: Fix verification of indirect var-off stack access bpf: Guard stack limits against 32bit overflow kernel/bpf/verifier.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS-SP2] ext4: fix corruption during on-line resize
by Zhihao Cheng 21 May '24

21 May '24

From: Maximilian Heyne <mheyne(a)amazon.de> stable inclusion from stable-v5.10.215 commit e8e8b197317228b5089ed9e7802dadf3ccaa027a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9CF CVE: CVE-2024-35807 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc ] We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not. Fixes: 01f795f9e0d67 ("ext4: add online resizing support for meta_bg and 64-bit file systems") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> Tested-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Reviewed-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Link: https://lore.kernel.org/r/20240215155009.94493-1-mheyne@amazon.de Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/ext4/resize.c [ Commit 31f13421c004a420c("ext4: correct offset of gdb backup in non meta_bg group to update_backups") is not applied. ] Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/ext4/resize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index 58980c6acbc8..b433d28b76a5 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1548,7 +1548,8 @@ static int ext4_flex_group_add(struct super_block *sb, int gdb_num = group / EXT4_DESC_PER_BLOCK(sb); int gdb_num_end = ((group + flex_gd->count - 1) / EXT4_DESC_PER_BLOCK(sb)); - int meta_bg = ext4_has_feature_meta_bg(sb); + int meta_bg = ext4_has_feature_meta_bg(sb) && + gdb_num >= le32_to_cpu(es->s_first_meta_bg); sector_t old_gdb = 0; update_backups(sb, sbi->s_sbh->b_blocknr, (char *)es, -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ext4: fix corruption during on-line resize
by Zhihao Cheng 21 May '24

21 May '24

From: Maximilian Heyne <mheyne(a)amazon.de> stable inclusion from stable-v5.10.215 commit e8e8b197317228b5089ed9e7802dadf3ccaa027a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9CF CVE: CVE-2024-35807 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc ] We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not. Fixes: 01f795f9e0d67 ("ext4: add online resizing support for meta_bg and 64-bit file systems") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> Tested-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Reviewed-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Link: https://lore.kernel.org/r/20240215155009.94493-1-mheyne@amazon.de Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/ext4/resize.c [ Commit 31f13421c004a420c("ext4: correct offset of gdb backup in non meta_bg group to update_backups") is not applied. ] Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/ext4/resize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index 58980c6acbc8..b433d28b76a5 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1548,7 +1548,8 @@ static int ext4_flex_group_add(struct super_block *sb, int gdb_num = group / EXT4_DESC_PER_BLOCK(sb); int gdb_num_end = ((group + flex_gd->count - 1) / EXT4_DESC_PER_BLOCK(sb)); - int meta_bg = ext4_has_feature_meta_bg(sb); + int meta_bg = ext4_has_feature_meta_bg(sb) && + gdb_num >= le32_to_cpu(es->s_first_meta_bg); sector_t old_gdb = 0; update_backups(sb, sbi->s_sbh->b_blocknr, (char *)es, -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS] ext4: fix corruption during on-line resize
by Zhihao Cheng 21 May '24

21 May '24

From: Maximilian Heyne <mheyne(a)amazon.de> stable inclusion from stable-v5.10.215 commit e8e8b197317228b5089ed9e7802dadf3ccaa027a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9CF CVE: CVE-2024-35807 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc ] We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not. Fixes: 01f795f9e0d67 ("ext4: add online resizing support for meta_bg and 64-bit file systems") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> Tested-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Reviewed-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Link: https://lore.kernel.org/r/20240215155009.94493-1-mheyne@amazon.de Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/ext4/resize.c [ Commit 31f13421c004a420c("ext4: correct offset of gdb backup in non meta_bg group to update_backups") is not applied. ] Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/ext4/resize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index 58980c6acbc8..b433d28b76a5 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1548,7 +1548,8 @@ static int ext4_flex_group_add(struct super_block *sb, int gdb_num = group / EXT4_DESC_PER_BLOCK(sb); int gdb_num_end = ((group + flex_gd->count - 1) / EXT4_DESC_PER_BLOCK(sb)); - int meta_bg = ext4_has_feature_meta_bg(sb); + int meta_bg = ext4_has_feature_meta_bg(sb) && + gdb_num >= le32_to_cpu(es->s_first_meta_bg); sector_t old_gdb = 0; update_backups(sb, sbi->s_sbh->b_blocknr, (char *)es, -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS 0/2] CVE-2023-52676
by Pu Lehui 21 May '24

21 May '24

Andrei Matei (2): bpf: Fix verification of indirect var-off stack access bpf: Guard stack limits against 32bit overflow kernel/bpf/verifier.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS] Bluetooth: af_bluetooth: Fix deadlock
by Li Huafei 21 May '24

21 May '24

From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> mainline inclusion from mainline-v6.9-rc1 commit f7b94bdc1ec107c92262716b073b3e816d4784fb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK0R CVE: CVE-2024-26886 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Attemting to do sock_lock on .recvmsg may cause a deadlock as shown bellow, so instead of using sock_sock this uses sk_receive_queue.lock on bt_sock_ioctl to avoid the UAF: INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183 Workqueue: hci0 hci_rx_work Call Trace: <TASK> __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Fixes: 2e07e8348ea4 ("Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Conflicts: net/bluetooth/af_bluetooth.c [ The conflict occurred because commit f4b41f062c42 ("net: remove noblock parameter from skb_recv_datagram()") and b8ddc3b14c7a ("Bluetooth: fix indentation and alignment reported by checkpatch") were not merged. ] Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- net/bluetooth/af_bluetooth.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c index 363f85c617bbc..0bd7ad4e72dc6 100644 --- a/net/bluetooth/af_bluetooth.c +++ b/net/bluetooth/af_bluetooth.c @@ -263,14 +263,11 @@ int bt_sock_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, if (flags & MSG_OOB) return -EOPNOTSUPP; - lock_sock(sk); - skb = skb_recv_datagram(sk, flags, noblock, &err); if (!skb) { if (sk->sk_shutdown & RCV_SHUTDOWN) err = 0; - release_sock(sk); return err; } @@ -293,8 +290,6 @@ int bt_sock_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, skb_free_datagram(sk, skb); - release_sock(sk); - if (flags & MSG_TRUNC) copied = skblen; @@ -519,10 +514,11 @@ int bt_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg) if (sk->sk_state == BT_LISTEN) return -EINVAL; - lock_sock(sk); + spin_lock(&sk->sk_receive_queue.lock); skb = skb_peek(&sk->sk_receive_queue); amount = skb ? skb->len : 0; - release_sock(sk); + spin_unlock(&sk->sk_receive_queue.lock); + err = put_user(amount, (int __user *) arg); break; -- 2.25.1

2 1

[PATCH OLK-5.10] Bluetooth: af_bluetooth: Fix deadlock
by Li Huafei 21 May '24

21 May '24

From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> mainline inclusion from mainline-v6.9-rc1 commit f7b94bdc1ec107c92262716b073b3e816d4784fb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HK0R CVE: CVE-2024-26886 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Attemting to do sock_lock on .recvmsg may cause a deadlock as shown bellow, so instead of using sock_sock this uses sk_receive_queue.lock on bt_sock_ioctl to avoid the UAF: INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183 Workqueue: hci0 hci_rx_work Call Trace: <TASK> __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Fixes: 2e07e8348ea4 ("Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Conflicts: net/bluetooth/af_bluetooth.c [ The conflict occurred because commit f4b41f062c42 ("net: remove noblock parameter from skb_recv_datagram()") and b8ddc3b14c7a ("Bluetooth: fix indentation and alignment reported by checkpatch") were not merged. ] Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- net/bluetooth/af_bluetooth.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c index 14a917e70f3ee..bb648d2a14fbb 100644 --- a/net/bluetooth/af_bluetooth.c +++ b/net/bluetooth/af_bluetooth.c @@ -263,14 +263,11 @@ int bt_sock_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, if (flags & MSG_OOB) return -EOPNOTSUPP; - lock_sock(sk); - skb = skb_recv_datagram(sk, flags, noblock, &err); if (!skb) { if (sk->sk_shutdown & RCV_SHUTDOWN) err = 0; - release_sock(sk); return err; } @@ -296,8 +293,6 @@ int bt_sock_recvmsg(struct socket *sock, struct msghdr *msg, size_t len, skb_free_datagram(sk, skb); - release_sock(sk); - if (flags & MSG_TRUNC) copied = skblen; @@ -520,10 +515,11 @@ int bt_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg) if (sk->sk_state == BT_LISTEN) return -EINVAL; - lock_sock(sk); + spin_lock(&sk->sk_receive_queue.lock); skb = skb_peek(&sk->sk_receive_queue); amount = skb ? skb->len : 0; - release_sock(sk); + spin_unlock(&sk->sk_receive_queue.lock); + err = put_user(amount, (int __user *) arg); break; -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] ext4: fix corruption during on-line resize
by Zhihao Cheng 21 May '24

21 May '24

From: Maximilian Heyne <mheyne(a)amazon.de> stable inclusion from stable-v5.10.215 commit e8e8b197317228b5089ed9e7802dadf3ccaa027a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q9CF CVE: CVE-2024-35807 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc ] We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not. Fixes: 01f795f9e0d67 ("ext4: add online resizing support for meta_bg and 64-bit file systems") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maximilian Heyne <mheyne(a)amazon.de> Tested-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Reviewed-by: Srivathsa Dara <srivathsa.d.dara(a)oracle.com> Link: https://lore.kernel.org/r/20240215155009.94493-1-mheyne@amazon.de Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/ext4/resize.c [ Commit 31f13421c004a420c("ext4: correct offset of gdb backup in non meta_bg group to update_backups") is not applied. ] Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com> --- fs/ext4/resize.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index 767cbebf04ee..eb10a43b1498 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1558,7 +1558,8 @@ static int ext4_flex_group_add(struct super_block *sb, int gdb_num = group / EXT4_DESC_PER_BLOCK(sb); int gdb_num_end = ((group + flex_gd->count - 1) / EXT4_DESC_PER_BLOCK(sb)); - int meta_bg = ext4_has_feature_meta_bg(sb); + int meta_bg = ext4_has_feature_meta_bg(sb) && + gdb_num >= le32_to_cpu(es->s_first_meta_bg); sector_t old_gdb = 0; update_backups(sb, sbi->s_sbh->b_blocknr, (char *)es, -- 2.31.1

1 0

[PATCH openEuler-22.03-LTS-SP2 0/2] CVE-2023-52676
by Pu Lehui 21 May '24

21 May '24

Andrei Matei (2): bpf: Fix verification of indirect var-off stack access bpf: Guard stack limits against 32bit overflow kernel/bpf/verifier.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2023-52676
by Pu Lehui 21 May '24

21 May '24

Andrei Matei (2): bpf: Fix verification of indirect var-off stack access bpf: Guard stack limits against 32bit overflow kernel/bpf/verifier.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) -- 2.34.1

2 3