- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] net: vmxnet3: fix possible NULL pointer dereference in vmxnet3_rq_cleanup()
by Zhengchao Shao 22 Aug '23

22 Aug '23

From: Zixuan Fu <r33s3n6(a)gmail.com> mainline inclusion from mainline-v5.18-rc1 commit edf410cb74dc612fd47ef5be319c5a0bcd6e6ccd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7UWI8 CVE: CVE-2023-4459 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In vmxnet3_rq_create(), when dma_alloc_coherent() fails, vmxnet3_rq_destroy() is called. It sets rq->rx_ring[i].base to NULL. Then vmxnet3_rq_create() returns an error to its callers mxnet3_rq_create_all() -> vmxnet3_change_mtu(). Then vmxnet3_change_mtu() calls vmxnet3_force_close() -> dev_close() in error handling code. And the driver calls vmxnet3_close() -> vmxnet3_quiesce_dev() -> vmxnet3_rq_cleanup_all() -> vmxnet3_rq_cleanup(). In vmxnet3_rq_cleanup(), rq->rx_ring[ring_idx].base is accessed, but this variable is NULL, causing a NULL pointer dereference. To fix this possible bug, an if statement is added to check whether rq->rx_ring[0].base is NULL in vmxnet3_rq_cleanup() and exit early if so. The error log in our fault-injection testing is shown as follows: [ 65.220135] BUG: kernel NULL pointer dereference, address: 0000000000000008 ... [ 65.222633] RIP: 0010:vmxnet3_rq_cleanup_all+0x396/0x4e0 [vmxnet3] ... [ 65.227977] Call Trace: ... [ 65.228262] vmxnet3_quiesce_dev+0x80f/0x8a0 [vmxnet3] [ 65.228580] vmxnet3_close+0x2c4/0x3f0 [vmxnet3] [ 65.228866] __dev_close_many+0x288/0x350 [ 65.229607] dev_close_many+0xa4/0x480 [ 65.231124] dev_close+0x138/0x230 [ 65.231933] vmxnet3_force_close+0x1f0/0x240 [vmxnet3] [ 65.232248] vmxnet3_change_mtu+0x75d/0x920 [vmxnet3] ... Fixes: d1a890fa37f27 ("net: VMware virtual Ethernet NIC driver: vmxnet3") Reported-by: TOTE Robot <oslab(a)tsinghua.edu.cn> Signed-off-by: Zixuan Fu <r33s3n6(a)gmail.com> Link: https://lore.kernel.org/r/20220514050711.2636709-1-r33s3n6@gmail.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/vmxnet3/vmxnet3_drv.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c index e454dfc9ad8f..f5cf7643289b 100644 --- a/drivers/net/vmxnet3/vmxnet3_drv.c +++ b/drivers/net/vmxnet3/vmxnet3_drv.c @@ -1584,6 +1584,10 @@ vmxnet3_rq_cleanup(struct vmxnet3_rx_queue *rq, u32 i, ring_idx; struct Vmxnet3_RxDesc *rxd; + /* ring has already been cleaned up */ + if (!rq->rx_ring[0].base) + return; + for (ring_idx = 0; ring_idx < 2; ring_idx++) { for (i = 0; i < rq->rx_ring[ring_idx].size; i++) { #ifdef __BIG_ENDIAN_BITFIELD -- 2.34.1

2 1

[PATCH OLK-5.10] net: bridge: multicast: notify switchdev driver whenever MC processing gets disabled
by Zhengchao Shao 22 Aug '23

22 Aug '23

From: Oleksandr Mazur <oleksandr.mazur(a)plvision.eu> mainline inclusion from mainline-v5.17-rc5 commit c832962ac972082b3a1f89775c9d4274c8cb5670 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7V613 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Whenever bridge driver hits the max capacity of MDBs, it disables the MC processing (by setting corresponding bridge option), but never notifies switchdev about such change (the notifiers are called only upon explicit setting of this option, through the registered netlink interface). This could lead to situation when Software MDB processing gets disabled, but this event never gets offloaded to the underlying Hardware. Fix this by adding a notify message in such case. Fixes: 147c1e9b902c ("switchdev: bridge: Offload multicast disabled") Signed-off-by: Oleksandr Mazur <oleksandr.mazur(a)plvision.eu> Acked-by: Nikolay Aleksandrov <nikolay(a)nvidia.com> Link: https://lore.kernel.org/r/20220215165303.31908-1-oleksandr.mazur@plvision.eu Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/bridge/br_multicast.c Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/bridge/br_multicast.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c index de79fbfe1611..e2b1bb3de4a1 100644 --- a/net/bridge/br_multicast.c +++ b/net/bridge/br_multicast.c @@ -48,6 +48,8 @@ static const struct rhashtable_params br_sg_port_rht_params = { .automatic_shrinking = true, }; +static void br_mc_disabled_update(struct net_device *dev, bool value); + static void br_multicast_start_querier(struct net_bridge *br, struct bridge_mcast_own_query *query); static void br_multicast_add_router(struct net_bridge *br, @@ -1040,6 +1042,7 @@ struct net_bridge_mdb_entry *br_multicast_new_group(struct net_bridge *br, return mp; if (atomic_read(&br->mdb_hash_tbl.nelems) >= br->hash_max) { + br_mc_disabled_update(br->dev, false); br_opt_toggle(br, BROPT_MULTICAST_ENABLED, false); return ERR_PTR(-E2BIG); } -- 2.34.1

2 1

[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

2024

2023

2022

2021

2020

2019

Kernel