From: Thomas Gleixner <tglx(a)linutronix.de>
stable inclusion
from stable-v6.6.55
commit 077e1b7cd521163ded545987bbbd389519aeed71
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRCY
CVE: CVE-2024-49927
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id…
--------------------------------
[ Upstream commit 830802a0fea8fb39d3dc9fb7d6b5581e1343eb1f ]
Breno observed panics when using failslab under certain conditions during
runtime:
can not alloc irq_pin_list (-1,0,20)
Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed
panic+0x4e9/0x590
mp_irqdomain_alloc+0x9ab/0xa80
irq_domain_alloc_irqs_locked+0x25d/0x8d0
__irq_domain_alloc_irqs+0x80/0x110
mp_map_pin_to_irq+0x645/0x890
acpi_register_gsi_ioapic+0xe6/0x150
hpet_open+0x313/0x480
That's a pointless panic which is a leftover of the historic IO/APIC code
which panic'ed during early boot when the interrupt allocation failed.
The only place which might justify panic is the PIT/HPET timer_check() code
which tries to figure out whether the timer interrupt is delivered through
the IO/APIC. But that code does not require to handle interrupt allocation
failures. If the interrupt cannot be allocated then timer delivery fails
and it either panics due to that or falls back to legacy mode.
Cure this by removing the panic wrapper around __add_pin_to_irq_node() and
making mp_irqdomain_alloc() aware of the failure condition and handle it as
any other failure in this function gracefully.
Reported-by: Breno Leitao <leitao(a)debian.org>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Tested-by: Breno Leitao <leitao(a)debian.org>
Tested-by: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
Link: https://lore.kernel.org/all/ZqfJmUF8sXIyuSHN@gmail.com
Link: https://lore.kernel.org/all/20240802155440.275200843@linutronix.de
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com>
---
arch/x86/kernel/apic/io_apic.c | 46 ++++++++++++++++------------------
1 file changed, 22 insertions(+), 24 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 00da6cf6b07d..d0c5325d1751 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -352,27 +352,26 @@ static void ioapic_mask_entry(int apic, int pin)
* shared ISA-space IRQs, so we have to support them. We are super
* fast in the common case, and fast for shared ISA-space IRQs.
*/
-static int __add_pin_to_irq_node(struct mp_chip_data *data,
- int node, int apic, int pin)
+static bool add_pin_to_irq_node(struct mp_chip_data *data, int node, int apic, int pin)
{
struct irq_pin_list *entry;
- /* don't allow duplicates */
- for_each_irq_pin(entry, data->irq_2_pin)
+ /* Don't allow duplicates */
+ for_each_irq_pin(entry, data->irq_2_pin) {
if (entry->apic == apic && entry->pin == pin)
- return 0;
+ return true;
+ }
entry = kzalloc_node(sizeof(struct irq_pin_list), GFP_ATOMIC, node);
if (!entry) {
- pr_err("can not alloc irq_pin_list (%d,%d,%d)\n",
- node, apic, pin);
- return -ENOMEM;
+ pr_err("Cannot allocate irq_pin_list (%d,%d,%d)\n", node, apic, pin);
+ return false;
}
+
entry->apic = apic;
entry->pin = pin;
list_add_tail(&entry->list, &data->irq_2_pin);
-
- return 0;
+ return true;
}
static void __remove_pin_from_irq(struct mp_chip_data *data, int apic, int pin)
@@ -387,13 +386,6 @@ static void __remove_pin_from_irq(struct mp_chip_data *data, int apic, int pin)
}
}
-static void add_pin_to_irq_node(struct mp_chip_data *data,
- int node, int apic, int pin)
-{
- if (__add_pin_to_irq_node(data, node, apic, pin))
- panic("IO-APIC: failed to add irq-pin. Can not proceed\n");
-}
-
/*
* Reroute an IRQ to a different pin.
*/
@@ -1002,8 +994,7 @@ static int alloc_isa_irq_from_domain(struct irq_domain *domain,
if (irq_data && irq_data->parent_data) {
if (!mp_check_pin_attr(irq, info))
return -EBUSY;
- if (__add_pin_to_irq_node(irq_data->chip_data, node, ioapic,
- info->ioapic.pin))
+ if (!add_pin_to_irq_node(irq_data->chip_data, node, ioapic, info->ioapic.pin))
return -ENOMEM;
} else {
info->flags |= X86_IRQ_ALLOC_LEGACY;
@@ -3037,10 +3028,8 @@ int mp_irqdomain_alloc(struct irq_domain *domain, unsigned int virq,
return -ENOMEM;
ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, info);
- if (ret < 0) {
- kfree(data);
- return ret;
- }
+ if (ret < 0)
+ goto free_data;
INIT_LIST_HEAD(&data->irq_2_pin);
irq_data->hwirq = info->ioapic.pin;
@@ -3049,7 +3038,10 @@ int mp_irqdomain_alloc(struct irq_domain *domain, unsigned int virq,
irq_data->chip_data = data;
mp_irqdomain_get_attr(mp_pin_to_gsi(ioapic, pin), data, info);
- add_pin_to_irq_node(data, ioapic_alloc_attr_node(info), ioapic, pin);
+ if (!add_pin_to_irq_node(data, ioapic_alloc_attr_node(info), ioapic, pin)) {
+ ret = -ENOMEM;
+ goto free_irqs;
+ }
mp_preconfigure_entry(data);
mp_register_handler(virq, data->is_level);
@@ -3064,6 +3056,12 @@ int mp_irqdomain_alloc(struct irq_domain *domain, unsigned int virq,
ioapic, mpc_ioapic_id(ioapic), pin, virq,
data->is_level, data->active_low);
return 0;
+
+free_irqs:
+ irq_domain_free_irqs_parent(domain, virq, nr_irqs);
+free_data:
+ kfree(data);
+ return ret;
}
void mp_irqdomain_free(struct irq_domain *domain, unsigned int virq,
--
2.34.1
mainline inclusion
from mainline-v6.9-rc1
commit 570b9147deb6b07b955b55e06c714ca12a5f3e16
bugzilla: https://gitee.com/openeuler/kernel/issues/IAZESX
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
--------------------------------
Since md_start_sync() will be called without the protect of mddev_lock,
and it can run concurrently with array reconfiguration, traversal of rdev
in it should be protected by RCU lock.
Commit bc08041b32ab ("md: suspend array in md_start_sync() if array need
reconfiguration") added md_spares_need_change() to md_start_sync(),
casusing use of rdev without any protection.
Fix this by adding RCU lock in md_spares_need_change().
Fixes: bc08041b32ab ("md: suspend array in md_start_sync() if array need reconfiguration")
Cc: stable(a)vger.kernel.org # 6.7+
Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com>
Signed-off-by: Song Liu <song(a)kernel.org>
Link: https://lore.kernel.org/r/20240104133629.1277517-1-lilingfeng@huaweicloud.c…
Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com>
---
drivers/md/md.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 29e105845772..31b275bad88c 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -9277,9 +9277,14 @@ static bool md_spares_need_change(struct mddev *mddev)
{
struct md_rdev *rdev;
- rdev_for_each(rdev, mddev)
- if (rdev_removeable(rdev) || rdev_addable(rdev))
+ rcu_read_lock();
+ rdev_for_each_rcu(rdev, mddev) {
+ if (rdev_removeable(rdev) || rdev_addable(rdev)) {
+ rcu_read_unlock();
return true;
+ }
+ }
+ rcu_read_unlock();
return false;
}
--
2.31.1
tree: https://gitee.com/openeuler/kernel.git OLK-5.10
head: 5faf5aae71283199f69c2a60ed91ab2847f3ffd8
commit: a2658f35fecf0534412a2b3125492fa90b253430 [16635/30000] net: enetc: manage ENETC_F_QBV in priv->active_offloads only when enabled
config: arm64-randconfig-002-20241024 (https://download.01.org/0day-ci/archive/20241024/202410241413.UxpYlVKk-lkp@…)
compiler: aarch64-linux-gcc (GCC) 14.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241024/202410241413.UxpYlVKk-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/202410241413.UxpYlVKk-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/net/ethernet/freescale/enetc/enetc_pf.c: In function 'enetc_pl_mac_link_up':
>> drivers/net/ethernet/freescale/enetc/enetc_pf.c:993:33: warning: variable 'priv' set but not used [-Wunused-but-set-variable]
993 | struct enetc_ndev_priv *priv;
| ^~~~
vim +/priv +993 drivers/net/ethernet/freescale/enetc/enetc_pf.c
d0a90192f86821 Vladimir Oltean 2021-03-27 986
71b77a7a27a338 Claudiu Manoil 2020-10-07 987 static void enetc_pl_mac_link_up(struct phylink_config *config,
71b77a7a27a338 Claudiu Manoil 2020-10-07 988 struct phy_device *phy, unsigned int mode,
71b77a7a27a338 Claudiu Manoil 2020-10-07 989 phy_interface_t interface, int speed,
71b77a7a27a338 Claudiu Manoil 2020-10-07 990 int duplex, bool tx_pause, bool rx_pause)
975d183ef0ca07 Michael Walle 2020-07-20 991 {
71b77a7a27a338 Claudiu Manoil 2020-10-07 992 struct enetc_pf *pf = phylink_to_enetc_pf(config);
71b77a7a27a338 Claudiu Manoil 2020-10-07 @993 struct enetc_ndev_priv *priv;
71b77a7a27a338 Claudiu Manoil 2020-10-07 994
71b77a7a27a338 Claudiu Manoil 2020-10-07 995 priv = netdev_priv(pf->si->ndev);
a2658f35fecf05 Vladimir Oltean 2022-05-10 996
a2658f35fecf05 Vladimir Oltean 2022-05-10 997 if (pf->si->hw_features & ENETC_SI_F_QBV)
71b77a7a27a338 Claudiu Manoil 2020-10-07 998 enetc_sched_speed_set(priv, speed);
975d183ef0ca07 Michael Walle 2020-07-20 999
d0a90192f86821 Vladimir Oltean 2021-03-27 1000 if (!phylink_autoneg_inband(mode) &&
d0a90192f86821 Vladimir Oltean 2021-03-27 1001 phy_interface_mode_is_rgmii(interface))
d0a90192f86821 Vladimir Oltean 2021-03-27 1002 enetc_force_rgmii_mac(&pf->si->hw, speed, duplex);
d0a90192f86821 Vladimir Oltean 2021-03-27 1003
71b77a7a27a338 Claudiu Manoil 2020-10-07 1004 enetc_mac_enable(&pf->si->hw, true);
975d183ef0ca07 Michael Walle 2020-07-20 1005 }
975d183ef0ca07 Michael Walle 2020-07-20 1006
:::::: The code at line 993 was first introduced by commit
:::::: 71b77a7a27a3388c97e754a2c4e282df3f568fd7 enetc: Migrate to PHYLINK and PCS_LYNX
:::::: TO: Claudiu Manoil <claudiu.manoil(a)nxp.com>
:::::: CC: Jakub Kicinski <kuba(a)kernel.org>
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Hi Mark,
FYI, the error/warning still remains.
tree: https://gitee.com/openeuler/kernel.git OLK-5.10
head: 5faf5aae71283199f69c2a60ed91ab2847f3ffd8
commit: 68da302c8ae30331c8917f1dc7b0f1682f696d71 [21492/30000] arm64/sve: Put system wide vector length information into structs
config: arm64-randconfig-003-20241024 (https://download.01.org/0day-ci/archive/20241024/202410241303.wTIeIXFm-lkp@…)
compiler: aarch64-linux-gcc (GCC) 14.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241024/202410241303.wTIeIXFm-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/202410241303.wTIeIXFm-lkp@intel.com/
All errors (new ones prefixed by >>):
arch/arm64/kvm/reset.c: In function 'kvm_arm_init_sve':
>> arch/arm64/kvm/reset.c:102:34: error: implicit declaration of function 'sve_max_virtualisable_vl' [-Werror=implicit-function-declaration]
102 | kvm_sve_max_vl = sve_max_virtualisable_vl();
| ^~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/sve_max_virtualisable_vl +102 arch/arm64/kvm/reset.c
98
99 int kvm_arm_init_sve(void)
100 {
101 if (system_supports_sve()) {
> 102 kvm_sve_max_vl = sve_max_virtualisable_vl();
103
104 /*
105 * The get_sve_reg()/set_sve_reg() ioctl interface will need
106 * to be extended with multiple register slice support in
107 * order to support vector lengths greater than
108 * SVE_VL_ARCH_MAX:
109 */
110 if (WARN_ON(kvm_sve_max_vl > SVE_VL_ARCH_MAX))
111 kvm_sve_max_vl = SVE_VL_ARCH_MAX;
112
113 /*
114 * Don't even try to make use of vector lengths that
115 * aren't available on all CPUs, for now:
116 */
117 if (kvm_sve_max_vl < sve_max_vl())
118 pr_warn("KVM: SVE vector length for guests limited to %u bytes\n",
119 kvm_sve_max_vl);
120 }
121
122 return 0;
123 }
124
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Hi Yabin,
FYI, the error/warning still remains.
tree: https://gitee.com/openeuler/kernel.git OLK-6.6
head: e7bc79687a034a22f94328123d5cf8c4d4436c35
commit: c74ae2c5da57becf3f41c596d79b3dd30fa1baa6 [13479/15255] hct: add mediated ccp driver support for hygon crypto technology.
config: x86_64-buildonly-randconfig-006-20241024 (https://download.01.org/0day-ci/archive/20241024/202410241021.mDLDP8B3-lkp@…)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241024/202410241021.mDLDP8B3-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/202410241021.mDLDP8B3-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/crypto/ccp/hygon/hct.c:1333:15: warning: no previous prototype for 'hct_pin_memory' [-Wmissing-prototypes]
1333 | struct page **hct_pin_memory(struct hct_private *private, unsigned long uaddr,
| ^~~~~~~~~~~~~~
drivers/crypto/ccp/hygon/hct.c: In function 'hct_get_page':
>> drivers/crypto/ccp/hygon/hct.c:1730:51: error: 'struct device' has no member named 'numa_node'
1730 | *node = hct_data.iommu[page_idx].pdev->dev.numa_node;
| ^
vim +1730 drivers/crypto/ccp/hygon/hct.c
1713
1714 static struct page *hct_get_page(pgoff_t page_idx)
1715 {
1716 u64 *node;
1717
1718 mutex_lock(&hct_share.lock);
1719 if (!hct_share.pages[page_idx]) {
1720 hct_share.pages[page_idx] =
1721 alloc_pages(GFP_HIGHUSER | __GFP_ZERO, 0);
1722 if (!hct_share.pages[page_idx]) {
1723 mutex_unlock(&hct_share.lock);
1724 return NULL;
1725 }
1726 }
1727 get_page(hct_share.pages[page_idx]);
1728
1729 node = page_to_virt(hct_share.pages[page_idx]) + PAGE_SIZE - 8;
> 1730 *node = hct_data.iommu[page_idx].pdev->dev.numa_node;
1731 mutex_unlock(&hct_share.lock);
1732
1733 return hct_share.pages[page_idx];
1734 }
1735
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
From: Waiman Long <longman(a)redhat.com>
stable inclusion
from stable-v4.19.322
commit 6760357063f593a17613e015aed2051cfd4197c6
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/IAYN0Z
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id…
--------------------------------
[ Upstream commit 57b56d16800e8961278ecff0dc755d46c4575092 ]
The writing of css->cgroup associated with the cgroup root in
rebind_subsystems() is currently protected only by cgroup_mutex.
However, the reading of css->cgroup in both proc_cpuset_show() and
proc_cgroup_show() is protected just by css_set_lock. That makes the
readers susceptible to racing problems like data tearing or caching.
It is also a problem that can be reported by KCSAN.
This can be fixed by using READ_ONCE() and WRITE_ONCE() to access
css->cgroup. Alternatively, the writing of css->cgroup can be moved
under css_set_lock as well which is done by this patch.
Signed-off-by: Waiman Long <longman(a)redhat.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
Signed-off-by: Chen Ridong <chenridong(a)huawei.com>
---
kernel/cgroup/cgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 1339b93f7054..7b3c1491cc88 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -1717,9 +1717,9 @@ int rebind_subsystems(struct cgroup_root *dst_root, u16 ss_mask)
RCU_INIT_POINTER(scgrp->subsys[ssid], NULL);
rcu_assign_pointer(dcgrp->subsys[ssid], css);
ss->root = dst_root;
- css->cgroup = dcgrp;
spin_lock_irq(&css_set_lock);
+ css->cgroup = dcgrp;
WARN_ON(!list_empty(&dcgrp->e_csets[ss->id]));
list_for_each_entry_safe(cset, cset_pos, &scgrp->e_csets[ss->id],
e_cset_node[ss->id]) {
--
2.34.1