- 20 7月, 2023 4 次提交
-
-
由 Li Lingfeng 提交于
mainline inclusion from mainline-v6.4-rc8 commit 2760904d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7FI78 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.4-rc7&id=2760904d895279f87196f0fa9ec570c79fe6a2e4 ---------------------------------------- As described in commit 38d11da5 ("dm: don't lock fs when the map is NULL in process of resume"), a deadlock may be triggered between do_resume() and do_mount(). This commit preserves the fix from commit 38d11da5 but moves it to where it also serves to fix a similar deadlock between do_suspend() and do_mount(). It does so, if the active map is NULL, by clearing DM_SUSPEND_LOCKFS_FLAG in dm_suspend() which is called by both do_suspend() and do_resume(). Fixes: 38d11da5 ("dm: don't lock fs when the map is NULL in process of resume") Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> Signed-off-by: NMike Snitzer <snitzer@kernel.org> Conflicts: drivers/md/dm-ioctl.c Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> (cherry picked from commit 0ba9dcd9)
-
由 Li Lingfeng 提交于
mainline inclusion from mainline-v6.4-rc1 commit 38d11da5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7FI78 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.4&id=38d11da522aacaa05898c734a1cec86f1e611129 ---------------------------------------- Commit fa247089 ("dm: requeue IO if mapping table not yet available") added a detection of whether the mapping table is available in the IO submission process. If the mapping table is unavailable, it returns BLK_STS_RESOURCE and requeues the IO. This can lead to the following deadlock problem: dm create mount ioctl(DM_DEV_CREATE_CMD) ioctl(DM_TABLE_LOAD_CMD) do_mount vfs_get_tree ext4_get_tree get_tree_bdev sget_fc alloc_super // got &s->s_umount down_write_nested(&s->s_umount, ...); ext4_fill_super ext4_load_super ext4_read_bh submit_bio // submit and wait io end ioctl(DM_DEV_SUSPEND_CMD) dev_suspend do_resume dm_suspend __dm_suspend lock_fs freeze_bdev get_active_super grab_super // wait for &s->s_umount down_write(&s->s_umount); dm_swap_table __bind // set md->map(can't get here) IO will be continuously requeued while holding the lock since mapping table is NULL. At the same time, mapping table won't be set since the lock is not available. Like request-based DM, bio-based DM also has the same problem. It's not proper to just abort IO if the mapping table not available. So clear DM_SKIP_LOCKFS_FLAG when the mapping table is NULL, this allows the DM table to be loaded and the IO submitted upon resume. Fixes: fa247089 ("dm: requeue IO if mapping table not yet available") Cc: stable@vger.kernel.org Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> Signed-off-by: NMike Snitzer <snitzer@kernel.org> Conflicts: drivers/md/dm-ioctl.c Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> (cherry picked from commit 14dd9b4d)
-
由 Mike Snitzer 提交于
mainline inclusion from mainline-v5.18-rc1 commit fa247089 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7FI78 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.4-rc7&id=fa247089de9936a46e290d4724cb5f0b845600f5 ---------------------------------------- Update both bio-based and request-based DM to requeue IO if the mapping table not available. This race of IO being submitted before the DM device ready is so narrow, yet possible for initial table load given that the DM device's request_queue is created prior, that it best to requeue IO to handle this unlikely case. Reported-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com> Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> (cherry picked from commit e50475d3)
-
由 Li Lingfeng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7FI78 -------------------------------- This reverts commit 90d1a836. It's not proper to just abort IO when the map is not ready. So revert this and requeue IO to keep consistent with the community. Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> (cherry picked from commit bc4c0996)
-
- 19 7月, 2023 3 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1254 PR sync from: ZhaoLong Wang <wangzhaolong1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/OPC4G2ZQN6WR2I5ESDGY65SMYHK4IJAH/ CVE fixes: CVE-2023-32255 CVE-2023-32248 *** BLURB HERE *** Namjae Jeon (2): ksmbd: fix memleak in session setup ksmbd: fix NULL pointer dereference in smb2_get_info_filesystem() -- 2.31.1 Link:https://gitee.com/openeuler/kernel/pulls/1371 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1262 PR sync from: Xia Fukun <xiafukun@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/LCJWGRWDEBQ2SDVR5JOAP447NA4IDPK4/ Link:https://gitee.com/openeuler/kernel/pulls/1289 Reviewed-by: Zucheng Zheng <zhengzucheng@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1358 PR sync from: Dong Chenchen <dongchenchen2@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/7VPFOSIEXGI6VKANM4UYHSTQS3WGKXAN/ Link:https://gitee.com/openeuler/kernel/pulls/1455 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 18 7月, 2023 11 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1426 PR sync from: Liu Jian <liujian56@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/PR7IN2IHBPPN57ADATMAXCK6IOVOB3OG/ https://gitee.com/src-openeuler/kernel/issues/I7ISR3 Link:https://gitee.com/openeuler/kernel/pulls/1438 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1425 PR sync from: Zhong Jinghua <zhongjinghua@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/3G4GOSWGIMJSHVPDQ6QC6X64RMPRIJIW/ https://gitee.com/openeuler/kernel/issues/I7JHOA Link:https://gitee.com/openeuler/kernel/pulls/1459 Reviewed-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1436 Pablo Neira Ayuso (4): netfilter: nf_tables: incorrect error path handling with NFT_MSG_NEWRULE netfilter: nf_tables: fix chain binding transaction logic netfilter: nf_tables: add NFT_TRANS_PREPARE_ERROR to deal with bound set/chain netfilter: nf_tables: unbind non-anonymous set if rule construction fails https://gitee.com/src-openeuler/kernel/issues/I7H68N Link:https://gitee.com/openeuler/kernel/pulls/1462 Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @ci-robot PR sync from: Zhong Jinghua <zhongjinghua@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/HOVMIDKZMBMNOQNYQNFHPUF5WRMSNV76/ From: Zhong Jinghua <zhongjinghua@huaweicloud.com> nbd: fix null-ptr-dereference while accessing 'nbd->config' Yu Kuai (3): nbd: fold nbd config initialization into nbd_alloc_config() nbd: factor out a helper to get nbd_config without holding 'config_lock' nbd: fix null-ptr-dereference while accessing 'nbd->config' -- 2.31.1 https://gitee.com/openeuler/kernel/issues/I7EENU Link:https://gitee.com/openeuler/kernel/pulls/1429 Reviewed-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Pablo Neira Ayuso 提交于
mainline inclusion from mainline-v6.4 commit 3e70489721b6c870252c9082c496703677240f53 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7H68N CVE: CVE-2023-3117 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e70489721b6c870252c9082c496703677240f53 -------------------------------- Otherwise a dangling reference to a rule object that is gone remains in the set binding list. Fixes: 26b5a571 ("netfilter: nf_tables: add NFT_TRANS_PREPARE_ERROR to deal with bound set/chain") Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: NLu Wei <luwei32@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> (cherry picked from commit dbc47736)
-
由 Pablo Neira Ayuso 提交于
mainline inclusion from mainline-v6.4 commit 26b5a571 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7H68N CVE: CVE-2023-3117 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=26b5a5712eb85e253724e56a54c17f8519bd8e4e -------------------------------- Add a new state to deal with rule expressions deactivation from the newrule error path, otherwise the anonymous set remains in the list in inactive state for the next generation. Mark the set/chain transaction as unbound so the abort path releases this object, set it as inactive in the next generation so it is not reachable anymore from this transaction and reference counter is dropped. Fixes: 1240eb93 ("netfilter: nf_tables: incorrect error path handling with NFT_MSG_NEWRULE") Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> conflict: include/net/netfilter/nf_tables.h net/netfilter/nf_tables_api.c Signed-off-by: NLu Wei <luwei32@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> (cherry picked from commit af739b3b)
-
由 Pablo Neira Ayuso 提交于
mainline inclusion from mainline-v6.4 commit 4bedf9ee category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7H68N CVE: CVE-2023-3117 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4bedf9eee016286c835e3d8fa981ddece5338795 -------------------------------- Add bound flag to rule and chain transactions as in 6a0a8d10 ("netfilter: nf_tables: use-after-free in failing rule with bound set") to skip them in case that the chain is already bound from the abort path. This patch fixes an imbalance in the chain use refcnt that triggers a WARN_ON on the table and chain destroy path. This patch also disallows nested chain bindings, which is not supported from userspace. The logic to deal with chain binding in nft_data_hold() and nft_data_release() is not correct. The NFT_TRANS_PREPARE state needs a special handling in case a chain is bound but next expressions in the same rule fail to initialize as described by 1240eb93 ("netfilter: nf_tables: incorrect error path handling with NFT_MSG_NEWRULE"). The chain is left bound if rule construction fails, so the objects stored in this chain (and the chain itself) are released by the transaction records from the abort path, follow up patch ("netfilter: nf_tables: add NFT_TRANS_PREPARE_ERROR to deal with bound set/chain") completes this error handling. When deleting an existing rule, chain bound flag is set off so the rule expression .destroy path releases the objects. Fixes: d0e2c7de ("netfilter: nf_tables: add NFT_CHAIN_BINDING") Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> conflict: include/net/netfilter/nf_tables.h net/netfilter/nf_tables_api.c Signed-off-by: NLu Wei <luwei32@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> (cherry picked from commit 04982868)
-
由 Pablo Neira Ayuso 提交于
mainline inclusion from mainline-v6.4-rc7 commit 1240eb93 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7H68N CVE: CVE-2023-3117 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1240eb93f0616b21c675416516ff3d74798fdc97 -------------------------------- In case of error when adding a new rule that refers to an anonymous set, deactivate expressions via NFT_TRANS_PREPARE state, not NFT_TRANS_RELEASE. Thus, the lookup expression marks anonymous sets as inactive in the next generation to ensure it is not reachable in this transaction anymore and decrement the set refcount as introduced by c1592a89 ("netfilter: nf_tables: deactivate anonymous set from preparation phase"). The abort step takes care of undoing the anonymous set. This is also consistent with rule deletion, where NFT_TRANS_PREPARE is used. Note that this error path is exercised in the preparation step of the commit protocol. This patch replaces nf_tables_rule_release() by the deactivate and destroy calls, this time with NFT_TRANS_PREPARE. Due to this incorrect error handling, it is possible to access a dangling pointer to the anonymous set that remains in the transaction list. [1009.379054] BUG: KASAN: use-after-free in nft_set_lookup_global+0x147/0x1a0 [nf_tables] [1009.379106] Read of size 8 at addr ffff88816c4c8020 by task nft-rule-add/137110 [1009.379116] CPU: 7 PID: 137110 Comm: nft-rule-add Not tainted 6.4.0-rc4+ #256 [1009.379128] Call Trace: [1009.379132] <TASK> [1009.379135] dump_stack_lvl+0x33/0x50 [1009.379146] ? nft_set_lookup_global+0x147/0x1a0 [nf_tables] [1009.379191] print_address_description.constprop.0+0x27/0x300 [1009.379201] kasan_report+0x107/0x120 [1009.379210] ? nft_set_lookup_global+0x147/0x1a0 [nf_tables] [1009.379255] nft_set_lookup_global+0x147/0x1a0 [nf_tables] [1009.379302] nft_lookup_init+0xa5/0x270 [nf_tables] [1009.379350] nf_tables_newrule+0x698/0xe50 [nf_tables] [1009.379397] ? nf_tables_rule_release+0xe0/0xe0 [nf_tables] [1009.379441] ? kasan_unpoison+0x23/0x50 [1009.379450] nfnetlink_rcv_batch+0x97c/0xd90 [nfnetlink] [1009.379470] ? nfnetlink_rcv_msg+0x480/0x480 [nfnetlink] [1009.379485] ? __alloc_skb+0xb8/0x1e0 [1009.379493] ? __alloc_skb+0xb8/0x1e0 [1009.379502] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0 [1009.379509] ? unwind_get_return_address+0x2a/0x40 [1009.379517] ? write_profile+0xc0/0xc0 [1009.379524] ? avc_lookup+0x8f/0xc0 [1009.379532] ? __rcu_read_unlock+0x43/0x60 Fixes: 958bee14 ("netfilter: nf_tables: use new transaction infrastructure to handle sets") Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> conflict: net/netfilter/nf_tables_api.c Signed-off-by: NLu Wei <luwei32@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> (cherry picked from commit a45e538a)
-
由 Zhong Jinghua 提交于
stable inclusion from stable-v5.10.173 commit c79a924ed6afac1708dfd370ba66bcf6a852ced6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7JHOA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c79a924ed6afac1708dfd370ba66bcf6a852ced6 -------------------------------- [ Upstream commit 9f6ad5d5 ] In loop_set_status_from_info(), lo->lo_offset and lo->lo_sizelimit should be checked before reassignment, because if an overflow error occurs, the original correct value will be changed to the wrong value, and it will not be changed back. More, the original patch did not solve the problem, the value was set and ioctl returned an error, but the subsequent io used the value in the loop driver, which still caused an alarm: loop_handle_cmd do_req_filebacked loff_t pos = ((loff_t) blk_rq_pos(rq) << 9) + lo->lo_offset; lo_rw_aio cmd->iocb.ki_pos = pos Fixes: c490a0b5 ("loop: Check for overflow while configuring loop") Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com> Reviewed-by: NChaitanya Kulkarni <kch@nvidia.com> Link: https://lore.kernel.org/r/20230221095027.3656193-1-zhongjinghua@huaweicloud.comSigned-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com> (cherry picked from commit cfb3aa6f)
-
由 Stephen Hemminger 提交于
stable inclusion from stable-v5.10.184 commit 1c004b379b0327992c1713334198cf5eba29a4ba category: bugfix bugzilla: 188948 CVE: CVE-2023-3338 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1c004b379b0327992c1713334198cf5eba29a4ba --------------------------- commit 1202cdd6 upstream. DECnet is an obsolete network protocol that receives more attention from kernel janitors than users. It belongs in computer protocol history museum not in Linux kernel. It has been "Orphaned" in kernel since 2010. The iproute2 support for DECnet was dropped in 5.0 release. The documentation link on Sourceforge says it is abandoned there as well. Leave the UAPI alone to keep userspace programs compiling. This means that there is still an empty neighbour table for AF_DECNET. The table of /proc/sys/net entries was updated to match current directories and reformatted to be alphabetical. Signed-off-by: NStephen Hemminger <stephen@networkplumber.org> Acked-by: NDavid Ahern <dsahern@kernel.org> Acked-by: NNikolay Aleksandrov <razor@blackwall.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com> (cherry picked from commit 44083b0c)
-
mainline inclusion from mainline commit 515ad530795c118f012539ed76d02bacfd426d89 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7ISR3 CVE: CVE-2023-31248 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=515ad530795c118f012539ed76d02bacfd426d89 --------------------------- When adding a rule to a chain referring to its ID, if that chain had been deleted on the same batch, the rule might end up referring to a deleted chain. This will lead to a WARNING like following: [ 33.098431] ------------[ cut here ]------------ [ 33.098678] WARNING: CPU: 5 PID: 69 at net/netfilter/nf_tables_api.c:2037 nf_tables_chain_destroy+0x23d/0x260 [ 33.099217] Modules linked in: [ 33.099388] CPU: 5 PID: 69 Comm: kworker/5:1 Not tainted 6.4.0+ #409 [ 33.099726] Workqueue: events nf_tables_trans_destroy_work [ 33.100018] RIP: 0010:nf_tables_chain_destroy+0x23d/0x260 [ 33.100306] Code: 8b 7c 24 68 e8 64 9c ed fe 4c 89 e7 e8 5c 9c ed fe 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7 c3 cc cc cc cc <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7 [ 33.101271] RSP: 0018:ffffc900004ffc48 EFLAGS: 00010202 [ 33.101546] RAX: 0000000000000001 RBX: ffff888006fc0a28 RCX: 0000000000000000 [ 33.101920] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 33.102649] RBP: ffffc900004ffc78 R08: 0000000000000000 R09: 0000000000000000 [ 33.103018] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880135ef500 [ 33.103385] R13: 0000000000000000 R14: dead000000000122 R15: ffff888006fc0a10 [ 33.103762] FS: 0000000000000000(0000) GS:ffff888024c80000(0000) knlGS:0000000000000000 [ 33.104184] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 33.104493] CR2: 00007fe863b56a50 CR3: 00000000124b0001 CR4: 0000000000770ee0 [ 33.104872] PKRU: 55555554 [ 33.104999] Call Trace: [ 33.105113] <TASK> [ 33.105214] ? show_regs+0x72/0x90 [ 33.105371] ? __warn+0xa5/0x210 [ 33.105520] ? nf_tables_chain_destroy+0x23d/0x260 [ 33.105732] ? report_bug+0x1f2/0x200 [ 33.105902] ? handle_bug+0x46/0x90 [ 33.106546] ? exc_invalid_op+0x19/0x50 [ 33.106762] ? asm_exc_invalid_op+0x1b/0x20 [ 33.106995] ? nf_tables_chain_destroy+0x23d/0x260 [ 33.107249] ? nf_tables_chain_destroy+0x30/0x260 [ 33.107506] nf_tables_trans_destroy_work+0x669/0x680 [ 33.107782] ? mark_held_locks+0x28/0xa0 [ 33.107996] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [ 33.108294] ? _raw_spin_unlock_irq+0x28/0x70 [ 33.108538] process_one_work+0x68c/0xb70 [ 33.108755] ? lock_acquire+0x17f/0x420 [ 33.108977] ? __pfx_process_one_work+0x10/0x10 [ 33.109218] ? do_raw_spin_lock+0x128/0x1d0 [ 33.109435] ? _raw_spin_lock_irq+0x71/0x80 [ 33.109634] worker_thread+0x2bd/0x700 [ 33.109817] ? __pfx_worker_thread+0x10/0x10 [ 33.110254] kthread+0x18b/0x1d0 [ 33.110410] ? __pfx_kthread+0x10/0x10 [ 33.110581] ret_from_fork+0x29/0x50 [ 33.110757] </TASK> [ 33.110866] irq event stamp: 1651 [ 33.111017] hardirqs last enabled at (1659): [<ffffffffa206a209>] __up_console_sem+0x79/0xa0 [ 33.111379] hardirqs last disabled at (1666): [<ffffffffa206a1ee>] __up_console_sem+0x5e/0xa0 [ 33.111740] softirqs last enabled at (1616): [<ffffffffa1f5d40e>] __irq_exit_rcu+0x9e/0xe0 [ 33.112094] softirqs last disabled at (1367): [<ffffffffa1f5d40e>] __irq_exit_rcu+0x9e/0xe0 [ 33.112453] ---[ end trace 0000000000000000 ]--- This is due to the nft_chain_lookup_byid ignoring the genmask. After this change, adding the new rule will fail as it will not find the chain. Fixes: 837830a4 ("netfilter: nf_tables: add NFTA_RULE_CHAIN_ID attribute") Cc: stable@vger.kernel.org Reported-by: Mingi Cho of Theori working with ZDI Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@canonical.com> Reviewed-by: NFlorian Westphal <fw@strlen.de> Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: NLiu Jian <liujian56@huawei.com> (cherry picked from commit ba0d52cb)
-
- 17 7月, 2023 2 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1415 PR sync from: Zhihao Cheng <chengzhihao1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/TSXRUVDLVGILRT2XURWM3RIMGTKSEUZT/ Revert origin fix, add debug message. Zhihao Cheng (2): Revert "ext4: Stop trying writing pages if no free blocks generated" ext4: Add debug message to notify user space is out of free -- 2.31.1 https://gitee.com/openeuler/kernel/issues/I7CBCS Link:https://gitee.com/openeuler/kernel/pulls/1419 Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1295 PR sync from: Li Lingfeng <lilingfeng3@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/OFH6G7EUCRF236P635HQ5LEDXVZ4AEJJ/ Yu Kuai (2): blk-wbt: make enable_state more accurate blk-wbt: don't show valid wbt_lat_usec in sysfs while wbt is disabled -- 2.31.1 Link:https://gitee.com/openeuler/kernel/pulls/1348 Reviewed-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 14 7月, 2023 6 次提交
-
-
由 Yu Kuai 提交于
Offering: HULK hulk inclusion category: bugfix bugzilla: 188902, https://gitee.com/openeuler/kernel/issues/I7EENU ---------------------------------------- nbd->config = config and refcount_set(&nbd->config_refs, 1) in nbd_genl_connect may be out of order, causing config_refs to be set to 1 first, and then nbd_open accessing nbd->config reports a null pointer reference. T1 T2 vfs_open do_dentry_open blkdev_open blkdev_get __blkdev_get nbd_open nbd_get_config_unlocked genl_rcv_msg genl_family_rcv_msg genl_family_rcv_msg_doit nbd_genl_connect nbd_alloc_and_init_config // out of order execution refcount_set(&nbd->config_refs, 1); // 2 nbd->config // null point nbd->config = config; // 1 Fix it by adding a cpu memory barrier to guarantee sequential execution. Signed-off-by: NYu Kuai <yukuai3@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Yu Kuai 提交于
Offering: HULK hulk inclusion category: bugfix bugzilla: 188902, https://gitee.com/openeuler/kernel/issues/I7EENU ---------------------------------------- There are no functional changes, just to make code cleaner and prepare to fix null-ptr-dereference while accessing 'nbd->config'. Signed-off-by: NYu Kuai <yukuai3@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Yu Kuai 提交于
Offering: HULK hulk inclusion category: bugfix bugzilla: 188902 ---------------------------------------- There are no functional changes, make the code cleaner and prepare to fix null-ptr-dereference while accessing 'nbd->config'. Signed-off-by: NYu Kuai <yukuai3@huawei.com> Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
-
由 Zhihao Cheng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7CBCS CVE: NA -------------------------------- Add debug message to notify user that ext4_writepages is stuck in loop caused by ENOSPC. Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> (cherry picked from commit 4ae7e703)
-
由 Zhihao Cheng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7CBCS CVE: NA -------------------------------- This reverts commit 07a8109d. When ext4 runs out of space, there could be a potential data lost in ext4_writepages: If there are many preallocated blocks for some files, e4b bitmap is different from block bitmap, and there are more free blocks accounted by block bitmap. ext4_writepages P2 ext4_mb_new_blocks ext4_map_blocks ext4_mb_regular_allocator // No free bits in e4b bitmap ext4_mb_discard_preallocations_should_retry ext4_mb_discard_preallocations ext4_mb_discard_group_preallocations ext4_mb_release_inode_pa // updates e4b bitmap by pa->pa_free mb_free_blocks ext4_mb_new_blocks ext4_mb_regular_allocator // Got e4b bitmap's free bits ext4_mb_regular_allocator // After 3 times retrying, ret ENOSPC ext4_writepages mpage_map_and_submit_extent mpage_map_one_extent // ret ENOSPC if (err == -ENOSPC && EXT4_SB(sb)->s_mb_free_pending) // s_mb_free_pending is 0 *give_up_on_write = true // Abandon writeback, data lost! Fixes: 07a8109d ("ext4: Stop trying writing pages if no free ...") Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> (cherry picked from commit 5f142164)
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1408 PR sync from: Gaosheng Cui <cuigaosheng1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/KDI6HM6ETZD4MQLPN2PXX7TI3XO7ZJC5/ Replace the hulk patch with the lts patch, thanks! Gaosheng Cui (1): Revert "cgroup: Stop task iteration when rebinding subsystem" Xiu Jianfeng (1): cgroup: Do not corrupt task iteration when rebinding subsystem -- 2.30.0 https://gitee.com/openeuler/kernel/issues/I7AZ85 Link:https://gitee.com/openeuler/kernel/pulls/1411 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 13 7月, 2023 5 次提交
-
-
由 Xiu Jianfeng 提交于
stable inclusion from stable-v5.10.186 commit 63608437a83ddabe497cfc163237e654eb563701 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7AZ85 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=63608437a83ddabe497cfc163237e654eb563701 -------------------------------- commit 6f363f5a upstream. We found a refcount UAF bug as follows: refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 342 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x148 Workqueue: events cpuset_hotplug_workfn Call trace: refcount_warn_saturate+0xa0/0x148 __refcount_add.constprop.0+0x5c/0x80 css_task_iter_advance_css_set+0xd8/0x210 css_task_iter_advance+0xa8/0x120 css_task_iter_next+0x94/0x158 update_tasks_root_domain+0x58/0x98 rebuild_root_domains+0xa0/0x1b0 rebuild_sched_domains_locked+0x144/0x188 cpuset_hotplug_workfn+0x138/0x5a0 process_one_work+0x1e8/0x448 worker_thread+0x228/0x3e0 kthread+0xe0/0xf0 ret_from_fork+0x10/0x20 then a kernel panic will be triggered as below: Unable to handle kernel paging request at virtual address 00000000c0000010 Call trace: cgroup_apply_control_disable+0xa4/0x16c rebind_subsystems+0x224/0x590 cgroup_destroy_root+0x64/0x2e0 css_free_rwork_fn+0x198/0x2a0 process_one_work+0x1d4/0x4bc worker_thread+0x158/0x410 kthread+0x108/0x13c ret_from_fork+0x10/0x18 The race that cause this bug can be shown as below: (hotplug cpu) | (umount cpuset) mutex_lock(&cpuset_mutex) | mutex_lock(&cgroup_mutex) cpuset_hotplug_workfn | rebuild_root_domains | rebind_subsystems update_tasks_root_domain | spin_lock_irq(&css_set_lock) css_task_iter_start | list_move_tail(&cset->e_cset_node[ss->id] while(css_task_iter_next) | &dcgrp->e_csets[ss->id]); css_task_iter_end | spin_unlock_irq(&css_set_lock) mutex_unlock(&cpuset_mutex) | mutex_unlock(&cgroup_mutex) Inside css_task_iter_start/next/end, css_set_lock is hold and then released, so when iterating task(left side), the css_set may be moved to another list(right side), then it->cset_head points to the old list head and it->cset_pos->next points to the head node of new list, which can't be used as struct css_set. To fix this issue, switch from all css_sets to only scgrp's css_sets to patch in-flight iterators to preserve correct iteration, and then update it->cset_head as well. Reported-by: NGaosheng Cui <cuigaosheng1@huawei.com> Link: https://www.spinics.net/lists/cgroups/msg37935.htmlSuggested-by: NMichal Koutný <mkoutny@suse.com> Link: https://lore.kernel.org/all/20230526114139.70274-1-xiujianfeng@huaweicloud.com/Signed-off-by: NXiu Jianfeng <xiujianfeng@huawei.com> Fixes: 2d8f243a ("cgroup: implement cgroup->e_csets[]") Cc: stable@vger.kernel.org # v3.16+ Signed-off-by: NTejun Heo <tj@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Conflicts: kernel/cgroup/cgroup.c Signed-off-by: NGaosheng Cui <cuigaosheng1@huawei.com> (cherry picked from commit d09e69cd)
-
由 Gaosheng Cui 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7AZ85 -------------------------------- This reverts commit e52586f4. Signed-off-by: NGaosheng Cui <cuigaosheng1@huawei.com> (cherry picked from commit 7a4d01c1)
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1312 PR sync from: Baokun Li <libaokun1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/7ATD3RNUBURBEYA34VGOOZB53J377OZQ/ Baokun Li (5): quota: factor out dquot_write_dquot() quota: rename dquot_active() to inode_quota_active() quota: add new helper dquot_active() quota: fix dqput() to follow the guarantees dquot_srcu should provide quota: simplify drop_dquot_ref() -- 2.31.1 Link:https://gitee.com/openeuler/kernel/pulls/1388 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1376 PR sync from: Zhihao Cheng <chengzhihao1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/XNJZFYFNQIMIIQRPICSJB7KUZJDPS27T/ Link:https://gitee.com/openeuler/kernel/pulls/1391 Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1280 A successful call to cgroup_css_set_fork() will always have taken a ref on kargs->cset (regardless of CLONE_INTO_CGROUP), so always do a corresponding put in cgroup_css_set_put_fork(). Without this, a cset and its contained css structures will be leaked for some fork failures. The following script reproduces the leak for a fork failure due to exceeding pids.max in the pids controller. A similar thing can happen if we jump to the bad_fork_cancel_cgroup label in copy_process(). [ -z "$1" ] && echo "Usage $0 pids-root" && exit 1 PID_ROOT=$1 CGROUP=$PID_ROOT/foo [ -e $CGROUP ] && rmdir -f $CGROUP mkdir $CGROUP echo 5 > $CGROUP/pids.max echo $$ > $CGROUP/cgroup.procs fork_bomb() { set -e for i in $(seq 10); do /bin/sleep 3600 & done } (fork_bomb) & wait echo $$ > $PID_ROOT/cgroup.procs kill $(cat $CGROUP/cgroup.procs) rmdir $CGROUP Link:https://gitee.com/openeuler/kernel/pulls/1307 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 12 7月, 2023 8 次提交
-
-
由 Zhihao Cheng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I70WHL CVE: NA -------------------------------- Following process will corrupt ext4 image: Step 1: jbd2_journal_commit_transaction __jbd2_journal_insert_checkpoint(jh, commit_transaction) // Put jh into trans1->t_checkpoint_list journal->j_checkpoint_transactions = commit_transaction // Put trans1 into journal->j_checkpoint_transactions Step 2: do_get_write_access test_clear_buffer_dirty(bh) // clear buffer dirty，set jbd dirty __jbd2_journal_file_buffer(jh, transaction) // jh belongs to trans2 Step 3: drop_cache journal_shrink_one_cp_list jbd2_journal_try_remove_checkpoint if (!trylock_buffer(bh)) // lock bh, true if (buffer_dirty(bh)) // buffer is not dirty __jbd2_journal_remove_checkpoint(jh) // remove jh from trans1->t_checkpoint_list Step 4: jbd2_log_do_checkpoint trans1 = journal->j_checkpoint_transactions // jh is not in trans1->t_checkpoint_list jbd2_cleanup_journal_tail(journal) // trans1 is done Step 5: Power cut, trans2 is not committed, jh is lost in next mounting. Fix it by checking 'jh->b_transaction' before remove it from checkpoint. Fixes: 80079353 ("jbd2: fix a race when checking checkpoint ...") Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> (cherry picked from commit 7723e91d)
-
由 Baokun Li 提交于
maillist inclusion category: bugfix bugzilla: 188812,https://gitee.com/openeuler/kernel/issues/I7E0YR Reference: https://www.spinics.net/lists/kernel/msg4844759.html ---------------------------------------- As Honza said, remove_inode_dquot_ref() currently does not release the last dquot reference but instead adds the dquot to tofree_head list. This is because dqput() can sleep while dropping of the last dquot reference (writing back the dquot and calling ->release_dquot()) and that must not happen under dq_list_lock. Now that dqput() queues the final dquot cleanup into a workqueue, remove_inode_dquot_ref() can call dqput() unconditionally and we can significantly simplify it. Here we open code the simplified code of remove_inode_dquot_ref() into remove_dquot_ref() and remove the function put_dquot_list() which is no longer used. Signed-off-by: NBaokun Li <libaokun1@huawei.com> (cherry picked from commit a13fcef3)
-
由 Baokun Li 提交于
maillist inclusion category: bugfix bugzilla: 188812,https://gitee.com/openeuler/kernel/issues/I7E0YR Reference: https://www.spinics.net/lists/kernel/msg4844759.html ---------------------------------------- The dquot_mark_dquot_dirty() using dquot references from the inode should be protected by dquot_srcu. quota_off code takes care to call synchronize_srcu(&dquot_srcu) to not drop dquot references while they are used by other users. But dquot_transfer() breaks this assumption. We call dquot_transfer() to drop the last reference of dquot and add it to free_dquots, but there may still be other users using the dquot at this time, as shown in the function graph below: cpu1 cpu2 _________________|_________________ wb_do_writeback CHOWN(1) ... ext4_da_update_reserve_space dquot_claim_block ... dquot_mark_dquot_dirty // try to dirty old quota test_bit(DQ_ACTIVE_B, &dquot->dq_flags) // still ACTIVE if (test_bit(DQ_MOD_B, &dquot->dq_flags)) // test no dirty, wait dq_list_lock ... dquot_transfer __dquot_transfer dqput_all(transfer_from) // rls old dquot dqput // last dqput dquot_release clear_bit(DQ_ACTIVE_B, &dquot->dq_flags) atomic_dec(&dquot->dq_count) put_dquot_last(dquot) list_add_tail(&dquot->dq_free, &free_dquots) // add the dquot to free_dquots if (!test_and_set_bit(DQ_MOD_B, &dquot->dq_flags)) add dqi_dirty_list // add released dquot to dirty_list This can cause various issues, such as dquot being destroyed by dqcache_shrink_scan() after being added to free_dquots, which can trigger a UAF in dquot_mark_dquot_dirty(); or after dquot is added to free_dquots and then to dirty_list, it is added to free_dquots again after dquot_writeback_dquots() is executed, which causes the free_dquots list to be corrupted and triggers a UAF when dqcache_shrink_scan() is called for freeing dquot twice. As Honza said, we need to fix dquot_transfer() to follow the guarantees dquot_srcu should provide. But calling synchronize_srcu() directly from dquot_transfer() is too expensive (and mostly unnecessary). So we add dquot whose last reference should be dropped to the new global dquot list releasing_dquots, and then queue work item which would call synchronize_srcu() and after that perform the final cleanup of all the dquots on releasing_dquots. Fixes: 4580b30e ("quota: Do not dirty bad dquots") Suggested-by: NJan Kara <jack@suse.cz> Signed-off-by: NBaokun Li <libaokun1@huawei.com> (cherry picked from commit d82ddaab)
-
由 Baokun Li 提交于
maillist inclusion category: bugfix bugzilla: 188812,https://gitee.com/openeuler/kernel/issues/I7E0YR Reference: https://www.spinics.net/lists/kernel/msg4844759.html ---------------------------------------- Add new helper function dquot_active() to make the code more concise. Signed-off-by: NBaokun Li <libaokun1@huawei.com> (cherry picked from commit 3fb7aa3a)
-
由 Baokun Li 提交于
maillist inclusion category: bugfix bugzilla: 188812,https://gitee.com/openeuler/kernel/issues/I7E0YR Reference: https://www.spinics.net/lists/kernel/msg4844759.html ---------------------------------------- Now we have a helper function dquot_dirty() to determine if dquot has DQ_MOD_B bit. dquot_active() can easily be misunderstood as a helper function to determine if dquot has DQ_ACTIVE_B bit. So we avoid this by renaming it to inode_quota_active() and later on we will add the helper function dquot_active() to determine if dquot has DQ_ACTIVE_B bit. Signed-off-by: NBaokun Li <libaokun1@huawei.com> (cherry picked from commit 329a1eb4)
-
由 Baokun Li 提交于
maillist inclusion category: bugfix bugzilla: 188812,https://gitee.com/openeuler/kernel/issues/I7E0YR Reference: https://www.spinics.net/lists/kernel/msg4844759.html ---------------------------------------- Refactor out dquot_write_dquot() to reduce duplicate code. Signed-off-by: NBaokun Li <libaokun1@huawei.com> (cherry picked from commit 0a3781ae)
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1325 PR sync from: Zhihao Cheng <chengzhihao1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/QARA5X5OQUKRFUIORG2YVB6YE3V5CGQB/ Zhang Yi (4): jbd2: remove journal_clean_one_cp_list() jbd2: fix a race when checking checkpoint buffer busy jbd2: remove __journal_try_to_free_buffer() jbd2: fix checkpoint cleanup performance regression Zhihao Cheng (1): jbd2: Fix wrongly judgement for buffer head removing while doing checkpoint -- 2.31.1 Link:https://gitee.com/openeuler/kernel/pulls/1328 Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1314 PR sync from: Zhihao Cheng <chengzhihao1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/ALOJ633HB2KNGCGZVSSVUI34JMM2MTRP/ Link:https://gitee.com/openeuler/kernel/pulls/1331 Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 11 7月, 2023 1 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/1286 PR sync from: Baokun Li <libaokun1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/X3ZSP2AARUKCTNGQH7V2EC4D2KQ67AMO/ Link:https://gitee.com/openeuler/kernel/pulls/1339 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-