- Kernel - mailweb.openeuler.org

[PATCH openEuler-22.03-LTS-SP2] spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected
by Guo Mengqi 21 May '24

21 May '24

From: Devyn Liu <liudingyuan(a)huawei.com> stable inclusion from stable-v5.10.211 commit e94da8aca2e78ef9ecca02eb211869eacd5504e5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2NX Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit de8b6e1c231a95abf95ad097b993d34b31458ec9 ] Return IRQ_NONE from the interrupt handler when no interrupt was detected. Because an empty interrupt will cause a null pointer error: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: complete+0x54/0x100 hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx] __handle_irq_event_percpu+0x64/0x1e0 handle_irq_event+0x7c/0x1cc Signed-off-by: Devyn Liu <liudingyuan(a)huawei.com> Link: https://msgid.link/r/20240123071149.917678-1-liudingyuan@huawei.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- drivers/spi/spi-hisi-sfc-v3xx.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/spi/spi-hisi-sfc-v3xx.c b/drivers/spi/spi-hisi-sfc-v3xx.c index d3a23b1c2a4c..61bf00dfe9c3 100644 --- a/drivers/spi/spi-hisi-sfc-v3xx.c +++ b/drivers/spi/spi-hisi-sfc-v3xx.c @@ -377,6 +377,11 @@ static const struct spi_controller_mem_ops hisi_sfc_v3xx_mem_ops = { static irqreturn_t hisi_sfc_v3xx_isr(int irq, void *data) { struct hisi_sfc_v3xx_host *host = data; + u32 reg; + + reg = readl(host->regbase + HISI_SFC_V3XX_INT_STAT); + if (!reg) + return IRQ_NONE; hisi_sfc_v3xx_disable_int(host); -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected
by Guo Mengqi 21 May '24

21 May '24

From: Devyn Liu <liudingyuan(a)huawei.com> stable inclusion from stable-v5.10.211 commit e94da8aca2e78ef9ecca02eb211869eacd5504e5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2NX Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit de8b6e1c231a95abf95ad097b993d34b31458ec9 ] Return IRQ_NONE from the interrupt handler when no interrupt was detected. Because an empty interrupt will cause a null pointer error: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: complete+0x54/0x100 hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx] __handle_irq_event_percpu+0x64/0x1e0 handle_irq_event+0x7c/0x1cc Signed-off-by: Devyn Liu <liudingyuan(a)huawei.com> Link: https://msgid.link/r/20240123071149.917678-1-liudingyuan@huawei.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- drivers/spi/spi-hisi-sfc-v3xx.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/spi/spi-hisi-sfc-v3xx.c b/drivers/spi/spi-hisi-sfc-v3xx.c index d3a23b1c2a4c..61bf00dfe9c3 100644 --- a/drivers/spi/spi-hisi-sfc-v3xx.c +++ b/drivers/spi/spi-hisi-sfc-v3xx.c @@ -377,6 +377,11 @@ static const struct spi_controller_mem_ops hisi_sfc_v3xx_mem_ops = { static irqreturn_t hisi_sfc_v3xx_isr(int irq, void *data) { struct hisi_sfc_v3xx_host *host = data; + u32 reg; + + reg = readl(host->regbase + HISI_SFC_V3XX_INT_STAT); + if (!reg) + return IRQ_NONE; hisi_sfc_v3xx_disable_int(host); -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS] spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected
by Guo Mengqi 21 May '24

21 May '24

From: Devyn Liu <liudingyuan(a)huawei.com> stable inclusion from stable-v5.10.211 commit e94da8aca2e78ef9ecca02eb211869eacd5504e5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2NX Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit de8b6e1c231a95abf95ad097b993d34b31458ec9 ] Return IRQ_NONE from the interrupt handler when no interrupt was detected. Because an empty interrupt will cause a null pointer error: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: complete+0x54/0x100 hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx] __handle_irq_event_percpu+0x64/0x1e0 handle_irq_event+0x7c/0x1cc Signed-off-by: Devyn Liu <liudingyuan(a)huawei.com> Link: https://msgid.link/r/20240123071149.917678-1-liudingyuan@huawei.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- drivers/spi/spi-hisi-sfc-v3xx.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/spi/spi-hisi-sfc-v3xx.c b/drivers/spi/spi-hisi-sfc-v3xx.c index d3a23b1c2a4c..61bf00dfe9c3 100644 --- a/drivers/spi/spi-hisi-sfc-v3xx.c +++ b/drivers/spi/spi-hisi-sfc-v3xx.c @@ -377,6 +377,11 @@ static const struct spi_controller_mem_ops hisi_sfc_v3xx_mem_ops = { static irqreturn_t hisi_sfc_v3xx_isr(int irq, void *data) { struct hisi_sfc_v3xx_host *host = data; + u32 reg; + + reg = readl(host->regbase + HISI_SFC_V3XX_INT_STAT); + if (!reg) + return IRQ_NONE; hisi_sfc_v3xx_disable_int(host); -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP2] net: ip_tunnel: prevent perpetual headroom growth
by Guo Mengqi 21 May '24

21 May '24

From: Florian Westphal <fw(a)strlen.de> stable inclusion from stable-v5.10.212 commit 2e95350fe9db9d53c701075060ac8ac883b68aee category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E47C Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 5ae1e9922bbdbaeb9cfbe91085ab75927488ac0f ] syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ... The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb)); ... but skb_network_offset() returns a negative offset and __skb_pull() arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value. The negative value is returned because skb->head and skb->data distance is more than 64k and skb->network_header (u16) has wrapped around. The bug is in the ip_tunnel infrastructure, which can cause dev->needed_headroom to increment ad infinitum. The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device. This results in the following pattern: 1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0. 2). ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future output device, rt.dev->needed_headroom (ipip0). 3). ip output / start_xmit moves skb on to ipip0. which runs the same code path again (xmit recursion). 4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet. tunl0->needed_headroom is then incremented based on the (already bumped) gre0 device headroom. This repeats for every future packet: gre0->needed_headroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 needed_headroom was increased. For each subsequent packet, gre/ipip0->needed_headroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k. Once that happens, skb->network_header (u16) wraps around when pskb_expand_head tries to make sure that skb_network_offset() is unchanged after the headroom expansion/reallocation. After this skb_network_offset(skb) returns a different (and negative) result post headroom expansion. The next trip to neigh layer (or anything else that would __skb_pull the network header) makes skb->data point to a memory location outside skb->head area. v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely. Reported-and-tested-by: syzbot+bfde3bef047a81b8fde6(a)syzkaller.appspotmail.com Closes: https://groups.google.com/g/syzkaller-bugs/c/fL9G6GtWskY/m/VKk_PR5FBAAJ Fixes: 243aad830e8a ("ip_gre: include route header_len in max_headroom calculation") Signed-off-by: Florian Westphal <fw(a)strlen.de> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://lore.kernel.org/r/20240220135606.4939-1-fw@strlen.de Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- net/ipv4/ip_tunnel.c | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c index 1d11e1832059..0953d805cbbe 100644 --- a/net/ipv4/ip_tunnel.c +++ b/net/ipv4/ip_tunnel.c @@ -553,6 +553,20 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb, return 0; } +static void ip_tunnel_adj_headroom(struct net_device *dev, unsigned int headroom) +{ + /* we must cap headroom to some upperlimit, else pskb_expand_head + * will overflow header offsets in skb_headers_offset_update(). + */ + static const unsigned int max_allowed = 512; + + if (headroom > max_allowed) + headroom = max_allowed; + + if (headroom > READ_ONCE(dev->needed_headroom)) + WRITE_ONCE(dev->needed_headroom, headroom); +} + void ip_md_tunnel_xmit(struct sk_buff *skb, struct net_device *dev, u8 proto, int tunnel_hlen) { @@ -626,13 +640,13 @@ void ip_md_tunnel_xmit(struct sk_buff *skb, struct net_device *dev, } headroom += LL_RESERVED_SPACE(rt->dst.dev) + rt->dst.header_len; - if (headroom > READ_ONCE(dev->needed_headroom)) - WRITE_ONCE(dev->needed_headroom, headroom); - - if (skb_cow_head(skb, READ_ONCE(dev->needed_headroom))) { + if (skb_cow_head(skb, headroom)) { ip_rt_put(rt); goto tx_dropped; } + + ip_tunnel_adj_headroom(dev, headroom); + iptunnel_xmit(NULL, rt, skb, fl4.saddr, fl4.daddr, proto, tos, ttl, df, !net_eq(tunnel->net, dev_net(dev))); return; @@ -810,16 +824,16 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev, max_headroom = LL_RESERVED_SPACE(rt->dst.dev) + sizeof(struct iphdr) + rt->dst.header_len + ip_encap_hlen(&tunnel->encap); - if (max_headroom > READ_ONCE(dev->needed_headroom)) - WRITE_ONCE(dev->needed_headroom, max_headroom); - if (skb_cow_head(skb, READ_ONCE(dev->needed_headroom))) { + if (skb_cow_head(skb, max_headroom)) { ip_rt_put(rt); dev->stats.tx_dropped++; kfree_skb(skb); return; } + ip_tunnel_adj_headroom(dev, max_headroom); + iptunnel_xmit(NULL, rt, skb, fl4.saddr, fl4.daddr, protocol, tos, ttl, df, !net_eq(tunnel->net, dev_net(dev))); return; -- 2.17.1

2 1

[PATCH v2 OLK-5.10 00/11] sync hulk-5.10 patches
by Yu Kuai 21 May '24

21 May '24

Changes in v2: - fix head in commit message Three features related: - add a switch to enable hungtask check for io, patch 1-2 - add a config to control hierarchical throttle, patch 3-4 - support enable/disable blk-mq debugfs dynamically, patch 5-11 Christoph Hellwig (2): block: serialize all debugfs operations using q->debugfs_mutex block: remove per-disk debugfs files in blk_unregister_queue Yu Kuai (9): block: add a switch to enable hungtask check for io block: disable BLK_IO_HUNG_TASK_CHECK by default blk-throttle: add a config to control hierarchical throttle in cgroup v1 blk-throttle: fix missing prefix "CONFIG_" block: protect blk_mq_debugfs_register/unregister_hctx() with 'debugfs_mutex' block: shutdown blktrace in blk_release_queue() block: support enable/disable blk-mq debugfs dynamically block: fix kabi broken in struct request_queue block: support to disable debugfs by default arch/arm64/configs/openeuler_defconfig | 2 + arch/x86/configs/openeuler_defconfig | 2 + block/Kconfig | 31 +++++++++ block/bio.c | 2 +- block/blk-core.c | 13 +++- block/blk-exec.c | 2 +- block/blk-mq-debugfs.c | 87 ++++++++++++++++++++++---- block/blk-mq-debugfs.h | 5 -- block/blk-mq-sched.c | 11 ++++ block/blk-mq.c | 12 ++++ block/blk-rq-qos.c | 2 - block/blk-rq-qos.h | 7 ++- block/blk-sysfs.c | 82 ++++++++++++++++++++---- block/blk-throttle.c | 17 ++++- block/blk.h | 1 + include/linux/blkdev.h | 8 ++- kernel/trace/blktrace.c | 3 - 17 files changed, 245 insertions(+), 42 deletions(-) -- 2.39.2

2 12

[PATCH OLK-6.6 0/1] Fix allmodconfig build error
by Shuai Wu 21 May '24

21 May '24

Fix allmodconfig build error in hiroce3 driver. Shuai Wu (1): net/ethernet/huawei/hiroce3: Fix allmodconfig build error .../hw/hiroce3/bond/roce_bond_common.c | 38 +- .../hw/hiroce3/cq/roce_cq_destroy.c | 15 +- .../hw/hiroce3/host/hmm/hmm_comp_mtt.c | 1 + .../hw/hiroce3/host/hmm/hmm_comp_mw_mr.c | 1 + .../hw/hiroce3/host/hmm/hmm_comp_res.c | 1 + .../infiniband/hw/hiroce3/host/hmm/hmm_mr.c | 98 +---- .../infiniband/hw/hiroce3/host/hmm/hmm_umem.c | 4 +- .../infiniband/hw/hiroce3/host/hmm/hmm_umem.h | 2 +- .../include/rdma/rdma_context_format.h | 4 +- .../include/rdma/rdma_ext_ctx_format.h | 5 +- .../hw/hiroce3/include/rdma/roce_ccf_format.h | 4 +- .../hw/hiroce3/include/rdma/roce_verbs_attr.h | 4 +- .../include/rdma/roce_verbs_attr_qpc_chip.h | 4 +- .../hiroce3/include/rdma/roce_verbs_cq_attr.h | 4 +- .../include/rdma/roce_verbs_ext_attr.h | 4 +- .../include/rdma/roce_verbs_gid_attr.h | 4 +- .../hiroce3/include/rdma/roce_verbs_mr_attr.h | 4 +- .../hw/hiroce3/include/rdma/roce_verbs_pub.h | 4 +- .../include/rdma/roce_verbs_srq_attr.h | 4 +- drivers/infiniband/hw/hiroce3/mr/roce_mr.c | 37 -- drivers/infiniband/hw/hiroce3/roce.h | 1 - drivers/infiniband/hw/hiroce3/roce_main.c | 7 +- .../ethernet/huawei/hinic3/bond/hinic3_bond.c | 1 - .../ethernet/huawei/hinic3/bond/hinic3_bond.h | 4 +- .../ethernet/huawei/hinic3/cqm/cqm_bat_cla.c | 198 +++------ .../huawei/hinic3/cqm/cqm_bitmap_table.c | 10 +- .../huawei/hinic3/cqm/cqm_bloomfilter.c | 69 +--- .../net/ethernet/huawei/hinic3/cqm/cqm_cmd.c | 139 ++----- .../net/ethernet/huawei/hinic3/cqm/cqm_cmd.h | 2 - .../net/ethernet/huawei/hinic3/cqm/cqm_db.c | 192 +++------ .../ethernet/huawei/hinic3/cqm/cqm_define.h | 4 - .../net/ethernet/huawei/hinic3/cqm/cqm_main.c | 178 +++------ .../ethernet/huawei/hinic3/cqm/cqm_object.c | 378 +++++------------- .../huawei/hinic3/cqm/cqm_object_intern.c | 194 +++------ .../ethernet/huawei/hinic3/hw/hinic3_hw_cfg.c | 2 +- .../ethernet/huawei/hinic3/hw/hinic3_hwif.c | 38 -- .../huawei/hinic3/hw/hinic3_multi_host_mgmt.c | 56 ++- .../hinic3/include/bond/bond_common_defs.h | 4 +- .../huawei/hinic3/include/hinic3_common.h | 2 - .../huawei/hinic3/include/hinic3_cqm.h | 11 - .../huawei/hinic3/include/hinic3_cqm_define.h | 4 - .../include/mpu/mpu_outband_ncsi_cmd_defs.h | 4 +- 42 files changed, 474 insertions(+), 1266 deletions(-) -- 2.33.0

2 3

[PATCH openEuler-22.03-LTS-SP1] cpumap: Zero-initialise xdp_rxq_info struct before running XDP program
by Pu Lehui 21 May '24

21 May '24

From: Toke Høiland-Jørgensen <toke(a)redhat.com> stable inclusion from stable-v5.10.213 commit 5f4e51abfbe6eb444fa91906a5cd083044278297 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q92U CVE: CVE-2024-27431 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2487007aa3b9fafbd2cb14068f49791ce1d7ede5 ] When running an XDP program that is attached to a cpumap entry, we don't initialise the xdp_rxq_info data structure being used in the xdp_buff that backs the XDP program invocation. Tobias noticed that this leads to random values being returned as the xdp_md->rx_queue_index value for XDP programs running in a cpumap. This means we're basically returning the contents of the uninitialised memory, which is bad. Fix this by zero-initialising the rxq data structure before running the XDP program. Fixes: 9216477449f3 ("bpf: cpumap: Add the possibility to attach an eBPF program to cpumap") Reported-by: Tobias Böhm <tobias(a)aibor.de> Signed-off-by: Toke Høiland-Jørgensen <toke(a)redhat.com> Link: https://lore.kernel.org/r/20240305213132.11955-1-toke@redhat.com Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/cpumap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c index 2097ed9bd583..6e4ce0be8be8 100644 --- a/kernel/bpf/cpumap.c +++ b/kernel/bpf/cpumap.c @@ -237,7 +237,7 @@ static int cpu_map_bpf_prog_run_xdp(struct bpf_cpu_map_entry *rcpu, void **frames, int n, struct xdp_cpumap_stats *stats) { - struct xdp_rxq_info rxq; + struct xdp_rxq_info rxq = {}; struct xdp_buff xdp; int i, nframes = 0; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP2] cpumap: Zero-initialise xdp_rxq_info struct before running XDP program
by Pu Lehui 21 May '24

21 May '24

From: Toke Høiland-Jørgensen <toke(a)redhat.com> stable inclusion from stable-v5.10.213 commit 5f4e51abfbe6eb444fa91906a5cd083044278297 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q92U CVE: CVE-2024-27431 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2487007aa3b9fafbd2cb14068f49791ce1d7ede5 ] When running an XDP program that is attached to a cpumap entry, we don't initialise the xdp_rxq_info data structure being used in the xdp_buff that backs the XDP program invocation. Tobias noticed that this leads to random values being returned as the xdp_md->rx_queue_index value for XDP programs running in a cpumap. This means we're basically returning the contents of the uninitialised memory, which is bad. Fix this by zero-initialising the rxq data structure before running the XDP program. Fixes: 9216477449f3 ("bpf: cpumap: Add the possibility to attach an eBPF program to cpumap") Reported-by: Tobias Böhm <tobias(a)aibor.de> Signed-off-by: Toke Høiland-Jørgensen <toke(a)redhat.com> Link: https://lore.kernel.org/r/20240305213132.11955-1-toke@redhat.com Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/cpumap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c index 2097ed9bd583..6e4ce0be8be8 100644 --- a/kernel/bpf/cpumap.c +++ b/kernel/bpf/cpumap.c @@ -237,7 +237,7 @@ static int cpu_map_bpf_prog_run_xdp(struct bpf_cpu_map_entry *rcpu, void **frames, int n, struct xdp_cpumap_stats *stats) { - struct xdp_rxq_info rxq; + struct xdp_rxq_info rxq = {}; struct xdp_buff xdp; int i, nframes = 0; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS] cpumap: Zero-initialise xdp_rxq_info struct before running XDP program
by Pu Lehui 21 May '24

21 May '24

From: Toke Høiland-Jørgensen <toke(a)redhat.com> stable inclusion from stable-v5.10.213 commit 5f4e51abfbe6eb444fa91906a5cd083044278297 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q92U CVE: CVE-2024-27431 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2487007aa3b9fafbd2cb14068f49791ce1d7ede5 ] When running an XDP program that is attached to a cpumap entry, we don't initialise the xdp_rxq_info data structure being used in the xdp_buff that backs the XDP program invocation. Tobias noticed that this leads to random values being returned as the xdp_md->rx_queue_index value for XDP programs running in a cpumap. This means we're basically returning the contents of the uninitialised memory, which is bad. Fix this by zero-initialising the rxq data structure before running the XDP program. Fixes: 9216477449f3 ("bpf: cpumap: Add the possibility to attach an eBPF program to cpumap") Reported-by: Tobias Böhm <tobias(a)aibor.de> Signed-off-by: Toke Høiland-Jørgensen <toke(a)redhat.com> Link: https://lore.kernel.org/r/20240305213132.11955-1-toke@redhat.com Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/cpumap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c index 2097ed9bd583..6e4ce0be8be8 100644 --- a/kernel/bpf/cpumap.c +++ b/kernel/bpf/cpumap.c @@ -237,7 +237,7 @@ static int cpu_map_bpf_prog_run_xdp(struct bpf_cpu_map_entry *rcpu, void **frames, int n, struct xdp_cpumap_stats *stats) { - struct xdp_rxq_info rxq; + struct xdp_rxq_info rxq = {}; struct xdp_buff xdp; int i, nframes = 0; -- 2.34.1

2 1

[PATCH OLK-5.10] cpumap: Zero-initialise xdp_rxq_info struct before running XDP program
by Pu Lehui 21 May '24

21 May '24

From: Toke Høiland-Jørgensen <toke(a)redhat.com> stable inclusion from stable-v5.10.213 commit 5f4e51abfbe6eb444fa91906a5cd083044278297 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q92U CVE: CVE-2024-27431 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2487007aa3b9fafbd2cb14068f49791ce1d7ede5 ] When running an XDP program that is attached to a cpumap entry, we don't initialise the xdp_rxq_info data structure being used in the xdp_buff that backs the XDP program invocation. Tobias noticed that this leads to random values being returned as the xdp_md->rx_queue_index value for XDP programs running in a cpumap. This means we're basically returning the contents of the uninitialised memory, which is bad. Fix this by zero-initialising the rxq data structure before running the XDP program. Fixes: 9216477449f3 ("bpf: cpumap: Add the possibility to attach an eBPF program to cpumap") Reported-by: Tobias Böhm <tobias(a)aibor.de> Signed-off-by: Toke Høiland-Jørgensen <toke(a)redhat.com> Link: https://lore.kernel.org/r/20240305213132.11955-1-toke@redhat.com Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/cpumap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c index 2097ed9bd583..6e4ce0be8be8 100644 --- a/kernel/bpf/cpumap.c +++ b/kernel/bpf/cpumap.c @@ -237,7 +237,7 @@ static int cpu_map_bpf_prog_run_xdp(struct bpf_cpu_map_entry *rcpu, void **frames, int n, struct xdp_cpumap_stats *stats) { - struct xdp_rxq_info rxq; + struct xdp_rxq_info rxq = {}; struct xdp_buff xdp; int i, nframes = 0; -- 2.34.1

2 1