- Kernel - mailweb.openeuler.org

[PATCH openEuler-23.09 00/12] Add SDEI Watchdog Support
by Xiongfeng Wang 22 Aug '23

22 Aug '23

Xiongfeng Wang (12): watchdog: make hardlockup detect code public firmware: arm_sdei: add interrupt binding api firmware: arm_sdei: make 'sdei_api_event_disable/enable' public lockup_detector: init lockup detector after all the init_calls watchdog: add nmi_watchdog support for arm64 based on SDEI sdei_watchdog: refresh 'last_timestamp' when enabling nmi_watchdog sdei_watchdog: clear EOI of the secure timer before kdump sdei_watchdog: set secure timer period base on 'watchdog_thresh' kprobes/arm64: Blacklist sdei watchdog callback functions sdei_watchdog: avoid possible false hardlockup init: only move down lockup_detector_init() when sdei_watchdog is enabled openeuler_defconfig: Enable SDEI Watchdog arch/arm64/configs/openeuler_defconfig | 2 + arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/machine_kexec.c | 10 ++ arch/arm64/kernel/watchdog_sdei.c | 156 +++++++++++++++++++++++++ drivers/firmware/arm_sdei.c | 26 ++++- include/linux/arm_sdei.h | 5 + include/linux/nmi.h | 24 +++- include/uapi/linux/arm_sdei.h | 2 + init/main.c | 7 +- kernel/Makefile | 2 +- kernel/watchdog.c | 2 + kernel/watchdog_hld.c | 61 ++++++---- lib/Kconfig.debug | 8 +- 13 files changed, 278 insertions(+), 28 deletions(-) create mode 100644 arch/arm64/kernel/watchdog_sdei.c -- 2.20.1

2 13

[PATCH openEuler-22.03-LTS-SP1 0/5] fix CVE-2023-20593 for openEuler
by Yu Liao 22 Aug '23

22 Aug '23

AMD Zen2 architecture Zenbleed remote execution vulnerability. The optimal fix is through microcode but in the case the proper microcode revision has not been applied, enable a fallback fix for openEuler. Arnaldo Carvalho de Melo (1): tools arch x86: Sync the msr-index.h copy with the kernel sources Borislav Petkov (1): x86/cpu: Restore AMD's DE_CFG MSR after resume Borislav Petkov (AMD) (2): x86/cpu/amd: Move the errata checking functionality up x86/cpu/amd: Add a Zenbleed fix Cristian Ciocaltea (1): x86/cpu/amd: Enable Zenbleed fix for AMD Custom APU 0405 arch/x86/include/asm/microcode.h | 1 + arch/x86/include/asm/microcode_amd.h | 2 + arch/x86/include/asm/msr-index.h | 9 +- arch/x86/kernel/cpu/amd.c | 206 ++++++++++++++++--------- arch/x86/kernel/cpu/common.c | 1 + arch/x86/kernel/cpu/hygon.c | 4 +- arch/x86/kvm/svm/svm.c | 10 +- arch/x86/kvm/x86.c | 2 +- arch/x86/power/cpu.c | 1 + tools/arch/x86/include/asm/msr-index.h | 9 +- 10 files changed, 155 insertions(+), 90 deletions(-) -- 2.25.1

2 6

[PATCH openEuler-22.03-LTS 0/5] fix CVE-2023-20593 for openEuler
by Yu Liao 22 Aug '23

22 Aug '23

AMD Zen2 architecture Zenbleed remote execution vulnerability. The optimal fix is through microcode but in the case the proper microcode revision has not been applied, enable a fallback fix for openEuler. Arnaldo Carvalho de Melo (1): tools arch x86: Sync the msr-index.h copy with the kernel sources Borislav Petkov (1): x86/cpu: Restore AMD's DE_CFG MSR after resume Borislav Petkov (AMD) (2): x86/cpu/amd: Move the errata checking functionality up x86/cpu/amd: Add a Zenbleed fix Cristian Ciocaltea (1): x86/cpu/amd: Enable Zenbleed fix for AMD Custom APU 0405 arch/x86/include/asm/microcode.h | 1 + arch/x86/include/asm/microcode_amd.h | 2 + arch/x86/include/asm/msr-index.h | 9 +- arch/x86/kernel/cpu/amd.c | 206 ++++++++++++++++--------- arch/x86/kernel/cpu/common.c | 1 + arch/x86/kernel/cpu/hygon.c | 4 +- arch/x86/kvm/svm/svm.c | 10 +- arch/x86/kvm/x86.c | 2 +- arch/x86/power/cpu.c | 1 + tools/arch/x86/include/asm/msr-index.h | 9 +- 10 files changed, 155 insertions(+), 90 deletions(-) -- 2.25.1

2 6

[PATCH openEuler-1.0-LTS] tcp: Reduce chance of collisions in inet6_hashfn().
by Wang Yufen 22 Aug '23

22 Aug '23

From: Stewart Smith <trawets(a)amazon.com> stable inclusion from stable-v4.19.291 commit d11b0df7ddf1831f3e170972f43186dad520bfcc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7FUFX CVE: CVE-2023-1206 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d11b0df7ddf1831f3e170972f43186dad520bfcc ] For both IPv4 and IPv6 incoming TCP connections are tracked in a hash table with a hash over the source & destination addresses and ports. However, the IPv6 hash is insufficient and can lead to a high rate of collisions. The IPv6 hash used an XOR to fit everything into the 96 bits for the fast jenkins hash, meaning it is possible for an external entity to ensure the hash collides, thus falling back to a linear search in the bucket, which is slow. We take the approach of hash the full length of IPv6 address in __ipv6_addr_jhash() so that all users can benefit from a more secure version. While this may look like it adds overhead, the reality of modern CPUs means that this is unmeasurable in real world scenarios. In simulating with llvm-mca, the increase in cycles for the hashing code was ~16 cycles on Skylake (from a base of ~155), and an extra ~9 on Nehalem (base of ~173). In commit dd6d2910c5e0 ("netfilter: conntrack: switch to siphash") netfilter switched from a jenkins hash to a siphash, but even the faster hsiphash is a more significant overhead (~20-30%) in some preliminary testing. So, in this patch, we keep to the more conservative approach to ensure we don't add much overhead per SYN. In testing, this results in a consistently even spread across the connection buckets. In both testing and real-world scenarios, we have not found any measurable performance impact. Fixes: 08dcdbf6a7b9 ("ipv6: use a stronger hash for tcp") Signed-off-by: Stewart Smith <trawets(a)amazon.com> Signed-off-by: Samuel Mendoza-Jonas <samjonas(a)amazon.com> Suggested-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Kuniyuki Iwashima <kuniyu(a)amazon.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Link: https://lore.kernel.org/r/20230721222410.17914-1-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Yufen <wangyufen(a)huawei.com> --- include/net/ipv6.h | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/include/net/ipv6.h b/include/net/ipv6.h index 0c88324..3a55a093 100644 --- a/include/net/ipv6.h +++ b/include/net/ipv6.h @@ -602,12 +602,8 @@ static inline u32 ipv6_addr_hash(const struct in6_addr *a) /* more secured version of ipv6_addr_hash() */ static inline u32 __ipv6_addr_jhash(const struct in6_addr *a, const u32 initval) { - u32 v = (__force u32)a->s6_addr32[0] ^ (__force u32)a->s6_addr32[1]; - - return jhash_3words(v, - (__force u32)a->s6_addr32[2], - (__force u32)a->s6_addr32[3], - initval); + return jhash2((__force const u32 *)a->s6_addr32, + ARRAY_SIZE(a->s6_addr32), initval); } static inline bool ipv6_addr_loopback(const struct in6_addr *a) -- 1.8.3.1

2 1

[PATCH OLK-5.10] tcp: Reduce chance of collisions in inet6_hashfn().
by Wang Yufen 22 Aug '23

22 Aug '23

From: Stewart Smith <trawets(a)amazon.com> stable inclusion from stable-v5.10.190 commit d11b0df7ddf1831f3e170972f43186dad520bfcc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7FUFX CVE: CVE-2023-1206 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d11b0df7ddf1831f3e170972f43186dad520bfcc ] For both IPv4 and IPv6 incoming TCP connections are tracked in a hash table with a hash over the source & destination addresses and ports. However, the IPv6 hash is insufficient and can lead to a high rate of collisions. The IPv6 hash used an XOR to fit everything into the 96 bits for the fast jenkins hash, meaning it is possible for an external entity to ensure the hash collides, thus falling back to a linear search in the bucket, which is slow. We take the approach of hash the full length of IPv6 address in __ipv6_addr_jhash() so that all users can benefit from a more secure version. While this may look like it adds overhead, the reality of modern CPUs means that this is unmeasurable in real world scenarios. In simulating with llvm-mca, the increase in cycles for the hashing code was ~16 cycles on Skylake (from a base of ~155), and an extra ~9 on Nehalem (base of ~173). In commit dd6d2910c5e0 ("netfilter: conntrack: switch to siphash") netfilter switched from a jenkins hash to a siphash, but even the faster hsiphash is a more significant overhead (~20-30%) in some preliminary testing. So, in this patch, we keep to the more conservative approach to ensure we don't add much overhead per SYN. In testing, this results in a consistently even spread across the connection buckets. In both testing and real-world scenarios, we have not found any measurable performance impact. Fixes: 08dcdbf6a7b9 ("ipv6: use a stronger hash for tcp") Signed-off-by: Stewart Smith <trawets(a)amazon.com> Signed-off-by: Samuel Mendoza-Jonas <samjonas(a)amazon.com> Suggested-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Kuniyuki Iwashima <kuniyu(a)amazon.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Link: https://lore.kernel.org/r/20230721222410.17914-1-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Yufen <wangyufen(a)huawei.com> --- include/net/ipv6.h | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/include/net/ipv6.h b/include/net/ipv6.h index 9a5b617..f2585cc 100644 --- a/include/net/ipv6.h +++ b/include/net/ipv6.h @@ -663,12 +663,8 @@ static inline u32 ipv6_addr_hash(const struct in6_addr *a) /* more secured version of ipv6_addr_hash() */ static inline u32 __ipv6_addr_jhash(const struct in6_addr *a, const u32 initval) { - u32 v = (__force u32)a->s6_addr32[0] ^ (__force u32)a->s6_addr32[1]; - - return jhash_3words(v, - (__force u32)a->s6_addr32[2], - (__force u32)a->s6_addr32[3], - initval); + return jhash2((__force const u32 *)a->s6_addr32, + ARRAY_SIZE(a->s6_addr32), initval); } static inline bool ipv6_addr_loopback(const struct in6_addr *a) -- 1.8.3.1

2 1

[OLK-5.10] tcp: Reduce chance of collisions in inet6_hashfn().
by Wang Yufen 22 Aug '23

22 Aug '23

From: Stewart Smith <trawets(a)amazon.com> stable inclusion from stable-v5.10.190 commit d11b0df7ddf1831f3e170972f43186dad520bfcc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7FUFX CVE: CVE-2023-1206 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d11b0df7ddf1831f3e170972f43186dad520bfcc ] For both IPv4 and IPv6 incoming TCP connections are tracked in a hash table with a hash over the source & destination addresses and ports. However, the IPv6 hash is insufficient and can lead to a high rate of collisions. The IPv6 hash used an XOR to fit everything into the 96 bits for the fast jenkins hash, meaning it is possible for an external entity to ensure the hash collides, thus falling back to a linear search in the bucket, which is slow. We take the approach of hash the full length of IPv6 address in __ipv6_addr_jhash() so that all users can benefit from a more secure version. While this may look like it adds overhead, the reality of modern CPUs means that this is unmeasurable in real world scenarios. In simulating with llvm-mca, the increase in cycles for the hashing code was ~16 cycles on Skylake (from a base of ~155), and an extra ~9 on Nehalem (base of ~173). In commit dd6d2910c5e0 ("netfilter: conntrack: switch to siphash") netfilter switched from a jenkins hash to a siphash, but even the faster hsiphash is a more significant overhead (~20-30%) in some preliminary testing. So, in this patch, we keep to the more conservative approach to ensure we don't add much overhead per SYN. In testing, this results in a consistently even spread across the connection buckets. In both testing and real-world scenarios, we have not found any measurable performance impact. Fixes: 08dcdbf6a7b9 ("ipv6: use a stronger hash for tcp") Signed-off-by: Stewart Smith <trawets(a)amazon.com> Signed-off-by: Samuel Mendoza-Jonas <samjonas(a)amazon.com> Suggested-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Kuniyuki Iwashima <kuniyu(a)amazon.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Link: https://lore.kernel.org/r/20230721222410.17914-1-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Yufen <wangyufen(a)huawei.com> --- include/net/ipv6.h | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/include/net/ipv6.h b/include/net/ipv6.h index 9a5b617..f2585cc 100644 --- a/include/net/ipv6.h +++ b/include/net/ipv6.h @@ -663,12 +663,8 @@ static inline u32 ipv6_addr_hash(const struct in6_addr *a) /* more secured version of ipv6_addr_hash() */ static inline u32 __ipv6_addr_jhash(const struct in6_addr *a, const u32 initval) { - u32 v = (__force u32)a->s6_addr32[0] ^ (__force u32)a->s6_addr32[1]; - - return jhash_3words(v, - (__force u32)a->s6_addr32[2], - (__force u32)a->s6_addr32[3], - initval); + return jhash2((__force const u32 *)a->s6_addr32, + ARRAY_SIZE(a->s6_addr32), initval); } static inline bool ipv6_addr_loopback(const struct in6_addr *a) -- 1.8.3.1

1 0

[PATCH OLK-5.10] xsk: Initialise xskb free_list_node
by Zhengchao Shao 22 Aug '23

22 Aug '23

From: Ciara Loftus <ciara.loftus(a)intel.com> mainline inclusion from mainline-v5.16-rc8 commit 5bec7ca2be6955ca1aa0d7bae2b981de9b1c9844 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7UZT5 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- This commit initialises the xskb's free_list_node when the xskb is allocated. This prevents a potential false negative returned from a call to list_empty for that node, such as the one introduced in commit 199d983bc015 ("xsk: Fix crash on double free in buffer pool") In my environment this issue caused packets to not be received by the xdpsock application if the traffic was running prior to application launch. This happened when the first batch of packets failed the xskmap lookup and XDP_PASS was returned from the bpf program. This action is handled in the i40e zc driver (and others) by allocating an skbuff, freeing the xdp_buff and adding the associated xskb to the xsk_buff_pool's free_list if it hadn't been added already. Without this fix, the xskb is not added to the free_list because the check to determine if it was added already returns an invalid positive result. Later, this caused allocation errors in the driver and the failure to receive packets. Fixes: 199d983bc015 ("xsk: Fix crash on double free in buffer pool") Fixes: 2b43470add8c ("xsk: Introduce AF_XDP buffer allocation API") Signed-off-by: Ciara Loftus <ciara.loftus(a)intel.com> Acked-by: Magnus Karlsson <magnus.karlsson(a)intel.com> Link: https://lore.kernel.org/r/20211220155250.2746-1-ciara.loftus@intel.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/xdp/xsk_buff_pool.c Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/xdp/xsk_buff_pool.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/xdp/xsk_buff_pool.c b/net/xdp/xsk_buff_pool.c index c347e52f58df..383c083faa01 100644 --- a/net/xdp/xsk_buff_pool.c +++ b/net/xdp/xsk_buff_pool.c @@ -81,6 +81,7 @@ struct xsk_buff_pool *xp_create_and_assign_umem(struct xdp_sock *xs, xskb = &pool->heads[i]; xskb->pool = pool; xskb->xdp.frame_sz = umem->chunk_size - umem->headroom; + INIT_LIST_HEAD(&xskb->free_list_node); pool->free_heads[i] = xskb; } -- 2.34.1

2 1

[openEuler-1.0-LTS] tcp: Reduce chance of collisions in inet6_hashfn().
by Wang Yufen 22 Aug '23

22 Aug '23

From: Stewart Smith <trawets(a)amazon.com> stable inclusion from stable-v4.19.291 commit d11b0df7ddf1831f3e170972f43186dad520bfcc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7FUFX CVE: CVE-2023-1206 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d11b0df7ddf1831f3e170972f43186dad520bfcc ] For both IPv4 and IPv6 incoming TCP connections are tracked in a hash table with a hash over the source & destination addresses and ports. However, the IPv6 hash is insufficient and can lead to a high rate of collisions. The IPv6 hash used an XOR to fit everything into the 96 bits for the fast jenkins hash, meaning it is possible for an external entity to ensure the hash collides, thus falling back to a linear search in the bucket, which is slow. We take the approach of hash the full length of IPv6 address in __ipv6_addr_jhash() so that all users can benefit from a more secure version. While this may look like it adds overhead, the reality of modern CPUs means that this is unmeasurable in real world scenarios. In simulating with llvm-mca, the increase in cycles for the hashing code was ~16 cycles on Skylake (from a base of ~155), and an extra ~9 on Nehalem (base of ~173). In commit dd6d2910c5e0 ("netfilter: conntrack: switch to siphash") netfilter switched from a jenkins hash to a siphash, but even the faster hsiphash is a more significant overhead (~20-30%) in some preliminary testing. So, in this patch, we keep to the more conservative approach to ensure we don't add much overhead per SYN. In testing, this results in a consistently even spread across the connection buckets. In both testing and real-world scenarios, we have not found any measurable performance impact. Fixes: 08dcdbf6a7b9 ("ipv6: use a stronger hash for tcp") Signed-off-by: Stewart Smith <trawets(a)amazon.com> Signed-off-by: Samuel Mendoza-Jonas <samjonas(a)amazon.com> Suggested-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Kuniyuki Iwashima <kuniyu(a)amazon.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Link: https://lore.kernel.org/r/20230721222410.17914-1-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Yufen <wangyufen(a)huawei.com> --- include/net/ipv6.h | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/include/net/ipv6.h b/include/net/ipv6.h index 0c88324..3a55a093 100644 --- a/include/net/ipv6.h +++ b/include/net/ipv6.h @@ -602,12 +602,8 @@ static inline u32 ipv6_addr_hash(const struct in6_addr *a) /* more secured version of ipv6_addr_hash() */ static inline u32 __ipv6_addr_jhash(const struct in6_addr *a, const u32 initval) { - u32 v = (__force u32)a->s6_addr32[0] ^ (__force u32)a->s6_addr32[1]; - - return jhash_3words(v, - (__force u32)a->s6_addr32[2], - (__force u32)a->s6_addr32[3], - initval); + return jhash2((__force const u32 *)a->s6_addr32, + ARRAY_SIZE(a->s6_addr32), initval); } static inline bool ipv6_addr_loopback(const struct in6_addr *a) -- 1.8.3.1

1 0

[PATCH OLK-5.10] fs: jfs: fix possible NULL pointer dereference in dbFree()
by Li Nan 22 Aug '23

22 Aug '23

From: Zixuan Fu <r33s3n6(a)gmail.com> mainline inclusion from mainline-v5.19-rc1 commit 0d4837fdb796f99369cf7691d33de1b856bcaf1f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7TT9F CVE: CVE-2023-4385 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In our fault-injection testing, the variable "nblocks" in dbFree() can be zero when kmalloc_array() fails in dtSearch(). In this case, the variable "mp" in dbFree() would be NULL and then it is dereferenced in "write_metapage(mp)". The failure log is listed as follows: [ 13.824137] BUG: kernel NULL pointer dereference, address: 0000000000000020 ... [ 13.827416] RIP: 0010:dbFree+0x5f7/0x910 [jfs] [ 13.834341] Call Trace: [ 13.834540] <TASK> [ 13.834713] txFreeMap+0x7b4/0xb10 [jfs] [ 13.835038] txUpdateMap+0x311/0x650 [jfs] [ 13.835375] jfs_lazycommit+0x5f2/0xc70 [jfs] [ 13.835726] ? sched_dynamic_update+0x1b0/0x1b0 [ 13.836092] kthread+0x3c2/0x4a0 [ 13.836355] ? txLockFree+0x160/0x160 [jfs] [ 13.836763] ? kthread_unuse_mm+0x160/0x160 [ 13.837106] ret_from_fork+0x1f/0x30 [ 13.837402] </TASK> ... This patch adds a NULL check of "mp" before "write_metapage(mp)" is called. Reported-by: TOTE Robot <oslab(a)tsinghua.edu.cn> Signed-off-by: Zixuan Fu <r33s3n6(a)gmail.com> Signed-off-by: Dave Kleikamp <dave.kleikamp(a)oracle.com> Signed-off-by: Li Nan <linan122(a)huawei.com> --- fs/jfs/jfs_dmap.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c index 2c9493011aec..7b2c9e60dabc 100644 --- a/fs/jfs/jfs_dmap.c +++ b/fs/jfs/jfs_dmap.c @@ -3262,7 +3262,8 @@ int dbAllocBottomUp(struct inode *ip, s64 blkno, s64 nblocks) } /* write the last buffer. */ - write_metapage(mp); + if (mp) + write_metapage(mp); IREAD_UNLOCK(ipbmap); -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS v3 0/3] fix NULL pointer dereference in __nf_nat_mangle_tcp_packet
by Zhengchao Shao 22 Aug '23

22 Aug '23

When nf_nat_ipv4.ko is not loaded, l3proto is NULL pointer. If the csum_recalc function of l3proto is called, it will cause NULL pointer access issue. --- v3: add space after return type for Patch 3/3 v2: modify commit message for Patch 3/3 --- Florian Westphal (2): netfilter: nat: remove csum_recalc hook netfilter: nat: fix udp checksum corruption Zhengchao Shao (1): netfilter: nat: fix kabi change include/net/netfilter/nf_nat_l3proto.h | 4 ++ net/ipv4/netfilter/nf_nat_l3proto_ipv4.c | 19 ------ net/ipv6/netfilter/nf_nat_l3proto_ipv6.c | 19 ------ net/netfilter/Makefile | 2 +- net/netfilter/nf_nat_helper.c | 12 ++-- net/netfilter/nf_nat_proto.c | 74 ++++++++++++++++++++++++ 6 files changed, 83 insertions(+), 47 deletions(-) create mode 100644 net/netfilter/nf_nat_proto.c -- 2.34.1

2 4

2024

2023

2022

2021

2020

2019

Kernel