- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 0/2] filelock: fix uaf while fcntl/close race
by Long Li 29 Jul '24

29 Jul '24

This patch set fix uaf while fcntl/close race. Jann Horn (2): filelock: Remove locks reliably when fcntl/close race is detected filelock: Fix fcntl/close race recovery compat path fs/locks.c | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) -- 2.39.2

2 3

[PATCH v2 openEuler-1.0-LTS] PCI/ROM: Fix PCI ROM header check bug
by liwei 29 Jul '24

29 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAEDJI -------------------------------- In UEFI Specification Version 2.8, describes that the PCIR data structure must start on a 4-byte boundary. Add checks to prevent vulnerabilities. Fixes: d7ad2254fa7c ("[IA64] SN: Correct ROM resource length for BIOS copy") Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/pci/rom.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c index 137bf0cee897..d7bae7a804c4 100644 --- a/drivers/pci/rom.c +++ b/drivers/pci/rom.c @@ -98,6 +98,12 @@ static size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, } /* get the PCI data structure and check its "PCIR" signature */ pds = image + readw(image + 24); + /* The PCIR data structure must begin on a 4-byte boundary */ + if (!IS_ALIGNED((unsigned long)pds, 4)) { + pci_info(pdev, "Invalid PCI ROM header signature: PCIR %#06x\n", + readw(image + 24)); + break; + } if (readl(pds) != 0x52494350) { pci_info(pdev, "Invalid PCI ROM data signature: expecting 0x52494350, got %#010x\n", readl(pds)); -- 2.25.1

2 1

[PATCH OLK-6.6] jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error
by Baokun Li 29 Jul '24

29 Jul '24

maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAG7MT CVE: NA Reference: https://lore.kernel.org/all/20240718115336.2554501-1-libaokun@huaweicloud.c… ---------------------------------------- In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: <TASK> add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code. Fixes: 8c3f25d8950c ("jbd2: don't give up looking for space so easily in __jbd2_log_wait_for_space") Cc: stable(a)kernel.org Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/jbd2/checkpoint.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c index 118699fff2f9..27a8931647ea 100644 --- a/fs/jbd2/checkpoint.c +++ b/fs/jbd2/checkpoint.c @@ -86,8 +86,11 @@ __releases(&journal->j_state_lock) write_unlock(&journal->j_state_lock); if (chkpt) { jbd2_log_do_checkpoint(journal); - } else if (jbd2_cleanup_journal_tail(journal) == 0) { - /* We were able to recover space; yay! */ + } else if (jbd2_cleanup_journal_tail(journal) <= 0) { + /* + * We were able to recover space or the + * journal was aborted due to an error. + */ ; } else if (tid) { /* -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS] PCI/ROM: Fix PCI ROM header check bug
by liwei 29 Jul '24

29 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAEAGS -------------------------------- In UEFI Specification Version 2.8, describes that the PCIR data structure must start on a 4-byte boundary. Add checks to prevent vulnerabilities. Fixes: d7ad2254fa7c ("[IA64] SN: Correct ROM resource length for BIOS copy") Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/pci/rom.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c index 137bf0cee897..d7bae7a804c4 100644 --- a/drivers/pci/rom.c +++ b/drivers/pci/rom.c @@ -98,6 +98,12 @@ static size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, } /* get the PCI data structure and check its "PCIR" signature */ pds = image + readw(image + 24); + /* The PCIR data structure must begin on a 4-byte boundary */ + if (!IS_ALIGNED((unsigned long)pds, 4)) { + pci_info(pdev, "Invalid PCI ROM header signature: PCIR %#06x\n", + readw(image + 24)); + break; + } if (readl(pds) != 0x52494350) { pci_info(pdev, "Invalid PCI ROM data signature: expecting 0x52494350, got %#010x\n", readl(pds)); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error
by Baokun Li 29 Jul '24

29 Jul '24

maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAG7MT CVE: NA Reference: https://lore.kernel.org/all/20240718115336.2554501-1-libaokun@huaweicloud.c… ---------------------------------------- In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: <TASK> add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code. Fixes: 8c3f25d8950c ("jbd2: don't give up looking for space so easily in __jbd2_log_wait_for_space") Cc: stable(a)kernel.org Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/jbd2/checkpoint.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c index b7e1a2bdd7fb..727f3505280c 100644 --- a/fs/jbd2/checkpoint.c +++ b/fs/jbd2/checkpoint.c @@ -98,8 +98,11 @@ __releases(&journal->j_state_lock) write_unlock(&journal->j_state_lock); if (chkpt) { jbd2_log_do_checkpoint(journal); - } else if (jbd2_cleanup_journal_tail(journal) == 0) { - /* We were able to recover space; yay! */ + } else if (jbd2_cleanup_journal_tail(journal) <= 0) { + /* + * We were able to recover space or the + * journal was aborted due to an error. + */ ; } else if (tid) { /* -- 2.31.1

2 1

[PATCH OLK-5.10] jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error
by Baokun Li 29 Jul '24

29 Jul '24

maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAG7MT CVE: NA Reference: https://lore.kernel.org/all/20240718115336.2554501-1-libaokun@huaweicloud.c… ---------------------------------------- In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: <TASK> add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code. Fixes: 8c3f25d8950c ("jbd2: don't give up looking for space so easily in __jbd2_log_wait_for_space") Cc: stable(a)kernel.org Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/jbd2/checkpoint.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c index b7e1a2bdd7fb..727f3505280c 100644 --- a/fs/jbd2/checkpoint.c +++ b/fs/jbd2/checkpoint.c @@ -98,8 +98,11 @@ __releases(&journal->j_state_lock) write_unlock(&journal->j_state_lock); if (chkpt) { jbd2_log_do_checkpoint(journal); - } else if (jbd2_cleanup_journal_tail(journal) == 0) { - /* We were able to recover space; yay! */ + } else if (jbd2_cleanup_journal_tail(journal) <= 0) { + /* + * We were able to recover space or the + * journal was aborted due to an error. + */ ; } else if (tid) { /* -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS] jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error
by Baokun Li 29 Jul '24

29 Jul '24

maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAG7MT CVE: NA Reference: https://lore.kernel.org/all/20240718115336.2554501-1-libaokun@huaweicloud.c… ---------------------------------------- In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: <TASK> add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code. Fixes: 8c3f25d8950c ("jbd2: don't give up looking for space so easily in __jbd2_log_wait_for_space") Cc: stable(a)kernel.org Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/jbd2/checkpoint.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c index b35f0b63baf0..ab6c0b9c5336 100644 --- a/fs/jbd2/checkpoint.c +++ b/fs/jbd2/checkpoint.c @@ -96,8 +96,11 @@ void __jbd2_log_wait_for_space(journal_t *journal) write_unlock(&journal->j_state_lock); if (chkpt) { jbd2_log_do_checkpoint(journal); - } else if (jbd2_cleanup_journal_tail(journal) == 0) { - /* We were able to recover space; yay! */ + } else if (jbd2_cleanup_journal_tail(journal) <= 0) { + /* + * We were able to recover space or the + * journal was aborted due to an error. + */ ; } else if (tid) { /* -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/2] fix CVE-2024-40976
by Jinjiang Tu 29 Jul '24

29 Jul '24

fix CVE-2024-40976. Erico Nunes (2): drm/lima: add mask irq callback to gp and pp drm/lima: mask irqs in timeout path before hard reset drivers/gpu/drm/lima/lima_bcast.c | 12 ++++++++++++ drivers/gpu/drm/lima/lima_bcast.h | 3 +++ drivers/gpu/drm/lima/lima_gp.c | 8 ++++++++ drivers/gpu/drm/lima/lima_pp.c | 18 ++++++++++++++++++ drivers/gpu/drm/lima/lima_sched.c | 7 +++++++ drivers/gpu/drm/lima/lima_sched.h | 1 + 6 files changed, 49 insertions(+) -- 2.25.1

2 3

[PATCH OLK-5.10 0/2] fix CVE-2024-40976
by Jinjiang Tu 29 Jul '24

29 Jul '24

fix CVE-2024-40976. Erico Nunes (2): drm/lima: add mask irq callback to gp and pp drm/lima: mask irqs in timeout path before hard reset drivers/gpu/drm/lima/lima_bcast.c | 12 ++++++++++++ drivers/gpu/drm/lima/lima_bcast.h | 3 +++ drivers/gpu/drm/lima/lima_gp.c | 8 ++++++++ drivers/gpu/drm/lima/lima_pp.c | 18 ++++++++++++++++++ drivers/gpu/drm/lima/lima_sched.c | 7 +++++++ drivers/gpu/drm/lima/lima_sched.h | 1 + 6 files changed, 49 insertions(+) -- 2.25.1

2 3

[PATCH OLK-6.6 0/2] bpf: Fix null-pointer-deref in resolve_prog_type()
by Tengda Wu 29 Jul '24

29 Jul '24

This patchset is going to fix null-pointer-deref in resolve_prog_type() for BPF_PROG_TYPE_EXT. `prog->aux->dst_prog` in resolve_prog_type() is assigned by `attach_prog_fd`, and would be NULL if `attach_prog_fd` is not provided. Loading EXT prog with bpf_dynptr_from_skb() kfunc call in this way will lead to null-pointer-deref. In last version we fix it by forcing `attach_prog_fd` non-empty at load time, which leads to libbpf_probe_prog_types() api broken. Currently, we fix it by just adding null check for EXT prog in resolve_prog_type() as the old way did. For the sake of safety, we compared the full test logs of selftest before and after applying these changes, and the results show that the two test logs were consistent. Tengda Wu (2): bpf: Fix null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXT selftests/bpf: Test for null-pointer-deref bugfix in resolve_prog_type() include/linux/bpf_verifier.h | 2 +- tools/testing/selftests/bpf/verifier/calls.c | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) -- 2.34.1

2 3

2024

2023

2022

2021

2020

2019

Kernel