- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 0/2] Fix xfs file creation issue
by Zizhi Wo 04 Jul '24

04 Jul '24

Revert the previous fix patch and adapt to the latest repair solution. Zizhi Wo (2): Revert "xfs: Fix file creation failure" xfs: Avoid races with cnt_btree lastrec updates fs/xfs/libxfs/xfs_alloc.c | 125 +++++++++++++++++++++++++++++--- fs/xfs/libxfs/xfs_alloc_btree.c | 72 ------------------ fs/xfs/libxfs/xfs_btree.c | 51 ------------- fs/xfs/libxfs/xfs_btree.h | 19 +---- 4 files changed, 115 insertions(+), 152 deletions(-) -- 2.39.2

2 3

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2024-26816
by liwei 04 Jul '24

04 Jul '24

CVE-2024-26816 Guixiong Wei (1): x86/boot: Ignore relocations in .notes sections in walk_relocs() too Kees Cook (1): x86, relocs: Ignore relocations in .notes section arch/x86/tools/relocs.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) -- 2.25.1

2 3

[PATCH OLK-5.10 0/2] CVE-2024-26816
by liwei 04 Jul '24

04 Jul '24

CVE-2024-26816 Guixiong Wei (1): x86/boot: Ignore relocations in .notes sections in walk_relocs() too Kees Cook (1): x86, relocs: Ignore relocations in .notes section arch/x86/tools/relocs.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS 0/2] CVE-2024-26816
by liwei 04 Jul '24

04 Jul '24

CVE-2024-26816 Guixiong Wei (1): x86/boot: Ignore relocations in .notes sections in walk_relocs() too Kees Cook (1): x86, relocs: Ignore relocations in .notes section arch/x86/tools/relocs.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS 0/3] CVE-2024-23848
by Yongqiang Liu 04 Jul '24

04 Jul '24

Hans Verkuil (3): media: cec: cec-adap: always cancel work in cec_transmit_msg_fh media: cec: cec-api: add locking in cec_release() media: cec: core: avoid recursive cec_claim_log_addrs drivers/media/cec/cec-adap.c | 9 ++++++--- drivers/media/cec/cec-api.c | 5 ++++- include/media/cec.h | 1 + 3 files changed, 11 insertions(+), 4 deletions(-) -- 2.34.1

2 4

[PATCH v2 OLK-5.10] x86, relocs: Ignore relocations in .notes section
by liwei 04 Jul '24

04 Jul '24

From: Kees Cook <keescook(a)chromium.org> mainline inclusion from mainline-v6.9-rc1 commit aaa8736370db1a78f0e8434344a484f9fd20be3b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNFG CVE: CVE-2024-26816 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. Reported-by: Guixiong Wei <guixiongwei(a)gmail.com> Closes: https://lore.kernel.org/all/20240218073501.54555-1-guixiongwei@gmail.com/ Fixes: 5ead97c84fa7 ("xen: Core Xen implementation") Fixes: da1a679cde9b ("Add /sys/kernel/notes") Reviewed-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: liwei <liwei728(a)huawei.com> --- arch/x86/tools/relocs.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index 1c3a1962cade..0043fd374a62 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -596,6 +596,14 @@ static void print_absolute_relocs(void) if (!(sec_applies->shdr.sh_flags & SHF_ALLOC)) { continue; } + /* + * Do not perform relocations in .notes section; any + * values there are meant for pre-boot consumption (e.g. + * startup_xen). + */ + if (sec_applies->shdr.sh_type == SHT_NOTE) { + continue; + } sh_symtab = sec_symtab->symtab; sym_strtab = sec_symtab->link->strtab; for (j = 0; j < sec->shdr.sh_size/sizeof(Elf_Rel); j++) { -- 2.25.1

2 1

[PATCH OLK-6.6] net: openvswitch: fix overwriting ct original tuple for ICMPv6
by Jinjie Ruan 04 Jul '24

04 Jul '24

From: Ilya Maximets <i.maximets(a)ovn.org> stable inclusion from stable-v5.10.219 commit 5ab6aecbede080b44b8e34720ab72050bf1e6982 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SH5 CVE: CVE-2024-38558 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ] OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Reported-by: Antonin Bas <antonin.bas(a)broadcom.com> Closes: https://github.com/openvswitch/ovs-issues/issues/327 Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org> Acked-by: Aaron Conole <aconole(a)redhat.com> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Link: https://lore.kernel.org/r/20240509094228.1035477-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- net/openvswitch/flow.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c index 33b21a0c0548..8a848ce72e29 100644 --- a/net/openvswitch/flow.c +++ b/net/openvswitch/flow.c @@ -561,7 +561,6 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, */ key->tp.src = htons(icmp->icmp6_type); key->tp.dst = htons(icmp->icmp6_code); - memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); if (icmp->icmp6_code == 0 && (icmp->icmp6_type == NDISC_NEIGHBOUR_SOLICITATION || @@ -570,6 +569,8 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, struct nd_msg *nd; int offset; + memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); + /* In order to process neighbor discovery options, we need the * entire packet. */ -- 2.34.1

2 1

[PATCH OLK-5.10] net: openvswitch: fix overwriting ct original tuple for ICMPv6
by Jinjie Ruan 04 Jul '24

04 Jul '24

From: Ilya Maximets <i.maximets(a)ovn.org> stable inclusion from stable-v5.10.219 commit 5ab6aecbede080b44b8e34720ab72050bf1e6982 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SH5 CVE: CVE-2024-38558 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ] OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Reported-by: Antonin Bas <antonin.bas(a)broadcom.com> Closes: https://github.com/openvswitch/ovs-issues/issues/327 Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org> Acked-by: Aaron Conole <aconole(a)redhat.com> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Link: https://lore.kernel.org/r/20240509094228.1035477-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- net/openvswitch/flow.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c index c9ba61413c98..9bad601c7fe8 100644 --- a/net/openvswitch/flow.c +++ b/net/openvswitch/flow.c @@ -412,7 +412,6 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, */ key->tp.src = htons(icmp->icmp6_type); key->tp.dst = htons(icmp->icmp6_code); - memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); if (icmp->icmp6_code == 0 && (icmp->icmp6_type == NDISC_NEIGHBOUR_SOLICITATION || @@ -421,6 +420,8 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, struct nd_msg *nd; int offset; + memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); + /* In order to process neighbor discovery options, we need the * entire packet. */ -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] wifi: ar5523: enable proper endpoint verification
by Chen Zhongjin 04 Jul '24

04 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> stable inclusion from stable-v4.19.316 commit 79ddf5f2020fd593d50f1363bb5131283d74f78f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SCR CVE: CVE-2024-38565 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e120b6388d7d88635d67dcae6483f39c37111850 ] Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it. Fix the issue by checking for the existence of all proper endpoints with their according types intact. Sadly, this patch has not been tested on real hardware. [1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Reported-and-tested-by: syzbot+1bc2c2afd44f820a669f(a)syzkaller.appspotmail.com Fixes: b7d572e1871d ("ar5523: Add new driver") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://msgid.link/20240408121425.29392-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- drivers/net/wireless/ath/ar5523/ar5523.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c b/drivers/net/wireless/ath/ar5523/ar5523.c index da2d179430ca..91b524ca3243 100644 --- a/drivers/net/wireless/ath/ar5523/ar5523.c +++ b/drivers/net/wireless/ath/ar5523/ar5523.c @@ -1580,6 +1580,20 @@ static int ar5523_probe(struct usb_interface *intf, struct ar5523 *ar; int error = -ENOMEM; + static const u8 bulk_ep_addr[] = { + AR5523_CMD_TX_PIPE | USB_DIR_OUT, + AR5523_DATA_TX_PIPE | USB_DIR_OUT, + AR5523_CMD_RX_PIPE | USB_DIR_IN, + AR5523_DATA_RX_PIPE | USB_DIR_IN, + 0}; + + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr)) { + dev_err(&dev->dev, + "Could not find all expected endpoints\n"); + error = -ENODEV; + goto out; + } + /* * Load firmware if the device requires it. This will return * -ENXIO on success and we'll get called back afer the usb -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] net: openvswitch: fix overwriting ct original tuple for ICMPv6
by Jinjie Ruan 04 Jul '24

04 Jul '24

From: Ilya Maximets <i.maximets(a)ovn.org> stable inclusion from stable-v5.10.219 commit 5ab6aecbede080b44b8e34720ab72050bf1e6982 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SH5 CVE: CVE-2024-38558 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ] OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Reported-by: Antonin Bas <antonin.bas(a)broadcom.com> Closes: https://github.com/openvswitch/ovs-issues/issues/327 Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org> Acked-by: Aaron Conole <aconole(a)redhat.com> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Link: https://lore.kernel.org/r/20240509094228.1035477-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- net/openvswitch/flow.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c index 56b8e7167790..857b1ffe3d85 100644 --- a/net/openvswitch/flow.c +++ b/net/openvswitch/flow.c @@ -427,7 +427,6 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, */ key->tp.src = htons(icmp->icmp6_type); key->tp.dst = htons(icmp->icmp6_code); - memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); if (icmp->icmp6_code == 0 && (icmp->icmp6_type == NDISC_NEIGHBOUR_SOLICITATION || @@ -436,6 +435,8 @@ static int parse_icmpv6(struct sk_buff *skb, struct sw_flow_key *key, struct nd_msg *nd; int offset; + memset(&key->ipv6.nd, 0, sizeof(key->ipv6.nd)); + /* In order to process neighbor discovery options, we need the * entire packet. */ -- 2.34.1

2 1

[PATCH v2 OLK-5.10] arm64: arm_pmuv3: Correctly extract and check the PMUVer
by Junhao He 04 Jul '24

04 Jul '24

mainline inclusion from mainline-v6.10-rc1 commit b782e8d07baac95a5ce3f8773cc61f4ed7d0ccbc category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9J01A CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------------------------------------------- Currently we're using "sbfx" to extract the PMUVer from ID_AA64DFR0_EL1 and skip the init/reset if no PMU present when the extracted PMUVer is negative or is zero. However for PMUv3p8 the PMUVer will be 0b1000 and PMUVer extracted by "sbfx" will always be negative and we'll skip the init/reset in __init_el2_debug/reset_pmuserenr_el0 unexpectedly. So this patch use "ubfx" instead of "sbfx" to extract the PMUVer. If the PMUVer is implementation defined (0b1111) or not implemented(0b0000) then skip the reset/init. Previously we'll also skip the init/reset if the PMUVer is higher than the version we known (currently PMUv3p9), with this patch we'll only skip if the PMU is not implemented or implementation defined. This keeps consistence with how we probe the PMU in the driver with pmuv3_implemented(). Signed-off-by: Yicong Yang <yangyicong(a)hisilicon.com> Link: https://lore.kernel.org/r/20240411123030.7201-1-yangyicong@huawei.com Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Junhao He <hejunhao3(a)huawei.com> --- arch/arm64/include/asm/assembler.h | 7 ++++--- arch/arm64/include/asm/sysreg.h | 1 + arch/arm64/kernel/head.S | 9 +++++---- 3 files changed, 10 insertions(+), 7 deletions(-) diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h index 5e6bacda05d8..63db8e5ec9f8 100644 --- a/arch/arm64/include/asm/assembler.h +++ b/arch/arm64/include/asm/assembler.h @@ -466,9 +466,10 @@ USER(\label, ic ivau, \tmp2) // invalidate I line PoU */ .macro reset_pmuserenr_el0, tmpreg mrs \tmpreg, id_aa64dfr0_el1 - sbfx \tmpreg, \tmpreg, #ID_AA64DFR0_PMUVER_SHIFT, #4 - cmp \tmpreg, #1 // Skip if no PMU present - b.lt 9000f + ubfx \tmpreg, \tmpreg, #ID_AA64DFR0_PMUVER_SHIFT, #4 + cmp \tmpreg, #ID_AA64DFR0_PMUVER_NI + ccmp \tmpreg, #ID_AA64DFR0_PMUVER_IMP_DEF, #4, ne + b.eq 9000f msr pmuserenr_el0, xzr // Disable PMU access from EL0 9000: .endm diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h index 8bcc9ac9963e..9705f7abd428 100644 --- a/arch/arm64/include/asm/sysreg.h +++ b/arch/arm64/include/asm/sysreg.h @@ -1488,6 +1488,7 @@ #define ID_AA64DFR0_EL1_BRBE_NI 0x0 #define ID_AA64DFR0_EL1_BRBE_IMP 0x1 #define ID_AA64DFR0_EL1_BRBE_BRBE_V1P1 0x2 +#define ID_AA64DFR0_PMUVER_NI 0x0 #define ID_AA64DFR0_PMUVER_8_0 0x1 #define ID_AA64DFR0_PMUVER_8_1 0x4 #define ID_AA64DFR0_PMUVER_8_4 0x5 diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 91890de6cefa..b44213388bab 100644 --- a/arch/arm64/kernel/head.S +++ b/arch/arm64/kernel/head.S @@ -623,13 +623,14 @@ set_hcr: /* EL2 debug */ mrs x1, id_aa64dfr0_el1 - sbfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4 - cmp x0, #1 - b.lt 4f // Skip if no PMU present + ubfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4 + cmp x0, #ID_AA64DFR0_PMUVER_NI + ccmp x0, #ID_AA64DFR0_PMUVER_IMP_DEF, #4, ne + b.eq 4f // Skip if no PMU present mrs x0, pmcr_el0 // Disable debug access traps ubfx x0, x0, #11, #5 // to EL2 and allow access to 4: - csel x3, xzr, x0, lt // all PMU counters from EL1 + csel x3, xzr, x0, eq // all PMU counters from EL1 /* Statistical profiling */ ubfx x0, x1, #ID_AA64DFR0_PMSVER_SHIFT, #4 -- 2.33.0

2 1

[PATCH openEuler-22.03-LTS-SP1] x86, relocs: Ignore relocations in .notes section
by liwei 04 Jul '24

04 Jul '24

From: Kees Cook <keescook(a)chromium.org> mainline inclusion from mainline-v6.9-rc1 commit aaa8736370db1a78f0e8434344a484f9fd20be3b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNFG CVE: CVE-2024-26816 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. Reported-by: Guixiong Wei <guixiongwei(a)gmail.com> Closes: https://lore.kernel.org/all/20240218073501.54555-1-guixiongwei@gmail.com/ Fixes: 5ead97c84fa7 ("xen: Core Xen implementation") Fixes: da1a679cde9b ("Add /sys/kernel/notes") Reviewed-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: liwei <liwei728(a)huawei.com> --- arch/x86/tools/relocs.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index 1c3a1962cade..0043fd374a62 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -596,6 +596,14 @@ static void print_absolute_relocs(void) if (!(sec_applies->shdr.sh_flags & SHF_ALLOC)) { continue; } + /* + * Do not perform relocations in .notes section; any + * values there are meant for pre-boot consumption (e.g. + * startup_xen). + */ + if (sec_applies->shdr.sh_type == SHT_NOTE) { + continue; + } sh_symtab = sec_symtab->symtab; sym_strtab = sec_symtab->link->strtab; for (j = 0; j < sec->shdr.sh_size/sizeof(Elf_Rel); j++) { -- 2.25.1

2 1

[PATCH OLK-5.10] x86, relocs: Ignore relocations in .notes section
by liwei 04 Jul '24

04 Jul '24

From: Kees Cook <keescook(a)chromium.org> mainline inclusion from mainline-v6.9-rc1 commit aaa8736370db1a78f0e8434344a484f9fd20be3b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNFG CVE: CVE-2024-26816 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. Reported-by: Guixiong Wei <guixiongwei(a)gmail.com> Closes: https://lore.kernel.org/all/20240218073501.54555-1-guixiongwei@gmail.com/ Fixes: 5ead97c84fa7 ("xen: Core Xen implementation") Fixes: da1a679cde9b ("Add /sys/kernel/notes") Reviewed-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: liwei <liwei728(a)huawei.com> --- arch/x86/tools/relocs.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index 3a6c8ebc8032..4fe8eab9152f 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -579,6 +579,14 @@ static void print_absolute_relocs(void) if (!(sec_applies->shdr.sh_flags & SHF_ALLOC)) { continue; } + /* + * Do not perform relocations in .notes section; any + * values there are meant for pre-boot consumption (e.g. + * startup_xen). + */ + if (sec_applies->shdr.sh_type == SHT_NOTE) { + continue; + } sh_symtab = sec_symtab->symtab; sym_strtab = sec_symtab->link->strtab; for (j = 0; j < sec->shdr.sh_size/sizeof(Elf_Rel); j++) { -- 2.25.1

2 1

[PATCH OLK-5.10] arm64: arm_pmuv3: Correctly extract and check the PMUVer
by Junhao He 04 Jul '24

04 Jul '24

mainline inclusion from mainline-v6.10-rc1 commit b782e8d07baac95a5ce3f8773cc61f4ed7d0ccbc category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9GLIG CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------------------------------------------- Currently we're using "sbfx" to extract the PMUVer from ID_AA64DFR0_EL1 and skip the init/reset if no PMU present when the extracted PMUVer is negative or is zero. However for PMUv3p8 the PMUVer will be 0b1000 and PMUVer extracted by "sbfx" will always be negative and we'll skip the init/reset in __init_el2_debug/reset_pmuserenr_el0 unexpectedly. So this patch use "ubfx" instead of "sbfx" to extract the PMUVer. If the PMUVer is implementation defined (0b1111) or not implemented(0b0000) then skip the reset/init. Previously we'll also skip the init/reset if the PMUVer is higher than the version we known (currently PMUv3p9), with this patch we'll only skip if the PMU is not implemented or implementation defined. This keeps consistence with how we probe the PMU in the driver with pmuv3_implemented(). Signed-off-by: Yicong Yang <yangyicong(a)hisilicon.com> Link: https://lore.kernel.org/r/20240411123030.7201-1-yangyicong@huawei.com Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Junhao He <hejunhao3(a)huawei.com> --- arch/arm64/include/asm/assembler.h | 7 ++++--- arch/arm64/include/asm/sysreg.h | 1 + arch/arm64/kernel/head.S | 9 +++++---- 3 files changed, 10 insertions(+), 7 deletions(-) diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h index 5e6bacda05d8..63db8e5ec9f8 100644 --- a/arch/arm64/include/asm/assembler.h +++ b/arch/arm64/include/asm/assembler.h @@ -466,9 +466,10 @@ USER(\label, ic ivau, \tmp2) // invalidate I line PoU */ .macro reset_pmuserenr_el0, tmpreg mrs \tmpreg, id_aa64dfr0_el1 - sbfx \tmpreg, \tmpreg, #ID_AA64DFR0_PMUVER_SHIFT, #4 - cmp \tmpreg, #1 // Skip if no PMU present - b.lt 9000f + ubfx \tmpreg, \tmpreg, #ID_AA64DFR0_PMUVER_SHIFT, #4 + cmp \tmpreg, #ID_AA64DFR0_PMUVER_NI + ccmp \tmpreg, #ID_AA64DFR0_PMUVER_IMP_DEF, #4, ne + b.eq 9000f msr pmuserenr_el0, xzr // Disable PMU access from EL0 9000: .endm diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h index 8bcc9ac9963e..9705f7abd428 100644 --- a/arch/arm64/include/asm/sysreg.h +++ b/arch/arm64/include/asm/sysreg.h @@ -1488,6 +1488,7 @@ #define ID_AA64DFR0_EL1_BRBE_NI 0x0 #define ID_AA64DFR0_EL1_BRBE_IMP 0x1 #define ID_AA64DFR0_EL1_BRBE_BRBE_V1P1 0x2 +#define ID_AA64DFR0_PMUVER_NI 0x0 #define ID_AA64DFR0_PMUVER_8_0 0x1 #define ID_AA64DFR0_PMUVER_8_1 0x4 #define ID_AA64DFR0_PMUVER_8_4 0x5 diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 91890de6cefa..b44213388bab 100644 --- a/arch/arm64/kernel/head.S +++ b/arch/arm64/kernel/head.S @@ -623,13 +623,14 @@ set_hcr: /* EL2 debug */ mrs x1, id_aa64dfr0_el1 - sbfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4 - cmp x0, #1 - b.lt 4f // Skip if no PMU present + ubfx x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4 + cmp x0, #ID_AA64DFR0_PMUVER_NI + ccmp x0, #ID_AA64DFR0_PMUVER_IMP_DEF, #4, ne + b.eq 4f // Skip if no PMU present mrs x0, pmcr_el0 // Disable debug access traps ubfx x0, x0, #11, #5 // to EL2 and allow access to 4: - csel x3, xzr, x0, lt // all PMU counters from EL1 + csel x3, xzr, x0, eq // all PMU counters from EL1 /* Statistical profiling */ ubfx x0, x1, #ID_AA64DFR0_PMSVER_SHIFT, #4 -- 2.33.0

2 1

[PATCH openEuler-1.0-LTS] x86, relocs: Ignore relocations in .notes section
by liwei 04 Jul '24

04 Jul '24

From: Kees Cook <keescook(a)chromium.org> stable inclusion from stable-v4.19.311 commit 13edb509abc91c72152a11baaf0e7c060a312e03 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNFG CVE: CVE-2024-26816 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit aaa8736370db1a78f0e8434344a484f9fd20be3b ] When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. Reported-by: Guixiong Wei <guixiongwei(a)gmail.com> Closes: https://lore.kernel.org/all/20240218073501.54555-1-guixiongwei@gmail.com/ Fixes: 5ead97c84fa7 ("xen: Core Xen implementation") Fixes: da1a679cde9b ("Add /sys/kernel/notes") Reviewed-by: Juergen Gross <jgross(a)suse.com> Signed-off-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: liwei <liwei728(a)huawei.com> --- arch/x86/tools/relocs.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index 3a6c8ebc8032..4fe8eab9152f 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -579,6 +579,14 @@ static void print_absolute_relocs(void) if (!(sec_applies->shdr.sh_flags & SHF_ALLOC)) { continue; } + /* + * Do not perform relocations in .notes section; any + * values there are meant for pre-boot consumption (e.g. + * startup_xen). + */ + if (sec_applies->shdr.sh_type == SHT_NOTE) { + continue; + } sh_symtab = sec_symtab->symtab; sym_strtab = sec_symtab->link->strtab; for (j = 0; j < sec->shdr.sh_size/sizeof(Elf_Rel); j++) { -- 2.25.1

2 1

[PATCH OLK-6.6] cxl/pci: Skip to handle RAS errors if CXL.mem device is detached
by Wei Li 04 Jul '24

04 Jul '24

From: Li Ming <ming4.li(a)intel.com> mainline inclusion from mainline-v6.8-rc6 commit eef5c7b28dbecd6b141987a96db6c54e49828102 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9E2M3 CVE: CVE-2024-26762 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?i… -------------------------------- The PCI AER model is an awkward fit for CXL error handling. While the expectation is that a PCI device can escalate to link reset to recover from an AER event, the same reset on CXL amounts to a surprise memory hotplug of massive amounts of memory. At present, the CXL error handler attempts some optimistic error handling to unbind the device from the cxl_mem driver after reaping some RAS register values. This results in a "hopeful" attempt to unplug the memory, but there is no guarantee that will succeed. A subsequent AER notification after the memdev unbind event can no longer assume the registers are mapped. Check for memdev bind before reaping status register values to avoid crashes of the form: BUG: unable to handle page fault for address: ffa00000195e9100 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page [...] RIP: 0010:__cxl_handle_ras+0x30/0x110 [cxl_core] [...] Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x82/0x160 ? kernelmode_fixup_or_oops+0x84/0x110 ? exc_page_fault+0x113/0x170 ? asm_exc_page_fault+0x26/0x30 ? __pfx_dpc_reset_link+0x10/0x10 ? __cxl_handle_ras+0x30/0x110 [cxl_core] ? find_cxl_port+0x59/0x80 [cxl_core] cxl_handle_rp_ras+0xbc/0xd0 [cxl_core] cxl_error_detected+0x6c/0xf0 [cxl_core] report_error_detected+0xc7/0x1c0 pci_walk_bus+0x73/0x90 pcie_do_recovery+0x23f/0x330 Longer term, the unbind and PCI_ERS_RESULT_DISCONNECT behavior might need to be replaced with a new PCI_ERS_RESULT_PANIC. Fixes: 6ac07883dbb5 ("cxl/pci: Add RCH downstream port error logging") Cc: stable(a)vger.kernel.org Suggested-by: Dan Williams <dan.j.williams(a)intel.com> Signed-off-by: Li Ming <ming4.li(a)intel.com> Link: https://lore.kernel.org/r/20240129131856.2458980-1-ming4.li@intel.com Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> Signed-off-by: Wei Li <liwei391(a)huawei.com> --- drivers/cxl/core/pci.c | 43 ++++++++++++++++++++++++++++++------------ 1 file changed, 31 insertions(+), 12 deletions(-) diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c index 011197fa61036..e78c8e6a5c9a7 100644 --- a/drivers/cxl/core/pci.c +++ b/drivers/cxl/core/pci.c @@ -904,11 +904,21 @@ static void cxl_handle_rdport_errors(struct cxl_dev_state *cxlds) { } void cxl_cor_error_detected(struct pci_dev *pdev) { struct cxl_dev_state *cxlds = pci_get_drvdata(pdev); + struct device *dev = &cxlds->cxlmd->dev; + + scoped_guard(device, dev) { + if (!dev->driver) { + dev_warn(&pdev->dev, + "%s: memdev disabled, abort error handling\n", + dev_name(dev)); + return; + } - if (cxlds->rcd) - cxl_handle_rdport_errors(cxlds); + if (cxlds->rcd) + cxl_handle_rdport_errors(cxlds); - cxl_handle_endpoint_cor_ras(cxlds); + cxl_handle_endpoint_cor_ras(cxlds); + } } EXPORT_SYMBOL_NS_GPL(cxl_cor_error_detected, CXL); @@ -920,16 +930,25 @@ pci_ers_result_t cxl_error_detected(struct pci_dev *pdev, struct device *dev = &cxlmd->dev; bool ue; - if (cxlds->rcd) - cxl_handle_rdport_errors(cxlds); + scoped_guard(device, dev) { + if (!dev->driver) { + dev_warn(&pdev->dev, + "%s: memdev disabled, abort error handling\n", + dev_name(dev)); + return PCI_ERS_RESULT_DISCONNECT; + } + + if (cxlds->rcd) + cxl_handle_rdport_errors(cxlds); + /* + * A frozen channel indicates an impending reset which is fatal to + * CXL.mem operation, and will likely crash the system. On the off + * chance the situation is recoverable dump the status of the RAS + * capability registers and bounce the active state of the memdev. + */ + ue = cxl_handle_endpoint_ras(cxlds); + } - /* - * A frozen channel indicates an impending reset which is fatal to - * CXL.mem operation, and will likely crash the system. On the off - * chance the situation is recoverable dump the status of the RAS - * capability registers and bounce the active state of the memdev. - */ - ue = cxl_handle_endpoint_ras(cxlds); switch (state) { case pci_channel_io_normal: -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2024-39469
by Yu Liao 04 Jul '24

04 Jul '24

CVE-2024-39469 Matthew Wilcox (Oracle) (1): nilfs2: return the mapped address from nilfs_get_page() Ryusuke Konishi (1): nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors fs/nilfs2/dir.c | 59 +++++++++++++++++++++++-------------------------- 1 file changed, 28 insertions(+), 31 deletions(-) -- 2.33.0

2 3

[PATCH v2 OLK-6.6] Revert "ACPI: processor: Add support for processors described as container packages"
by liwei 04 Jul '24

04 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAAJ94 ---------------------------- 'processor_container_handler' identifies ACPI0010 does not match the Processor information reported by DSDT. This reverts commit 2f257a8ec840ccc5fcefab424f468552da7b15ff. Fixes: 2f257a8ec840 ("ACPI: processor: Add support for processors described as container packages") Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/acpi/acpi_processor.c | 22 ---------------------- 1 file changed, 22 deletions(-) diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c index 0ff69af46a50..d46e1fe25d58 100644 --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -698,31 +698,9 @@ static struct acpi_scan_handler processor_handler = { }, }; -static acpi_status acpi_processor_container_walk(acpi_handle handle, - u32 lvl, - void *context, - void **rv) -{ - struct acpi_device *adev; - acpi_status status; - - adev = acpi_get_acpi_dev(handle); - if (!adev) - return AE_ERROR; - - status = acpi_processor_add(adev, &processor_device_ids[0]); - acpi_put_acpi_dev(adev); - - return status; -} - static int acpi_processor_container_attach(struct acpi_device *dev, const struct acpi_device_id *id) { - acpi_walk_namespace(ACPI_TYPE_PROCESSOR, dev->handle, - ACPI_UINT32_MAX, acpi_processor_container_walk, - NULL, NULL, NULL); - return 1; } -- 2.25.1

2 1

[PATCH OLK-5.10 0/2] CVE-2024-39469
by Yu Liao 04 Jul '24

04 Jul '24

CVE-2024-39469 Matthew Wilcox (Oracle) (1): nilfs2: return the mapped address from nilfs_get_page() Ryusuke Konishi (1): nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors fs/nilfs2/dir.c | 59 +++++++++++++++++++++++-------------------------- 1 file changed, 28 insertions(+), 31 deletions(-) -- 2.33.0

2 3

[PATCH openEuler-1.0-LTS 0/2] Fix CVE-2024-36949
by Zheng Zucheng 04 Jul '24

04 Jul '24

Mukul Joshi (1): drm/amdkfd: Rework kfd_locked handling Zhigang Luo (1): amd/amdkfd: sync all devices to wait all processes being evicted drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 3 --- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 27 +++++++++++++++--------- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 1 + drivers/gpu/drm/amd/amdkfd/kfd_process.c | 8 ++++++- 4 files changed, 25 insertions(+), 14 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS V1] USB: core: Fix hang in usb_kill_urb by adding memory barriers
by Cheng Yu 04 Jul '24

04 Jul '24

From: Alan Stern <stern(a)rowland.harvard.edu> stable inclusion from stable-v5.10.96 commit e3b131e30e612ff0e32de6c1cb4f69f89db29193 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72HV CVE: CVE-2022-48760 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 26fbe9772b8c459687930511444ce443011f86bf upstream. The syzbot fuzzer has identified a bug in which processes hang waiting for usb_kill_urb() to return. It turns out the issue is not unlinking the URB; that works just fine. Rather, the problem arises when the wakeup notification that the URB has completed is not received. The reason is memory-access ordering on SMP systems. In outline form, usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on different CPUs perform the following actions: CPU 0 CPU 1 ---------------------------- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(&urb->reject); atomic_dec(&urb->use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); Confining your attention to urb->reject and urb->use_count, you can see that the overall pattern of accesses on CPU 0 is: write urb->reject, then read urb->use_count; whereas the overall pattern of accesses on CPU 1 is: write urb->use_count, then read urb->reject. This pattern is referred to in memory-model circles as SB (for "Store Buffering"), and it is well known that without suitable enforcement of the desired order of accesses -- in the form of memory barriers -- it is entirely possible for one or both CPUs to execute their reads ahead of their writes. The end result will be that sometimes CPU 0 sees the old un-decremented value of urb->use_count while CPU 1 sees the old un-incremented value of urb->reject. Consequently CPU 0 ends up on the wait queue and never gets woken up, leading to the observed hang in usb_kill_urb(). The same pattern of accesses occurs in usb_poison_urb() and the failure pathway of usb_hcd_submit_urb(). The problem is fixed by adding suitable memory barriers. To provide proper memory-access ordering in the SB pattern, a full barrier is required on both CPUs. The atomic_inc() and atomic_dec() accesses themselves don't provide any memory ordering, but since they are present, we can use the optimized smp_mb__after_atomic() memory barrier in the various routines to obtain the desired effect. This patch adds the necessary memory barriers. CC: <stable(a)vger.kernel.org> Reported-and-tested-by: syzbot+76629376e06e2c2ad626(a)syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Link: https://lore.kernel.org/r/Ye8K0QYee0Q0Nna2@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/usb/core/hcd.c | 14 ++++++++++++++ drivers/usb/core/urb.c | 12 ++++++++++++ 2 files changed, 26 insertions(+) diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index 62e6c526e6ed..acff95a9f239 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -1663,6 +1663,13 @@ int usb_hcd_submit_urb (struct urb *urb, gfp_t mem_flags) urb->hcpriv = NULL; INIT_LIST_HEAD(&urb->urb_list); atomic_dec(&urb->use_count); + /* + * Order the write of urb->use_count above before the read + * of urb->reject below. Pairs with the memory barriers in + * usb_kill_urb() and usb_poison_urb(). + */ + smp_mb__after_atomic(); + atomic_dec(&urb->dev->urbnum); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); @@ -1772,6 +1779,13 @@ static void __usb_hcd_giveback_urb(struct urb *urb) usb_anchor_resume_wakeups(anchor); atomic_dec(&urb->use_count); + /* + * Order the write of urb->use_count above before the read + * of urb->reject below. Pairs with the memory barriers in + * usb_kill_urb() and usb_poison_urb(). + */ + smp_mb__after_atomic(); + if (unlikely(atomic_read(&urb->reject))) wake_up(&usb_kill_urb_queue); usb_put_urb(urb); diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c index 5e844097a9e3..abf4681159df 100644 --- a/drivers/usb/core/urb.c +++ b/drivers/usb/core/urb.c @@ -692,6 +692,12 @@ void usb_kill_urb(struct urb *urb) if (!(urb && urb->dev && urb->ep)) return; atomic_inc(&urb->reject); + /* + * Order the write of urb->reject above before the read + * of urb->use_count below. Pairs with the barriers in + * __usb_hcd_giveback_urb() and usb_hcd_submit_urb(). + */ + smp_mb__after_atomic(); usb_hcd_unlink_urb(urb, -ENOENT); wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); @@ -733,6 +739,12 @@ void usb_poison_urb(struct urb *urb) if (!urb) return; atomic_inc(&urb->reject); + /* + * Order the write of urb->reject above before the read + * of urb->use_count below. Pairs with the barriers in + * __usb_hcd_giveback_urb() and usb_hcd_submit_urb(). + */ + smp_mb__after_atomic(); if (!urb->dev || !urb->ep) return; -- 2.25.1

2 1

[openeuler:openEuler-1.0-LTS 23159/23203] include/asm-generic/atomic-instrumented.h:33:9: warning: 'wait_req' may be used uninitialized
by kernel test robot 04 Jul '24

04 Jul '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 3747e12f550e11fcfb6878af5c6e88f3e4af0d1f commit: 6741506ca02825b90e77088e8fce01c3d02edfdd [23159/23203] nilfs2: fix unexpected freezing of nilfs_segctor_sync() config: x86_64-buildonly-randconfig-005-20240704 (https://download.01.org/0day-ci/archive/20240704/202407041352.YmlrzTKf-lkp@…) compiler: gcc-12 (Ubuntu 12.3.0-9ubuntu2) 12.3.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240704/202407041352.YmlrzTKf-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202407041352.YmlrzTKf-lkp@intel.com/ Note: it may well be a FALSE warning. FWIW you are at least aware of it now. http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings All warnings (new ones prefixed by >>): In file included from arch/x86/include/asm/atomic.h:265, from arch/x86/include/asm/msr.h:67, from arch/x86/include/asm/processor.h:21, from arch/x86/include/asm/cpufeature.h:5, from arch/x86/include/asm/thread_info.h:53, from include/linux/thread_bits.h:22, from include/linux/thread_info.h:14, from arch/x86/include/asm/preempt.h:7, from include/linux/preempt.h:81, from include/linux/spinlock.h:51, from include/linux/mmzone.h:9, from include/linux/gfp.h:6, from include/linux/mm.h:11, from include/linux/pagemap.h:8, from fs/nilfs2/segment.c:11: In function 'atomic_set', inlined from 'nilfs_segctor_sync' at fs/nilfs2/segment.c:2175:2: >> include/asm-generic/atomic-instrumented.h:33:9: warning: 'wait_req' may be used uninitialized [-Wmaybe-uninitialized] 33 | kasan_check_write(v, sizeof(*v)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/linux/compiler.h:265, from include/asm-generic/bug.h:5, from arch/x86/include/asm/bug.h:83, from include/linux/bug.h:5, from include/linux/mmdebug.h:5, from include/linux/mm.h:10: include/linux/kasan-checks.h: In function 'nilfs_segctor_sync': include/linux/kasan-checks.h:7:6: note: by argument 1 of type 'const volatile void *' to 'kasan_check_write' declared here 7 | void kasan_check_write(const volatile void *p, unsigned int size); | ^~~~~~~~~~~~~~~~~ fs/nilfs2/segment.c:2170:43: note: 'wait_req' declared here 2170 | struct nilfs_segctor_wait_request wait_req; | ^~~~~~~~ vim +/wait_req +33 include/asm-generic/atomic-instrumented.h b06ed71a624ba0 Dmitry Vyukov 2018-01-29 30 b06ed71a624ba0 Dmitry Vyukov 2018-01-29 31 static __always_inline void atomic_set(atomic_t *v, int i) b06ed71a624ba0 Dmitry Vyukov 2018-01-29 32 { a35353bb9eb199 Dmitry Vyukov 2018-01-29 @33 kasan_check_write(v, sizeof(*v)); b06ed71a624ba0 Dmitry Vyukov 2018-01-29 34 arch_atomic_set(v, i); b06ed71a624ba0 Dmitry Vyukov 2018-01-29 35 } b06ed71a624ba0 Dmitry Vyukov 2018-01-29 36 :::::: The code at line 33 was first introduced by commit :::::: a35353bb9eb1990a44a0d7585f99e9589bcdb682 locking/atomic, asm-generic: Add KASAN instrumentation to atomic operations :::::: TO: Dmitry Vyukov <dvyukov(a)google.com> :::::: CC: Ingo Molnar <mingo(a)kernel.org> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] Revert "ACPI: processor: Add support for processors described as container packages"
by liwei 04 Jul '24

04 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAAJ94 ---------------------------- 'processor_container_handler' identifies ACPI0010 does not match the Processor information reported by DSDT. This reverts commit 2f257a8ec840ccc5fcefab424f468552da7b15ff. Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/acpi/acpi_processor.c | 22 ---------------------- 1 file changed, 22 deletions(-) diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c index 0ff69af46a50..d46e1fe25d58 100644 --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -698,31 +698,9 @@ static struct acpi_scan_handler processor_handler = { }, }; -static acpi_status acpi_processor_container_walk(acpi_handle handle, - u32 lvl, - void *context, - void **rv) -{ - struct acpi_device *adev; - acpi_status status; - - adev = acpi_get_acpi_dev(handle); - if (!adev) - return AE_ERROR; - - status = acpi_processor_add(adev, &processor_device_ids[0]); - acpi_put_acpi_dev(adev); - - return status; -} - static int acpi_processor_container_attach(struct acpi_device *dev, const struct acpi_device_id *id) { - acpi_walk_namespace(ACPI_TYPE_PROCESSOR, dev->handle, - ACPI_UINT32_MAX, acpi_processor_container_walk, - NULL, NULL, NULL); - return 1; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] scsi: qedf: Ensure the copied buf is NUL terminated
by Zheng Zucheng 04 Jul '24

04 Jul '24

From: Bui Quang Minh <minhquangbui99(a)gmail.com> mainline inclusion from mainline-v6.10-rc1 commit d0184a375ee797eb657d74861ba0935b6e405c62 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SHD CVE: CVE-2024-38559 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Currently, we allocate a count-sized kernel buffer and copy count from userspace to that buffer. Later, we use kstrtouint on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using kstrtouint. Fix this issue by using memdup_user_nul instead of memdup_user. Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.") Signed-off-by: Bui Quang Minh <minhquangbui99(a)gmail.com> Link: https://lore.kernel.org/r/20240424-fix-oob-read-v2-4-f1f1b53a10f4@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/scsi/qedf/qedf_debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/qedf/qedf_debugfs.c b/drivers/scsi/qedf/qedf_debugfs.c index c29c162a494f..e7a609b5791d 100644 --- a/drivers/scsi/qedf/qedf_debugfs.c +++ b/drivers/scsi/qedf/qedf_debugfs.c @@ -181,7 +181,7 @@ qedf_dbg_debug_cmd_write(struct file *filp, const char __user *buffer, if (!count || *ppos) return 0; - kern_buf = memdup_user(buffer, count); + kern_buf = memdup_user_nul(buffer, count); if (IS_ERR(kern_buf)) return PTR_ERR(kern_buf); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] dma-mapping: benchmark: handle NUMA_NO_NODE correctly
by Liu Shixin 04 Jul '24

04 Jul '24

From: Fedor Pchelkin <pchelkin(a)ispras.ru> mainline inclusion from mainline-v6.10-rc2 commit e64746e74f717961250a155e14c156616fcd981f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7DCL CVE: CVE-2024-39277 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- cpumask_of_node() can be called for NUMA_NO_NODE inside do_map_benchmark() resulting in the following sanitizer report: UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask [64][1]' CPU: 1 PID: 990 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) ubsan_epilogue (lib/ubsan.c:232) __ubsan_handle_out_of_bounds (lib/ubsan.c:429) cpumask_of_node (arch/x86/include/asm/topology.h:72) [inline] do_map_benchmark (kernel/dma/map_benchmark.c:104) map_benchmark_ioctl (kernel/dma/map_benchmark.c:246) full_proxy_unlocked_ioctl (fs/debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Use cpumask_of_node() in place when binding a kernel thread to a cpuset of a particular node. Note that the provided node id is checked inside map_benchmark_ioctl(). It's just a NUMA_NO_NODE case which is not handled properly later. Found by Linux Verification Center (linuxtesting.org) Fixes: 65789daa8087 ("dma-mapping: add benchmark support for streaming DMA APIs") Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> Acked-by: Barry Song <baohua(a)kernel.org> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- kernel/dma/map_benchmark.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/kernel/dma/map_benchmark.c b/kernel/dma/map_benchmark.c index e0e64f8b0739..c2d225e1cd47 100644 --- a/kernel/dma/map_benchmark.c +++ b/kernel/dma/map_benchmark.c @@ -121,7 +121,6 @@ static int do_map_benchmark(struct map_benchmark_data *map) struct task_struct **tsk; int threads = map->bparam.threads; int node = map->bparam.node; - const cpumask_t *cpu_mask = cpumask_of_node(node); u64 loops; int ret = 0; int i; @@ -142,7 +141,7 @@ static int do_map_benchmark(struct map_benchmark_data *map) } if (node != NUMA_NO_NODE) - kthread_bind_mask(tsk[i], cpu_mask); + kthread_bind_mask(tsk[i], cpumask_of_node(node)); } /* clear the old value in the previous benchmark */ -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries
by Liu Shixin 04 Jul '24

04 Jul '24

From: Zhipeng Lu <alexious(a)zju.edu.cn> stable inclusion from stable-v5.10.219 commit 4b68b861b514a5c09220d622ac3784c0ebac6c80 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SGC CVE: CVE-2024-38547 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 3b621e9e9e148c0928ab109ac3d4b81487469acb ] The allocation failure of mycs->yuv_scaler_binary in load_video_binaries() is followed with a dereference of mycs->yuv_scaler_binary after the following call chain: sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries() In unload_video_binaries(), it calls to ia_css_binary_unload with argument &pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to the same memory slot as mycs->yuv_scaler_binary. Thus, a null-pointer dereference is triggered. Link: https://lore.kernel.org/r/20240118151303.3828292-1-alexious@zju.edu.cn Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") Signed-off-by: Zhipeng Lu <alexious(a)zju.edu.cn> Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- drivers/staging/media/atomisp/pci/sh_css.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/media/atomisp/pci/sh_css.c b/drivers/staging/media/atomisp/pci/sh_css.c index 54a18921fbd1..cb0354520360 100644 --- a/drivers/staging/media/atomisp/pci/sh_css.c +++ b/drivers/staging/media/atomisp/pci/sh_css.c @@ -5477,6 +5477,7 @@ static int load_video_binaries(struct ia_css_pipe *pipe) mycs->yuv_scaler_binary = kzalloc(cas_scaler_descr.num_stage * sizeof(struct ia_css_binary), GFP_KERNEL); if (!mycs->yuv_scaler_binary) { + mycs->num_yuv_scaler = 0; err = -ENOMEM; return err; } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/1] CVE-2024-38621
by Liao Chen 04 Jul '24

04 Jul '24

media: stk1160: fix bounds checking in stk1160_copy_video() Dan Carpenter (1): media: stk1160: fix bounds checking in stk1160_copy_video() drivers/media/usb/stk1160/stk1160-video.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS] net/9p: fix uninit-value in p9_client_rpc()
by Yang Yingliang 04 Jul '24

04 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.10-rc2 commit 25460d6f39024cc3b8241b14c7ccf0d6f11a736a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA8AEF CVE: CVE-2024-39301 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Syzbot with the help of KMSAN reported the following error: BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline] BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 trace_9p_client_res include/trace/events/9p.h:146 [inline] p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2175 [inline] allocate_slab mm/slub.c:2338 [inline] new_slab+0x2de/0x1400 mm/slub.c:2391 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525 __slab_alloc mm/slub.c:3610 [inline] __slab_alloc_node mm/slub.c:3663 [inline] slab_alloc_node mm/slub.c:3835 [inline] kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852 p9_tag_alloc net/9p/client.c:278 [inline] p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag will not be properly initialized. However, trace_9p_client_res() ends up trying to print it out anyway before p9_client_rpc() finishes. Fix this issue by assigning default values to p9_fcall fields such as 'tag' and (just in case KMSAN unearths something new) 'id' during the tag allocation stage. Reported-and-tested-by: syzbot+ff14db38f56329ef68df(a)syzkaller.appspotmail.com Fixes: 348b59012e5c ("net/9p: Convert net/9p protocol dumps to tracepoints") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Reviewed-by: Christian Schoenebeck <linux_oss(a)crudebyte.com> Cc: stable(a)vger.kernel.org Message-ID: <20240408141039.30428-1-n.zhandarovich(a)fintech.ru> Signed-off-by: Dominique Martinet <asmadeus(a)codewreck.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- net/9p/client.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/9p/client.c b/net/9p/client.c index d62f83f93d7b..557b7798d642 100644 --- a/net/9p/client.c +++ b/net/9p/client.c @@ -250,6 +250,8 @@ static int p9_fcall_init(struct p9_client *c, struct p9_fcall *fc, if (!fc->sdata) return -ENOMEM; fc->capacity = alloc_msize; + fc->id = 0; + fc->tag = P9_NOTAG; return 0; } -- 2.25.1

2 1

[PATCH OLK-6.6] net/9p: fix uninit-value in p9_client_rpc()
by Yang Yingliang 04 Jul '24

04 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.10-rc2 commit 25460d6f39024cc3b8241b14c7ccf0d6f11a736a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA8AEF CVE: CVE-2024-39301 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Syzbot with the help of KMSAN reported the following error: BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline] BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 trace_9p_client_res include/trace/events/9p.h:146 [inline] p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2175 [inline] allocate_slab mm/slub.c:2338 [inline] new_slab+0x2de/0x1400 mm/slub.c:2391 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525 __slab_alloc mm/slub.c:3610 [inline] __slab_alloc_node mm/slub.c:3663 [inline] slab_alloc_node mm/slub.c:3835 [inline] kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852 p9_tag_alloc net/9p/client.c:278 [inline] p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag will not be properly initialized. However, trace_9p_client_res() ends up trying to print it out anyway before p9_client_rpc() finishes. Fix this issue by assigning default values to p9_fcall fields such as 'tag' and (just in case KMSAN unearths something new) 'id' during the tag allocation stage. Reported-and-tested-by: syzbot+ff14db38f56329ef68df(a)syzkaller.appspotmail.com Fixes: 348b59012e5c ("net/9p: Convert net/9p protocol dumps to tracepoints") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Reviewed-by: Christian Schoenebeck <linux_oss(a)crudebyte.com> Cc: stable(a)vger.kernel.org Message-ID: <20240408141039.30428-1-n.zhandarovich(a)fintech.ru> Signed-off-by: Dominique Martinet <asmadeus(a)codewreck.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- net/9p/client.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/9p/client.c b/net/9p/client.c index f7e90b4769bb..b05f73c291b4 100644 --- a/net/9p/client.c +++ b/net/9p/client.c @@ -235,6 +235,8 @@ static int p9_fcall_init(struct p9_client *c, struct p9_fcall *fc, if (!fc->sdata) return -ENOMEM; fc->capacity = alloc_msize; + fc->id = 0; + fc->tag = P9_NOTAG; return 0; } -- 2.25.1

2 1

[PATCH OLK-5.10] net/9p: fix uninit-value in p9_client_rpc()
by Yang Yingliang 04 Jul '24

04 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.10-rc2 commit 25460d6f39024cc3b8241b14c7ccf0d6f11a736a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA8AEF CVE: CVE-2024-39301 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Syzbot with the help of KMSAN reported the following error: BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline] BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 trace_9p_client_res include/trace/events/9p.h:146 [inline] p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2175 [inline] allocate_slab mm/slub.c:2338 [inline] new_slab+0x2de/0x1400 mm/slub.c:2391 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525 __slab_alloc mm/slub.c:3610 [inline] __slab_alloc_node mm/slub.c:3663 [inline] slab_alloc_node mm/slub.c:3835 [inline] kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852 p9_tag_alloc net/9p/client.c:278 [inline] p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag will not be properly initialized. However, trace_9p_client_res() ends up trying to print it out anyway before p9_client_rpc() finishes. Fix this issue by assigning default values to p9_fcall fields such as 'tag' and (just in case KMSAN unearths something new) 'id' during the tag allocation stage. Reported-and-tested-by: syzbot+ff14db38f56329ef68df(a)syzkaller.appspotmail.com Fixes: 348b59012e5c ("net/9p: Convert net/9p protocol dumps to tracepoints") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Reviewed-by: Christian Schoenebeck <linux_oss(a)crudebyte.com> Cc: stable(a)vger.kernel.org Message-ID: <20240408141039.30428-1-n.zhandarovich(a)fintech.ru> Signed-off-by: Dominique Martinet <asmadeus(a)codewreck.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- net/9p/client.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/9p/client.c b/net/9p/client.c index cd85a4b6448b..0fa324e8b245 100644 --- a/net/9p/client.c +++ b/net/9p/client.c @@ -235,6 +235,8 @@ static int p9_fcall_init(struct p9_client *c, struct p9_fcall *fc, if (!fc->sdata) return -ENOMEM; fc->capacity = alloc_msize; + fc->id = 0; + fc->tag = P9_NOTAG; return 0; } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] net/9p: fix uninit-value in p9_client_rpc()
by Yang Yingliang 04 Jul '24

04 Jul '24

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> mainline inclusion from mainline-v6.10-rc2 commit 25460d6f39024cc3b8241b14c7ccf0d6f11a736a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA8AEF CVE: CVE-2024-39301 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- Syzbot with the help of KMSAN reported the following error: BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline] BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 trace_9p_client_res include/trace/events/9p.h:146 [inline] p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2175 [inline] allocate_slab mm/slub.c:2338 [inline] new_slab+0x2de/0x1400 mm/slub.c:2391 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525 __slab_alloc mm/slub.c:3610 [inline] __slab_alloc_node mm/slub.c:3663 [inline] slab_alloc_node mm/slub.c:3835 [inline] kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852 p9_tag_alloc net/9p/client.c:278 [inline] p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag will not be properly initialized. However, trace_9p_client_res() ends up trying to print it out anyway before p9_client_rpc() finishes. Fix this issue by assigning default values to p9_fcall fields such as 'tag' and (just in case KMSAN unearths something new) 'id' during the tag allocation stage. Reported-and-tested-by: syzbot+ff14db38f56329ef68df(a)syzkaller.appspotmail.com Fixes: 348b59012e5c ("net/9p: Convert net/9p protocol dumps to tracepoints") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Reviewed-by: Christian Schoenebeck <linux_oss(a)crudebyte.com> Cc: stable(a)vger.kernel.org Message-ID: <20240408141039.30428-1-n.zhandarovich(a)fintech.ru> Signed-off-by: Dominique Martinet <asmadeus(a)codewreck.org> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- net/9p/client.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/9p/client.c b/net/9p/client.c index cd85a4b6448b..0fa324e8b245 100644 --- a/net/9p/client.c +++ b/net/9p/client.c @@ -235,6 +235,8 @@ static int p9_fcall_init(struct p9_client *c, struct p9_fcall *fc, if (!fc->sdata) return -ENOMEM; fc->capacity = alloc_msize; + fc->id = 0; + fc->tag = P9_NOTAG; return 0; } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()
by Tong Tiangen 04 Jul '24

04 Jul '24

From: Hao Chen <chenhao418(a)huawei.com> mainline inclusion from mainline-v6.9-rc1 commit 582c1aeee0a9e73010cf1c4cef338709860deeb0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9HCSA CVE: CVE-2024-38603 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=fo… ------------------------------------------------------------------------ pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action() fails, the irq vector is not freed, which leads to a memory leak. Replace the devm_add_action with devm_add_action_or_reset to ensure the irq vector can be destroyed when it fails. Fixes: 66637ab137b4 ("drivers/perf: hisi: add driver for HNS3 PMU") Signed-off-by: Hao Chen <chenhao418(a)huawei.com> Signed-off-by: Junhao He <hejunhao3(a)huawei.com> Reviewed-by: Jijie Shao <shaojijie(a)huawei.com> Acked-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Link: https://lore.kernel.org/r/20240425124627.13764-4-hejunhao3@huawei.com Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Slim6882 <yangjunshuo(a)huawei.com> Signed-off-by: Tong Tiangen <tongtiangen(a)huawei.com> --- drivers/perf/hisilicon/hns3_pmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/perf/hisilicon/hns3_pmu.c b/drivers/perf/hisilicon/hns3_pmu.c index 08b2068b5278..40edc4cfcc34 100644 --- a/drivers/perf/hisilicon/hns3_pmu.c +++ b/drivers/perf/hisilicon/hns3_pmu.c @@ -1518,7 +1518,7 @@ static int hns3_pmu_irq_register(struct pci_dev *pdev, return ret; } - ret = devm_add_action(&pdev->dev, hns3_pmu_free_irq, pdev); + ret = devm_add_action_or_reset(&pdev->dev, hns3_pmu_free_irq, pdev); if (ret) { pci_err(pdev, "failed to add free irq action, ret = %d.\n", ret); return ret; -- 2.25.1

2 1

[PATCH OLK-6.6 0/2] CVE-2024-39469
by Yu Liao 04 Jul '24

04 Jul '24

CVE-2024-39469 Matthew Wilcox (Oracle) (1): [Backport] nilfs2: return the mapped address from nilfs_get_page() Ryusuke Konishi (1): [Backport] nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors fs/nilfs2/dir.c | 59 +++++++++++++++++++++++-------------------------- 1 file changed, 28 insertions(+), 31 deletions(-) -- 2.33.0

2 3

[PATCH OLK-5.10 v2 0/5] Backport bpf bugfixes
by Zheng Yejian 04 Jul '24

04 Jul '24

v1 -> v2: Update bugzilla link info in patch1 & patch2 Daniel Borkmann (1): bpf: Fix __reg_bound_offset 64->32 var_off subreg propagation Krister Johansen (1): bpf: ensure main program has an extable Kumar Kartikeya Dwivedi (1): bpf: Clobber stack slot when writing over spilled PTR_TO_BTF_ID Stanislav Fomichev (1): bpf: Don't EFAULT for {g,s}setsockopt with wrong optlen Wang Yufen (1): bpf: Fix memory leaks in __check_func_call kernel/bpf/cgroup.c | 15 +++++++++ kernel/bpf/verifier.c | 33 +++++++++++-------- .../testing/selftests/bpf/prog_tests/align.c | 4 +-- 3 files changed, 37 insertions(+), 15 deletions(-) -- 2.25.1

2 6

[PATCH OLK-6.6] efi: libstub: only free priv.runtime_map when allocated
by Tong Tiangen 04 Jul '24

04 Jul '24

From: Hagar Hemdan <hagarhem(a)amazon.com> stable inclusion from stable-v6.6.33 commit 9dce01f386c9ce6990c0a83fa14b1c95330b037e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA7D2K CVE: CVE-2024-33619 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 4b2543f7e1e6b91cfc8dd1696e3cdf01c3ac8974 upstream. priv.runtime_map is only allocated when efi_novamap is not set. Otherwise, it is an uninitialized value. In the error path, it is freed unconditionally. Avoid passing an uninitialized value to free_pool. Free priv.runtime_map only when it was allocated. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Fixes: f80d26043af9 ("efi: libstub: avoid efi_get_memory_map() for allocating the virt map") Cc: <stable(a)vger.kernel.org> Signed-off-by: Hagar Hemdan <hagarhem(a)amazon.com> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Tong Tiangen <tongtiangen(a)huawei.com> --- drivers/firmware/efi/libstub/fdt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c index 70e9789ff9de..6a337f1f8787 100644 --- a/drivers/firmware/efi/libstub/fdt.c +++ b/drivers/firmware/efi/libstub/fdt.c @@ -335,8 +335,8 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle, fail: efi_free(fdt_size, fdt_addr); - - efi_bs_call(free_pool, priv.runtime_map); + if (!efi_novamap) + efi_bs_call(free_pool, priv.runtime_map); return EFI_LOAD_ERROR; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] seg6: fix the iif in the IPv6 socket control block
by Dong Chenchen 04 Jul '24

04 Jul '24

From: Andrea Mayer <andrea.mayer(a)uniroma2.it> stable inclusion from stable-v4.19.221 commit 6431e71093f3da586a00c6d931481ffb0dc2db0e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9S252 CVE: CVE-2021-47515 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ae68d93354e5bf5191ee673982251864ea24dd5c upstream. When an IPv4 packet is received, the ip_rcv_core(...) sets the receiving interface index into the IPv4 socket control block (v5.16-rc4, net/ipv4/ip_input.c line 510): IPCB(skb)->iif = skb->skb_iif; If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH header, the seg6_do_srh_encap(...) performs the required encapsulation. In this case, the seg6_do_srh_encap function clears the IPv6 socket control block (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163): memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); The memset(...) was introduced in commit ef489749aae5 ("ipv6: sr: clear IP6CB(skb) on SRH ip4ip6 encapsulation") a long time ago (2019-01-29). Since the IPv6 socket control block and the IPv4 socket control block share the same memory area (skb->cb), the receiving interface index info is lost (IP6CB(skb)->iif is set to zero). As a side effect, that condition triggers a NULL pointer dereference if commit 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig netdev") is applied. To fix that issue, we set the IP6CB(skb)->iif with the index of the receiving interface once again. Fixes: ef489749aae5 ("ipv6: sr: clear IP6CB(skb) on SRH ip4ip6 encapsulation") Signed-off-by: Andrea Mayer <andrea.mayer(a)uniroma2.it> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://lore.kernel.org/r/20211208195409.12169-1-andrea.mayer@uniroma2.it Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/ipv6/seg6_iptunnel.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c index ee5403cbe655..26882fd9323a 100644 --- a/net/ipv6/seg6_iptunnel.c +++ b/net/ipv6/seg6_iptunnel.c @@ -148,6 +148,14 @@ int seg6_do_srh_encap(struct sk_buff *skb, struct ipv6_sr_hdr *osrh, int proto) hdr->hop_limit = ip6_dst_hoplimit(skb_dst(skb)); memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); + + /* the control block has been erased, so we have to set the + * iif once again. + * We read the receiving interface index directly from the + * skb->skb_iif as it is done in the IPv4 receiving path (i.e.: + * ip_rcv_core(...)). + */ + IP6CB(skb)->iif = skb->skb_iif; } hdr->nexthdr = NEXTHDR_ROUTING; -- 2.25.1

2 1

[PATCH OLK-5.10 0/5] Backport bpf bugfixes
by Zheng Yejian 04 Jul '24

04 Jul '24

Daniel Borkmann (1): bpf: Fix __reg_bound_offset 64->32 var_off subreg propagation Krister Johansen (1): bpf: ensure main program has an extable Kumar Kartikeya Dwivedi (1): bpf: Clobber stack slot when writing over spilled PTR_TO_BTF_ID Stanislav Fomichev (1): bpf: Don't EFAULT for {g,s}setsockopt with wrong optlen Wang Yufen (1): bpf: Fix memory leaks in __check_func_call kernel/bpf/cgroup.c | 15 +++++++++ kernel/bpf/verifier.c | 33 +++++++++++-------- .../testing/selftests/bpf/prog_tests/align.c | 4 +-- 3 files changed, 37 insertions(+), 15 deletions(-) -- 2.25.1

2 6

[openEuler-22.03-LTS-SP1 0/1] CVE-2024-38621
by Liao Chen 04 Jul '24

04 Jul '24

media: stk1160: fix bounds checking in stk1160_copy_video() Dan Carpenter (1): media: stk1160: fix bounds checking in stk1160_copy_video() drivers/media/usb/stk1160/stk1160-video.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) -- 2.34.1

1 1

[PATCH openEuler-1.0-LTS] net: amd-xgbe: Fix skb data length underflow
by Zheng Zucheng 04 Jul '24

04 Jul '24

From: Shyam Sundar S K <Shyam-sundar.S-k(a)amd.com> mainline inclusion from mainline-v5.17-rc3 commit 5aac9108a180fc06e28d4e7fb00247ce603b72ee category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72MM CVE: CVE-2022-48743 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors. Fixes: 622c36f143fc ("amd-xgbe: Fix jumbo MTU processing on newer hardware") Suggested-by: Tom Lendacky <thomas.lendacky(a)amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k(a)amd.com> Acked-by: Tom Lendacky <thomas.lendacky(a)amd.com> Link: https://lore.kernel.org/r/20220127092003.2812745-1-Shyam-sundar.S-k@amd.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> --- drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c index d96a84a62d78..cdbabd77f2d4 100644 --- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c +++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c @@ -2765,6 +2765,14 @@ static int xgbe_rx_poll(struct xgbe_channel *channel, int budget) buf2_len = xgbe_rx_buf2_len(rdata, packet, len); len += buf2_len; + if (buf2_len > rdata->rx.buf.dma_len) { + /* Hardware inconsistency within the descriptors + * that has resulted in a length underflow. + */ + error = 1; + goto skip_data; + } + if (!skb) { skb = xgbe_create_skb(pdata, napi, rdata, buf1_len); @@ -2794,8 +2802,10 @@ static int xgbe_rx_poll(struct xgbe_channel *channel, int budget) if (!last || context_next) goto read_again; - if (!skb) + if (!skb || error) { + dev_kfree_skb(skb); goto next_packet; + } /* Be sure we don't exceed the configured MTU */ max_len = netdev->mtu + ETH_HLEN; -- 2.34.1

2 1

[PATCH OLK-6.6] efi: libstub: only free priv.runtime_map when allocated
by Tong Tiangen 04 Jul '24

04 Jul '24

From: Hagar Hemdan <hagarhem(a)amazon.com> stable inclusion from stable-v6.6.33 commit 9dce01f386c9ce6990c0a83fa14b1c95330b037e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA74DQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 4b2543f7e1e6b91cfc8dd1696e3cdf01c3ac8974 upstream. priv.runtime_map is only allocated when efi_novamap is not set. Otherwise, it is an uninitialized value. In the error path, it is freed unconditionally. Avoid passing an uninitialized value to free_pool. Free priv.runtime_map only when it was allocated. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Fixes: f80d26043af9 ("efi: libstub: avoid efi_get_memory_map() for allocating the virt map") Cc: <stable(a)vger.kernel.org> Signed-off-by: Hagar Hemdan <hagarhem(a)amazon.com> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Tong Tiangen <tongtiangen(a)huawei.com> --- drivers/firmware/efi/libstub/fdt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c index 70e9789ff9de..6a337f1f8787 100644 --- a/drivers/firmware/efi/libstub/fdt.c +++ b/drivers/firmware/efi/libstub/fdt.c @@ -335,8 +335,8 @@ efi_status_t allocate_new_fdt_and_exit_boot(void *handle, fail: efi_free(fdt_size, fdt_addr); - - efi_bs_call(free_pool, priv.runtime_map); + if (!efi_novamap) + efi_bs_call(free_pool, priv.runtime_map); return EFI_LOAD_ERROR; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS v2 0/2] net: Fix CVE-2022-48757
by Dong Chenchen 04 Jul '24

04 Jul '24

fix CVE-2022-48757. Congyu Liu (1): net: fix information leakage in /proc/net/ptype Dong Chenchen (1): net: fix kabi breakage in struct packet_type include/linux/netdevice.h | 4 ++++ net/core/net-procfs.c | 3 ++- net/packet/af_packet.c | 2 ++ 3 files changed, 8 insertions(+), 1 deletion(-) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS 0/4] Fix CVE-2024-35915
by Zheng Zucheng 03 Jul '24

03 Jul '24

Ryosuke Yasuoka (3): nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet nfc: nci: Fix uninit-value in nci_rx_work nfc: nci: Fix handling of zero-length payload packets in nci_rx_work() Tetsuo Handa (1): nfc: nci: Fix kcov check in nci_rx_work() net/nfc/nci/core.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) -- 2.34.1

2 5

[PATCH openEuler-1.0-LTS 0/2] net: fix CVE-2022-48757
by Dong Chenchen 03 Jul '24

03 Jul '24

fix CVE-2022-48757. Congyu Liu (1): net: fix information leakage in /proc/net/ptype Dong Chenchen (1): net: fix kabi breakage in struct packet_type include/linux/netdevice.h | 4 ++++ net/core/net-procfs.c | 3 ++- net/packet/af_packet.c | 2 ++ 3 files changed, 8 insertions(+), 1 deletion(-) -- 2.25.1

2 3

[PATCH openEuler-22.03-LTS-SP1 0/1] ext4: delete redundant uptodate
by Zheng Zengkai 03 Jul '24

03 Jul '24

Backport patch from mainline to optimize file copy performance. Yang Guo (1): ext4: delete redundant uptodate check for buffer fs/ext4/inode.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) -- 2.20.1

2 2

[PATCH OLK-6.6] drm: vc4: Fix possible null pointer dereference
by Ze Zuo 03 Jul '24

03 Jul '24

From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v6.6.33 commit 42c22b63056cea259d5313bf138a834840af85a5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6SGI CVE: CVE-2024-38546 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit c534b63bede6cb987c2946ed4d0b0013a52c5ba7 ] In vc4_hdmi_audio_init() of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Signed-off-by: Maxime Ripard <mripard(a)kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240409075622.11783-1-amishi… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ze Zuo <zuoze1(a)huawei.com> --- drivers/gpu/drm/vc4/vc4_hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index 4626fe9aac56..643754fa6a8a 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -2729,6 +2729,8 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi *vc4_hdmi) index = 1; addr = of_get_address(dev->of_node, index, NULL, NULL); + if (!addr) + return -EINVAL; vc4_hdmi->audio.dma_data.addr = be32_to_cpup(addr) + mai_data->offset; vc4_hdmi->audio.dma_data.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES; -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] firewire: ohci: mask bus reset interrupts between ISR and bottom half
by Ze Zuo 03 Jul '24

03 Jul '24

From: Adam Goldman <adamg(a)pobox.com> stable inclusion from stable-v5.10.217 commit fa273f312334246c909475c5868e6daab889cc8c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UOCQ CVE: CVE-2024-36950 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 752e3c53de0fa3b7d817a83050b6699b8e9c6ec9 ] In the FireWire OHCI interrupt handler, if a bus reset interrupt has occurred, mask bus reset interrupts until bus_reset_work has serviced and cleared the interrupt. Normally, we always leave bus reset interrupts masked. We infer the bus reset from the self-ID interrupt that happens shortly thereafter. A scenario where we unmask bus reset interrupts was introduced in 2008 in a007bb857e0b26f5d8b73c2ff90782d9c0972620: If OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we will unmask bus reset interrupts so we can log them. irq_handler logs the bus reset interrupt. However, we can't clear the bus reset event flag in irq_handler, because we won't service the event until later. irq_handler exits with the event flag still set. If the corresponding interrupt is still unmasked, the first bus reset will usually freeze the system due to irq_handler being called again each time it exits. This freeze can be reproduced by loading firewire_ohci with "modprobe firewire_ohci debug=-1" (to enable all debugging output). Apparently there are also some cases where bus_reset_work will get called soon enough to clear the event, and operation will continue normally. This freeze was first reported a few months after a007bb85 was committed, but until now it was never fixed. The debug level could safely be set to -1 through sysfs after the module was loaded, but this would be ineffectual in logging bus reset interrupts since they were only unmasked during initialization. irq_handler will now leave the event flag set but mask bus reset interrupts, so irq_handler won't be called again and there will be no freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will unmask the interrupt after servicing the event, so future interrupts will be caught as desired. As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be enabled through sysfs in addition to during initial module loading. However, when enabled through sysfs, logging of bus reset interrupts will be effective only starting with the second bus reset, after bus_reset_work has executed. Signed-off-by: Adam Goldman <adamg(a)pobox.com> Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ze Zuo <zuoze1(a)huawei.com> --- drivers/firewire/ohci.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c index 9811c40956e5..5810b8f068ef 100644 --- a/drivers/firewire/ohci.c +++ b/drivers/firewire/ohci.c @@ -2001,6 +2001,8 @@ static void bus_reset_work(struct work_struct *work) ohci->generation = generation; reg_write(ohci, OHCI1394_IntEventClear, OHCI1394_busReset); + if (param_debug & OHCI_PARAM_DEBUG_BUSRESETS) + reg_write(ohci, OHCI1394_IntMaskSet, OHCI1394_busReset); if (ohci->quirks & QUIRK_RESET_PACKET) ohci->request_generation = generation; @@ -2067,12 +2069,14 @@ static irqreturn_t irq_handler(int irq, void *data) return IRQ_NONE; /* - * busReset and postedWriteErr must not be cleared yet + * busReset and postedWriteErr events must not be cleared yet * (OHCI 1.1 clauses 7.2.3.2 and 13.2.8.1) */ reg_write(ohci, OHCI1394_IntEventClear, event & ~(OHCI1394_busReset | OHCI1394_postedWriteErr)); log_irqs(ohci, event); + if (event & OHCI1394_busReset) + reg_write(ohci, OHCI1394_IntMaskClear, OHCI1394_busReset); if (event & OHCI1394_selfIDComplete) queue_work(selfid_workqueue, &ohci->bus_reset_work); -- 2.25.1

2 1

[PATCH OLK-5.10] KVM: LAPIC: Also cancel preemption timer during SET_LAPIC
by Zeng Heng 03 Jul '24

03 Jul '24

From: Wanpeng Li <wanpengli(a)tencent.com> mainline inclusion from mainline-v5.17-rc2 commit 35fe7cfbab2e81f1afb23fc4212210b1de6d9633 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72K9 CVE: CVE-2022-48765 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The below warning is splatting during guest reboot. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm] CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G I 5.17.0-rc1+ #5 RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm] Call Trace: <TASK> kvm_vcpu_ioctl+0x279/0x710 [kvm] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fd39797350b This can be triggered by not exposing tsc-deadline mode and doing a reboot in the guest. The lapic_shutdown() function which is called in sys_reboot path will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode switch between tsc-deadline and oneshot/periodic, which can result in preemption timer be cancelled in apic_update_lvtt(). However, We can't depend on this when not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption timer. Qemu will synchronise states around reset, let's cancel preemption timer under KVM_SET_LAPIC. Signed-off-by: Wanpeng Li <wanpengli(a)tencent.com> Message-Id: <1643102220-35667-1-git-send-email-wanpengli(a)tencent.com> Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Conflicts: arch/x86/kvm/lapic.c [Resolve conflicts due to several refactor patches not merged.] Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- arch/x86/kvm/lapic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 610a79f1c469..d6272f97368f 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2631,7 +2631,7 @@ int kvm_apic_set_state(struct kvm_vcpu *vcpu, struct kvm_lapic_state *s) kvm_apic_set_version(vcpu); apic_update_ppr(apic); - hrtimer_cancel(&apic->lapic_timer.timer); + cancel_apic_timer(apic); apic_update_lvtt(apic); apic_manage_nmi_watchdog(apic, kvm_lapic_get_reg(apic, APIC_LVT0)); update_divide_count(apic); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] KVM: LAPIC: Also cancel preemption timer during SET_LAPIC
by Zeng Heng 03 Jul '24

03 Jul '24

From: Wanpeng Li <wanpengli(a)tencent.com> mainline inclusion from mainline-v5.17-rc2 commit 35fe7cfbab2e81f1afb23fc4212210b1de6d9633 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA72K9 CVE: CVE-2022-48765 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The below warning is splatting during guest reboot. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm] CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G I 5.17.0-rc1+ #5 RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm] Call Trace: <TASK> kvm_vcpu_ioctl+0x279/0x710 [kvm] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fd39797350b This can be triggered by not exposing tsc-deadline mode and doing a reboot in the guest. The lapic_shutdown() function which is called in sys_reboot path will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode switch between tsc-deadline and oneshot/periodic, which can result in preemption timer be cancelled in apic_update_lvtt(). However, We can't depend on this when not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption timer. Qemu will synchronise states around reset, let's cancel preemption timer under KVM_SET_LAPIC. Signed-off-by: Wanpeng Li <wanpengli(a)tencent.com> Message-Id: <1643102220-35667-1-git-send-email-wanpengli(a)tencent.com> Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Conflicts: arch/x86/kvm/lapic.c [Resolve conflicts due to several refactor patches not merged.] Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- arch/x86/kvm/lapic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 610a79f1c469..d6272f97368f 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2631,7 +2631,7 @@ int kvm_apic_set_state(struct kvm_vcpu *vcpu, struct kvm_lapic_state *s) kvm_apic_set_version(vcpu); apic_update_ppr(apic); - hrtimer_cancel(&apic->lapic_timer.timer); + cancel_apic_timer(apic); apic_update_lvtt(apic); apic_manage_nmi_watchdog(apic, kvm_lapic_get_reg(apic, APIC_LVT0)); update_divide_count(apic); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ax25: Fix reference count leak issues of ax25_dev
by Liu Jian 03 Jul '24

03 Jul '24

From: Duoming Zhou <duoming(a)zju.edu.cn> mainline inclusion from mainline-v6.10-rc1 commit b505e0319852b08a3a716b64620168eab21f4ced category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S8I CVE: CVE-2024-38602 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference count leak issue of the object "ax25_dev". Memory leak issue in ax25_addr_ax25dev(): The reference count of the object "ax25_dev" can be increased multiple times in ax25_addr_ax25dev(). This will cause a memory leak. Memory leak issues in ax25_dev_device_down(): The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and then increase the reference count when ax25_dev is added to ax25_dev_list. As a result, the reference count of ax25_dev is 2. But when the device is shutting down. The ax25_dev_device_down() drops the reference count once or twice depending on if we goto unlock_put or not, which will cause memory leak. As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer to be on a list twice. So add a break in ax25_addr_ax25dev(). As for the issue of ax25_dev_device_down(), increase the reference count of ax25_dev once in ax25_dev_device_up() and decrease the reference count of ax25_dev after it is removed from the ax25_dev_list. Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs") Suggested-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/r/361bbf2a4b091e120006279ec3b382d73c4a0c17.17152470… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ax25/ax25_dev.c [The conflict occurs because the commit a968c799eb1d("ax25: merge repeat codes in ax25_dev_device_down()") and a7d6e36b9ad0("ax25: Use kernel universal linked list to implement ax25_dev_list") are not merged] Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/ax25/ax25_dev.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/net/ax25/ax25_dev.c b/net/ax25/ax25_dev.c index d1d8d8a21ddd..fe730fad1c38 100644 --- a/net/ax25/ax25_dev.c +++ b/net/ax25/ax25_dev.c @@ -38,6 +38,7 @@ ax25_dev *ax25_addr_ax25dev(ax25_address *addr) if (ax25cmp(addr, (ax25_address *)ax25_dev->dev->dev_addr) == 0) { res = ax25_dev; ax25_dev_hold(ax25_dev); + break; } spin_unlock_bh(&ax25_dev_lock); @@ -86,7 +87,6 @@ void ax25_dev_device_up(struct net_device *dev) ax25_dev->next = ax25_dev_list; ax25_dev_list = ax25_dev; spin_unlock_bh(&ax25_dev_lock); - ax25_dev_hold(ax25_dev); ax25_register_dev_sysctl(ax25_dev); } @@ -116,7 +116,6 @@ void ax25_dev_device_down(struct net_device *dev) if ((s = ax25_dev_list) == ax25_dev) { ax25_dev_list = s->next; spin_unlock_bh(&ax25_dev_lock); - ax25_dev_put(ax25_dev); dev->ax25_ptr = NULL; dev_put(dev); ax25_dev_put(ax25_dev); @@ -127,7 +126,6 @@ void ax25_dev_device_down(struct net_device *dev) if (s->next == ax25_dev) { s->next = ax25_dev->next; spin_unlock_bh(&ax25_dev_lock); - ax25_dev_put(ax25_dev); dev->ax25_ptr = NULL; dev_put(dev); ax25_dev_put(ax25_dev); -- 2.34.1

2 1

[PATCH OLK-5.10] ax25: Fix reference count leak issues of ax25_dev
by Liu Jian 03 Jul '24

03 Jul '24

From: Duoming Zhou <duoming(a)zju.edu.cn> mainline inclusion from mainline-v6.10-rc1 commit b505e0319852b08a3a716b64620168eab21f4ced category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA6S8I CVE: CVE-2024-38602 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference count leak issue of the object "ax25_dev". Memory leak issue in ax25_addr_ax25dev(): The reference count of the object "ax25_dev" can be increased multiple times in ax25_addr_ax25dev(). This will cause a memory leak. Memory leak issues in ax25_dev_device_down(): The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and then increase the reference count when ax25_dev is added to ax25_dev_list. As a result, the reference count of ax25_dev is 2. But when the device is shutting down. The ax25_dev_device_down() drops the reference count once or twice depending on if we goto unlock_put or not, which will cause memory leak. As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer to be on a list twice. So add a break in ax25_addr_ax25dev(). As for the issue of ax25_dev_device_down(), increase the reference count of ax25_dev once in ax25_dev_device_up() and decrease the reference count of ax25_dev after it is removed from the ax25_dev_list. Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs") Suggested-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Duoming Zhou <duoming(a)zju.edu.cn> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://lore.kernel.org/r/361bbf2a4b091e120006279ec3b382d73c4a0c17.17152470… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ax25/ax25_dev.c [The conflict occurs because the commit a968c799eb1d("ax25: merge repeat codes in ax25_dev_device_down()") and a7d6e36b9ad0("ax25: Use kernel universal linked list to implement ax25_dev_list") are not merged] Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/ax25/ax25_dev.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/net/ax25/ax25_dev.c b/net/ax25/ax25_dev.c index d1d8d8a21ddd..fe730fad1c38 100644 --- a/net/ax25/ax25_dev.c +++ b/net/ax25/ax25_dev.c @@ -38,6 +38,7 @@ ax25_dev *ax25_addr_ax25dev(ax25_address *addr) if (ax25cmp(addr, (ax25_address *)ax25_dev->dev->dev_addr) == 0) { res = ax25_dev; ax25_dev_hold(ax25_dev); + break; } spin_unlock_bh(&ax25_dev_lock); @@ -86,7 +87,6 @@ void ax25_dev_device_up(struct net_device *dev) ax25_dev->next = ax25_dev_list; ax25_dev_list = ax25_dev; spin_unlock_bh(&ax25_dev_lock); - ax25_dev_hold(ax25_dev); ax25_register_dev_sysctl(ax25_dev); } @@ -116,7 +116,6 @@ void ax25_dev_device_down(struct net_device *dev) if ((s = ax25_dev_list) == ax25_dev) { ax25_dev_list = s->next; spin_unlock_bh(&ax25_dev_lock); - ax25_dev_put(ax25_dev); dev->ax25_ptr = NULL; dev_put(dev); ax25_dev_put(ax25_dev); @@ -127,7 +126,6 @@ void ax25_dev_device_down(struct net_device *dev) if (s->next == ax25_dev) { s->next = ax25_dev->next; spin_unlock_bh(&ax25_dev_lock); - ax25_dev_put(ax25_dev); dev->ax25_ptr = NULL; dev_put(dev); ax25_dev_put(ax25_dev); -- 2.34.1

2 1