- Kernel - mailweb.openeuler.org

[PATCH] mm: thp: support migration control when numa balancing
by Nanyong Sun 02 Aug '24

02 Aug '24

hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IAHJKC CVE: NA -------------------------------- Sometimes migrate THP is not beneficial, for example, when 64K page size is set on ARM64, THP will be 512M, migration may result in performance regression. This featrue add a switch to enalbe THP migration when do numa balancing, default is on, and can disable by: echo 0 > /sys/kernel/mm/transparent_hugepage/numa_migrate If disabled it, migrate_misplaced_page will return fail and task still have change to migrate. Signed-off-by: Nanyong Sun <sunnanyong(a)huawei.com> --- Documentation/admin-guide/mm/transhuge.rst | 5 +++++ arch/arm64/Kconfig | 1 + include/linux/huge_mm.h | 14 +++++++++++++ mm/Kconfig | 10 ++++++++++ mm/huge_memory.c | 23 ++++++++++++++++++++++ mm/migrate.c | 3 +++ 6 files changed, 56 insertions(+) diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst index 2bfb380e8380..97be39a0d5f5 100644 --- a/Documentation/admin-guide/mm/transhuge.rst +++ b/Documentation/admin-guide/mm/transhuge.rst @@ -160,6 +160,11 @@ library) may want to know the size (in bytes) of a transparent hugepage:: cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size +THP migration can be disabled when do numa balance if +CONFIG_NUMA_MIGRATE_THP_CONTROL is on by:: + + echo 0 > /sys/kernel/mm/transparent_hugepage/numa_migrate + khugepaged will be automatically started when transparent_hugepage/enabled is set to "always" or "madvise, and it'll be automatically shutdown if it's set to "never". diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index cae54a9bf65d..b3d0c391a570 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -216,6 +216,7 @@ config ARM64 select SYSCTL_EXCEPTION_TRACE select THREAD_INFO_IN_TASK select HAVE_LIVEPATCH_WO_FTRACE + select NUMA_MIGRATE_THP_CONTROL if ARM64_64K_PAGES help ARM 64-bit (AArch64) Linux support. diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h index efb370e79ac3..5442889245ef 100644 --- a/include/linux/huge_mm.h +++ b/include/linux/huge_mm.h @@ -90,6 +90,9 @@ enum transparent_hugepage_flag { #ifdef CONFIG_DEBUG_VM TRANSPARENT_HUGEPAGE_DEBUG_COW_FLAG, #endif +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL + TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG, +#endif }; struct kobject; @@ -181,6 +184,14 @@ bool transparent_hugepage_active(struct vm_area_struct *vma); (transparent_hugepage_flags & \ (1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG)) +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL +#define thp_can_numa_migrate() \ + (transparent_hugepage_flags & \ + (1<<TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG)) +#else +#define thp_can_numa_migrate() 1 +#endif + unsigned long thp_get_unmapped_area(struct file *filp, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags); @@ -485,6 +496,9 @@ static inline bool thp_migration_supported(void) { return false; } + +#define thp_can_numa_migrate() 0 + #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ /** diff --git a/mm/Kconfig b/mm/Kconfig index ccbad233f2b1..311b54078307 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -1038,6 +1038,16 @@ config NUMABALANCING_MEM_SAMPLING if unsure, say N to disable the NUMABALANCING_MEM_SAMPLING. +config NUMA_MIGRATE_THP_CONTROL + bool "Control THP migration when numa balancing" + depends on NUMA_BALANCING && TRANSPARENT_HUGEPAGE + default n + help + Sometimes migrate THP is not beneficial, for example, when 64K page + size is set on ARM64, THP will be 512M, migration will be expensive. + This featrue add a switch to control the behavior of THP migration + when do numa balancing. + source "mm/damon/Kconfig" endmenu diff --git a/mm/huge_memory.c b/mm/huge_memory.c index eb293d17a104..c02ffcbad96b 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -56,6 +56,9 @@ unsigned long transparent_hugepage_flags __read_mostly = #endif (1<<TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG)| (1<<TRANSPARENT_HUGEPAGE_DEFRAG_KHUGEPAGED_FLAG)| +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL + (1<<TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG)| +#endif (1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG); static struct shrinker deferred_split_shrinker; @@ -316,6 +319,23 @@ static ssize_t hpage_pmd_size_show(struct kobject *kobj, static struct kobj_attribute hpage_pmd_size_attr = __ATTR_RO(hpage_pmd_size); +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL +static ssize_t numa_migrate_show(struct kobject *kobj, + struct kobj_attribute *attr, char *buf) +{ + return single_hugepage_flag_show(kobj, attr, buf, + TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG); +} +static ssize_t numa_migrate_store(struct kobject *kobj, + struct kobj_attribute *attr, const char *buf, size_t count) +{ + return single_hugepage_flag_store(kobj, attr, buf, count, + TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG); +} +static struct kobj_attribute numa_migrate_attr = + __ATTR(numa_migrate, 0644, numa_migrate_show, numa_migrate_store); +#endif + static struct attribute *hugepage_attr[] = { &enabled_attr.attr, &defrag_attr.attr, @@ -323,6 +343,9 @@ static struct attribute *hugepage_attr[] = { &hpage_pmd_size_attr.attr, #ifdef CONFIG_SHMEM &shmem_enabled_attr.attr, +#endif +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL + &numa_migrate_attr.attr, #endif NULL, }; diff --git a/mm/migrate.c b/mm/migrate.c index 3f5b217d5af1..f7eb9b4c8668 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -2157,6 +2157,9 @@ int migrate_misplaced_page(struct page *page, struct vm_area_struct *vma, */ compound = PageTransHuge(page); + if (compound && !thp_can_numa_migrate()) + return 0; + if (compound) new = alloc_misplaced_dst_page_thp; else -- 2.25.1

1 0

[PATCH openEuler-22.03-LTS-SP1 0/4] fix CVE-2024-41062
by Zhengchao Shao 02 Aug '24

02 Aug '24

Fix CVE-2024-41062 Edward Adam Davis (1): bluetooth/l2cap: sync sock recv cb and release Luiz Augusto von Dentz (2): Bluetooth: L2CAP: Fix deadlock Bluetooth: Fix usage of __hci_cmd_sync_status Marcel Holtmann (1): Bluetooth: Add helper for serialized HCI command execution include/net/bluetooth/hci_core.h | 11 +- include/net/bluetooth/hci_sync.h | 44 ++++ net/bluetooth/Makefile | 2 +- net/bluetooth/hci_core.c | 92 ++------- net/bluetooth/hci_request.c | 68 ------ net/bluetooth/hci_request.h | 4 + net/bluetooth/hci_sync.c | 343 +++++++++++++++++++++++++++++++ net/bluetooth/l2cap_core.c | 3 + net/bluetooth/l2cap_sock.c | 10 +- 9 files changed, 427 insertions(+), 150 deletions(-) create mode 100644 include/net/bluetooth/hci_sync.h create mode 100644 net/bluetooth/hci_sync.c -- 2.34.1

2 5

[PATCH OLK-5.10 0/4] fix CVE-2024-41062
by Zhengchao Shao 02 Aug '24

02 Aug '24

Fix CVE-2024-41062 Edward Adam Davis (1): bluetooth/l2cap: sync sock recv cb and release Luiz Augusto von Dentz (2): Bluetooth: L2CAP: Fix deadlock Bluetooth: Fix usage of __hci_cmd_sync_status Marcel Holtmann (1): Bluetooth: Add helper for serialized HCI command execution include/net/bluetooth/hci_core.h | 11 +- include/net/bluetooth/hci_sync.h | 44 ++++ net/bluetooth/Makefile | 2 +- net/bluetooth/hci_core.c | 92 ++------- net/bluetooth/hci_request.c | 68 ------ net/bluetooth/hci_request.h | 4 + net/bluetooth/hci_sync.c | 343 +++++++++++++++++++++++++++++++ net/bluetooth/l2cap_core.c | 3 + net/bluetooth/l2cap_sock.c | 10 +- 9 files changed, 427 insertions(+), 150 deletions(-) create mode 100644 include/net/bluetooth/hci_sync.h create mode 100644 net/bluetooth/hci_sync.c -- 2.34.1

2 5

[PATCH OLK-5.10] mm: thp: support migration control when numa balancing
by Nanyong Sun 02 Aug '24

02 Aug '24

hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IAHJKC CVE: NA -------------------------------- Sometimes migrate THP is not beneficial, for example, when 64K page size is set on ARM64, THP will be 512M, migration may result in performance regression. This featrue add a switch to enalbe THP migration when do numa balancing, default is on, and can disable by: echo 0 > /sys/kernel/mm/transparent_hugepage/numa_migrate If disabled it, migrate_misplaced_page will return fail and task still have change to migrate. Signed-off-by: Nanyong Sun <sunnanyong(a)huawei.com> --- Documentation/admin-guide/mm/transhuge.rst | 5 +++++ arch/arm64/Kconfig | 1 + include/linux/huge_mm.h | 14 +++++++++++++ mm/Kconfig | 10 ++++++++++ mm/huge_memory.c | 23 ++++++++++++++++++++++ mm/migrate.c | 3 +++ 6 files changed, 56 insertions(+) diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst index 2bfb380e8380..97be39a0d5f5 100644 --- a/Documentation/admin-guide/mm/transhuge.rst +++ b/Documentation/admin-guide/mm/transhuge.rst @@ -160,6 +160,11 @@ library) may want to know the size (in bytes) of a transparent hugepage:: cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size +THP migration can be disabled when do numa balance if +CONFIG_NUMA_MIGRATE_THP_CONTROL is on by:: + + echo 0 > /sys/kernel/mm/transparent_hugepage/numa_migrate + khugepaged will be automatically started when transparent_hugepage/enabled is set to "always" or "madvise, and it'll be automatically shutdown if it's set to "never". diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index cae54a9bf65d..b3d0c391a570 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -216,6 +216,7 @@ config ARM64 select SYSCTL_EXCEPTION_TRACE select THREAD_INFO_IN_TASK select HAVE_LIVEPATCH_WO_FTRACE + select NUMA_MIGRATE_THP_CONTROL if ARM64_64K_PAGES help ARM 64-bit (AArch64) Linux support. diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h index efb370e79ac3..5442889245ef 100644 --- a/include/linux/huge_mm.h +++ b/include/linux/huge_mm.h @@ -90,6 +90,9 @@ enum transparent_hugepage_flag { #ifdef CONFIG_DEBUG_VM TRANSPARENT_HUGEPAGE_DEBUG_COW_FLAG, #endif +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL + TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG, +#endif }; struct kobject; @@ -181,6 +184,14 @@ bool transparent_hugepage_active(struct vm_area_struct *vma); (transparent_hugepage_flags & \ (1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG)) +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL +#define thp_can_numa_migrate() \ + (transparent_hugepage_flags & \ + (1<<TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG)) +#else +#define thp_can_numa_migrate() 1 +#endif + unsigned long thp_get_unmapped_area(struct file *filp, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags); @@ -485,6 +496,9 @@ static inline bool thp_migration_supported(void) { return false; } + +#define thp_can_numa_migrate() 0 + #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ /** diff --git a/mm/Kconfig b/mm/Kconfig index ccbad233f2b1..311b54078307 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -1038,6 +1038,16 @@ config NUMABALANCING_MEM_SAMPLING if unsure, say N to disable the NUMABALANCING_MEM_SAMPLING. +config NUMA_MIGRATE_THP_CONTROL + bool "Control THP migration when numa balancing" + depends on NUMA_BALANCING && TRANSPARENT_HUGEPAGE + default n + help + Sometimes migrate THP is not beneficial, for example, when 64K page + size is set on ARM64, THP will be 512M, migration will be expensive. + This featrue add a switch to control the behavior of THP migration + when do numa balancing. + source "mm/damon/Kconfig" endmenu diff --git a/mm/huge_memory.c b/mm/huge_memory.c index eb293d17a104..c02ffcbad96b 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -56,6 +56,9 @@ unsigned long transparent_hugepage_flags __read_mostly = #endif (1<<TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG)| (1<<TRANSPARENT_HUGEPAGE_DEFRAG_KHUGEPAGED_FLAG)| +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL + (1<<TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG)| +#endif (1<<TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG); static struct shrinker deferred_split_shrinker; @@ -316,6 +319,23 @@ static ssize_t hpage_pmd_size_show(struct kobject *kobj, static struct kobj_attribute hpage_pmd_size_attr = __ATTR_RO(hpage_pmd_size); +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL +static ssize_t numa_migrate_show(struct kobject *kobj, + struct kobj_attribute *attr, char *buf) +{ + return single_hugepage_flag_show(kobj, attr, buf, + TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG); +} +static ssize_t numa_migrate_store(struct kobject *kobj, + struct kobj_attribute *attr, const char *buf, size_t count) +{ + return single_hugepage_flag_store(kobj, attr, buf, count, + TRANSPARENT_HUGEPAGE_NUMA_MIGRATE_ENABLE_FLAG); +} +static struct kobj_attribute numa_migrate_attr = + __ATTR(numa_migrate, 0644, numa_migrate_show, numa_migrate_store); +#endif + static struct attribute *hugepage_attr[] = { &enabled_attr.attr, &defrag_attr.attr, @@ -323,6 +343,9 @@ static struct attribute *hugepage_attr[] = { &hpage_pmd_size_attr.attr, #ifdef CONFIG_SHMEM &shmem_enabled_attr.attr, +#endif +#ifdef CONFIG_NUMA_MIGRATE_THP_CONTROL + &numa_migrate_attr.attr, #endif NULL, }; diff --git a/mm/migrate.c b/mm/migrate.c index 3f5b217d5af1..f7eb9b4c8668 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -2157,6 +2157,9 @@ int migrate_misplaced_page(struct page *page, struct vm_area_struct *vma, */ compound = PageTransHuge(page); + if (compound && !thp_can_numa_migrate()) + return 0; + if (compound) new = alloc_misplaced_dst_page_thp; else -- 2.25.1

2 1

[PATCH OLK-5.10 v2] ax25: Fix refcount imbalance on inbound connections
by Dong Chenchen 02 Aug '24

02 Aug '24

From: Lars Kellogg-Stedman <lars(a)oddbit.com> mainline inclusion from mainline-v6.10-rc3 commit 3c34fb0bd4a4237592c5ecb5b2e2531900c55774 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZYN CVE: CVE-2024-40910 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When releasing a socket in ax25_release(), we call netdev_put() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdev_hold(). This imbalance leads to refcount errors, and ultimately to kernel crashes. A typical call trace for the above situation will start with one of the following errors: refcount_t: decrement hit 0; leaking memory. refcount_t: underflow; use-after-free. And will then have a trace like: Call Trace: <TASK> ? show_regs+0x64/0x70 ? __warn+0x83/0x120 ? refcount_warn_saturate+0xb2/0x100 ? report_bug+0x158/0x190 ? prb_read_valid+0x20/0x30 ? handle_bug+0x3e/0x70 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xb2/0x100 ? refcount_warn_saturate+0xb2/0x100 ax25_release+0x2ad/0x360 __sock_release+0x35/0xa0 sock_close+0x19/0x20 [...] On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop: unregister_netdevice: waiting for ax0 to become free. Usage count = 0 This patch corrects these issues by ensuring that we call netdev_hold() and ax25_dev_hold() for new connections in ax25_accept(). This makes the logic leading to ax25_accept() match the logic for ax25_bind(): in both cases we increment the refcount, which is ultimately decremented in ax25_release(). Fixes: 9fd75b66b8f6 ("ax25: Fix refcount leaks caused by ax25_cb_del()") Signed-off-by: Lars Kellogg-Stedman <lars(a)oddbit.com> Tested-by: Duoming Zhou <duoming(a)zju.edu.cn> Tested-by: Dan Cross <crossd(a)gmail.com> Tested-by: Chris Maness <christopher.maness(a)gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/r/20240529210242.3346844-2-lars@oddbit.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ax25/af_ax25.c [commit d62607c3fe45 add netdev_hold() to track refcnt, which not merged lead to conflicts. We can use dev_hold().] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/ax25/af_ax25.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c index a1f4cb836fcf..8d45ca82bd7d 100644 --- a/net/ax25/af_ax25.c +++ b/net/ax25/af_ax25.c @@ -1369,8 +1369,10 @@ static int ax25_accept(struct socket *sock, struct socket *newsock, int flags, { struct sk_buff *skb; struct sock *newsk; + ax25_dev *ax25_dev; DEFINE_WAIT(wait); struct sock *sk; + ax25_cb *ax25; int err = 0; if (sock->state != SS_UNCONNECTED) @@ -1425,6 +1427,10 @@ static int ax25_accept(struct socket *sock, struct socket *newsock, int flags, kfree_skb(skb); sk_acceptq_removed(sk); newsock->state = SS_CONNECTED; + ax25 = sk_to_ax25(newsk); + ax25_dev = ax25->ax25_dev; + dev_hold(ax25_dev->dev); + ax25_dev_hold(ax25_dev); out: release_sock(sk); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1 v2] ax25: Fix refcount imbalance on inbound connections
by Dong Chenchen 02 Aug '24

02 Aug '24

From: Lars Kellogg-Stedman <lars(a)oddbit.com> mainline inclusion from mainline-v6.10-rc3 commit 3c34fb0bd4a4237592c5ecb5b2e2531900c55774 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZYN CVE: CVE-2024-40910 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When releasing a socket in ax25_release(), we call netdev_put() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdev_hold(). This imbalance leads to refcount errors, and ultimately to kernel crashes. A typical call trace for the above situation will start with one of the following errors: refcount_t: decrement hit 0; leaking memory. refcount_t: underflow; use-after-free. And will then have a trace like: Call Trace: <TASK> ? show_regs+0x64/0x70 ? __warn+0x83/0x120 ? refcount_warn_saturate+0xb2/0x100 ? report_bug+0x158/0x190 ? prb_read_valid+0x20/0x30 ? handle_bug+0x3e/0x70 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xb2/0x100 ? refcount_warn_saturate+0xb2/0x100 ax25_release+0x2ad/0x360 __sock_release+0x35/0xa0 sock_close+0x19/0x20 [...] On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop: unregister_netdevice: waiting for ax0 to become free. Usage count = 0 This patch corrects these issues by ensuring that we call netdev_hold() and ax25_dev_hold() for new connections in ax25_accept(). This makes the logic leading to ax25_accept() match the logic for ax25_bind(): in both cases we increment the refcount, which is ultimately decremented in ax25_release(). Fixes: 9fd75b66b8f6 ("ax25: Fix refcount leaks caused by ax25_cb_del()") Signed-off-by: Lars Kellogg-Stedman <lars(a)oddbit.com> Tested-by: Duoming Zhou <duoming(a)zju.edu.cn> Tested-by: Dan Cross <crossd(a)gmail.com> Tested-by: Chris Maness <christopher.maness(a)gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/r/20240529210242.3346844-2-lars@oddbit.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ax25/af_ax25.c [commit d62607c3fe45 add netdev_hold() to track refcnt, which not merged lead to conflicts. We can use dev_hold().] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/ax25/af_ax25.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c index a1f4cb836fcf..8d45ca82bd7d 100644 --- a/net/ax25/af_ax25.c +++ b/net/ax25/af_ax25.c @@ -1369,8 +1369,10 @@ static int ax25_accept(struct socket *sock, struct socket *newsock, int flags, { struct sk_buff *skb; struct sock *newsk; + ax25_dev *ax25_dev; DEFINE_WAIT(wait); struct sock *sk; + ax25_cb *ax25; int err = 0; if (sock->state != SS_UNCONNECTED) @@ -1425,6 +1427,10 @@ static int ax25_accept(struct socket *sock, struct socket *newsock, int flags, kfree_skb(skb); sk_acceptq_removed(sk); newsock->state = SS_CONNECTED; + ax25 = sk_to_ax25(newsk); + ax25_dev = ax25->ax25_dev; + dev_hold(ax25_dev->dev); + ax25_dev_hold(ax25_dev); out: release_sock(sk); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] filelock: Fix fcntl/close race recovery compat path
by Yifan Qiao 02 Aug '24

02 Aug '24

From: Jann Horn <jannh(a)google.com> stable inclusion from stable-v4.19.319 commit a561145f3ae973ebf3e0aee41624e92a6c5cb38d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEF4 CVE: CVE-2024-41020 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit f8138f2ad2f745b9a1c696a05b749eabe44337ea upstream. When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected"), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels. Thanks to Greg KH for stumbling over this while doing the stable backport... Apply exactly the same fix to the compat path for 32-bit kernels. Fixes: c293621bbf67 ("[PATCH] stale POSIX lock handling") Cc: stable(a)kernel.org Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=2563 Signed-off-by: Jann Horn <jannh(a)google.com> Link: https://lore.kernel.org/r/20240723-fs-lock-recover-compatfix-v1-1-148096719… Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/locks.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/fs/locks.c b/fs/locks.c index 6e118955b9b6..6280fbb613de 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -2661,8 +2661,9 @@ int fcntl_setlk64(unsigned int fd, struct file *filp, unsigned int cmd, error = do_lock_file_wait(filp, cmd, file_lock); /* - * Attempt to detect a close/fcntl race and recover by releasing the - * lock that was just acquired. There is no need to do that when we're + * Detect close/fcntl races and recover by zapping all POSIX locks + * associated with this file and our files_struct, just like on + * filp_flush(). There is no need to do that when we're * unlocking though, or for OFD locks. */ if (!error && file_lock->fl_type != F_UNLCK && @@ -2676,9 +2677,7 @@ int fcntl_setlk64(unsigned int fd, struct file *filp, unsigned int cmd, f = fcheck(fd); spin_unlock(&current->files->file_lock); if (f != filp) { - file_lock->fl_type = F_UNLCK; - error = do_lock_file_wait(filp, cmd, file_lock); - WARN_ON_ONCE(error); + locks_remove_posix(filp, &current->files); error = -EBADF; } } -- 2.39.2

2 1

[PATCH OLK-5.10] filelock: Fix fcntl/close race recovery compat path
by Yifan Qiao 02 Aug '24

02 Aug '24

From: Jann Horn <jannh(a)google.com> stable inclusion from stable-v4.19.319 commit a561145f3ae973ebf3e0aee41624e92a6c5cb38d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAGEF4 CVE: CVE-2024-41020 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit f8138f2ad2f745b9a1c696a05b749eabe44337ea upstream. When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected"), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels. Thanks to Greg KH for stumbling over this while doing the stable backport... Apply exactly the same fix to the compat path for 32-bit kernels. Fixes: c293621bbf67 ("[PATCH] stale POSIX lock handling") Cc: stable(a)kernel.org Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=2563 Signed-off-by: Jann Horn <jannh(a)google.com> Link: https://lore.kernel.org/r/20240723-fs-lock-recover-compatfix-v1-1-148096719… Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/locks.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/fs/locks.c b/fs/locks.c index f4504008a2ea..6f27ec4f58da 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -2661,8 +2661,9 @@ int fcntl_setlk64(unsigned int fd, struct file *filp, unsigned int cmd, error = do_lock_file_wait(filp, cmd, file_lock); /* - * Attempt to detect a close/fcntl race and recover by releasing the - * lock that was just acquired. There is no need to do that when we're + * Detect close/fcntl races and recover by zapping all POSIX locks + * associated with this file and our files_struct, just like on + * filp_flush(). There is no need to do that when we're * unlocking though, or for OFD locks. */ if (!error && file_lock->fl_type != F_UNLCK && @@ -2676,9 +2677,7 @@ int fcntl_setlk64(unsigned int fd, struct file *filp, unsigned int cmd, f = fcheck(fd); spin_unlock(&current->files->file_lock); if (f != filp) { - file_lock->fl_type = F_UNLCK; - error = do_lock_file_wait(filp, cmd, file_lock); - WARN_ON_ONCE(error); + locks_remove_posix(filp, &current->files); error = -EBADF; } } -- 2.39.2

2 1

[PATCH OLK-6.6 0/1] kvm : add coda feature
by y00878127 02 Aug '24

02 Aug '24

From: Xiangkai Yang <yangxiangkai(a)huawei.com> virtCCA feature Xiangkai Yang (1): clean code drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c | 3 ++- virt/kvm/vfio.c | 1 - 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.25.1

2 2

[PATCH OLK-6.6 0/1] kvm : add coda feature
by l00500167 02 Aug '24

02 Aug '24

From: Xiangkai Yang <yangxiangkai(a)huawei.com> virtCCA feature Xiangkai Yang (1): clean code drivers/iommu/arm/arm-smmu-v3/arm-s-smmu-v3.c | 3 ++- virt/kvm/vfio.c | 1 - 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.25.1

2 2