- Linux-stable-mirror - lists.linaro.org

[PATCH 5.10 v3 0/3] Backport fix for CVE-2023-53103

by Alexey Panov

Changes in v3: - Fixed patch numbering (previously sent as 2/3 instead of 3/3) Changes in v2: - Added a new patch fixing bonding regression, based on the Fixes tag in c484fcc058ba ("bonding: Fix memory leak when changing bond type to Ethernet") - Added a cover letter - No changes in patches 1 and 3 - Retested the reproducer [1] Tested with the syzkaller reproducer [1]. The issue triggers on vanilla v5.10.y and no longer reproduces with these patches applied. Additionally, c484fcc058ba ("bonding: Fix memory leak when changing bond type to Ethernet") has a Fixes tag pointing to 9ec7eb60dcbc ("bonding: restore IFF_MASTER/SLAVE flags on bond enslave ether type change"), so it should be ported as well. [1]: https://syzkaller.appspot.com/bug?extid=9dfc3f3348729cc82277 Ido Schimmel (1): bonding: Fix memory leak when changing bond type to Ethernet Nikolay Aleksandrov (2): bonding: restore IFF_MASTER/SLAVE flags on bond enslave ether type change bonding: restore bond's IFF_SLAVE flag if a non-eth dev enslave fails drivers/net/bonding/bond_main.c | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-) -- 2.39.5

1 week, 3 days

1
3
0 0

[PATCH 5.10 v2 0/3] Backport fix for CVE-2023-53103

by Alexey Panov

Changes in v2: - Added a new patch fixing bonding regression, based on the Fixes tag in c484fcc058ba ("bonding: Fix memory leak when changing bond type to Ethernet") - Added a cover letter - No changes in patches 1 and 3 - Retested the reproducer [1] Tested with the syzkaller reproducer [1]. The issue triggers on vanilla v5.10.y and no longer reproduces with these patches applied. Additionally, c484fcc058ba ("bonding: Fix memory leak when changing bond type to Ethernet") has a Fixes tag pointing to 9ec7eb60dcbc ("bonding: restore IFF_MASTER/SLAVE flags on bond enslave ether type change"), so it should be ported as well. [1]: https://syzkaller.appspot.com/bug?extid=9dfc3f3348729cc82277 Ido Schimmel (1): bonding: Fix memory leak when changing bond type to Ethernet Nikolay Aleksandrov (2): bonding: restore IFF_MASTER/SLAVE flags on bond enslave ether type change bonding: restore bond's IFF_SLAVE flag if a non-eth dev enslave fails drivers/net/bonding/bond_main.c | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-) -- 2.39.5

1 week, 3 days

1
3
0 0

[PATCH] gpio: loongson: Switch 2K2000/3000 GPIO to BYTE_CTRL_MODE

by Xi Ruoyao

The manuals of 2K2000 says both BIT_CTRL_MODE and BYTE_CTRL_MODE are supported but the latter is recommended. Also on 2K3000, per the ACPI DSDT the GPIO controller is compatible with 2K2000, but it fails to operate GPIOs 62 and 63 (and maybe others) using BIT_CTRL_MODE. Using BYTE_CTRL_MODE also makes those 2K3000 GPIOs work. Fixes: 3feb70a61740 ("gpio: loongson: add more gpio chip support") Cc: stable(a)vger.kernel.org Signed-off-by: Xi Ruoyao <xry111(a)xry111.site> --- drivers/gpio/gpio-loongson-64bit.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpio/gpio-loongson-64bit.c b/drivers/gpio/gpio-loongson-64bit.c index 02f181cb219e..82d4c3aa4d2f 100644 --- a/drivers/gpio/gpio-loongson-64bit.c +++ b/drivers/gpio/gpio-loongson-64bit.c @@ -407,11 +407,11 @@ static const struct loongson_gpio_chip_data loongson_gpio_ls2k2000_data0 = { static const struct loongson_gpio_chip_data loongson_gpio_ls2k2000_data1 = { .label = "ls2k2000_gpio", - .mode = BIT_CTRL_MODE, - .conf_offset = 0x0, - .in_offset = 0x20, - .out_offset = 0x10, - .inten_offset = 0x30, + .mode = BYTE_CTRL_MODE, + .conf_offset = 0x800, + .in_offset = 0xa00, + .out_offset = 0x900, + .inten_offset = 0xb00, }; static const struct loongson_gpio_chip_data loongson_gpio_ls2k2000_data2 = { -- 2.52.0

1 week, 3 days

3
2
0 0

[PATCH 2/4] PCI: Rewrite bridge window head alignment function

by Ilpo Järvinen

The calculation of bridge window head alignment is done by calculate_mem_align() [*]. With the default bridge window alignment, it is used for both head and tail alignment. The selected head alignment does not always result in tight-fitting resources (gap at d4f00000-d4ffffff): d4800000-dbffffff : PCI Bus 0000:06 d4800000-d48fffff : PCI Bus 0000:07 d4800000-d4803fff : 0000:07:00.0 d4800000-d4803fff : nvme d4900000-d49fffff : PCI Bus 0000:0a d4900000-d490ffff : 0000:0a:00.0 d4900000-d490ffff : r8169 d4910000-d4913fff : 0000:0a:00.0 d4a00000-d4cfffff : PCI Bus 0000:0b d4a00000-d4bfffff : 0000:0b:00.0 d4a00000-d4bfffff : 0000:0b:00.0 d4c00000-d4c07fff : 0000:0b:00.0 d4d00000-d4dfffff : PCI Bus 0000:15 d4d00000-d4d07fff : 0000:15:00.0 d4d00000-d4d07fff : xhci-hcd d4e00000-d4efffff : PCI Bus 0000:16 d4e00000-d4e7ffff : 0000:16:00.0 d4e80000-d4e803ff : 0000:16:00.0 d4e80000-d4e803ff : ahci d5000000-dbffffff : PCI Bus 0000:0c This has not been caused problems (for years) with the default bridge window tail alignment that grossly over-estimates the required tail alignment leaving more tail room than necessary. With the introduction of relaxed tail alignment that leaves no extra tail room whatsoever, any gaps will immediately turn into assignment failures. Introduce head alignment calculation that ensures no gaps are left and apply the new approach when using relaxed alignment. ([*] I don't understand the algorithm in calculate_mem_align().) Fixes: 5d0a8965aea9 ("[PATCH] 2.5.14: New PCI allocation code (alpha, arm, parisc) [2/2]") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220775 Reported-by: Malte Schröder <malte+lkml(a)tnxip.de> Tested-by: Malte Schröder <malte+lkml(a)tnxip.de> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- Little annoyingly, there's difference in what aligns array contains between the legacy alignment approach (which I dare not to touch as I really don't understand what the algorithm tries to do) and this new head aligment algorithm, both consuming stack space. After making the new approach the only available approach in the follow-up patch, only one array remains (however, that follow-up change is also somewhat riskier when it comes to regressions). That being said, the new head alignment could work with the same aligns array as the legacy approach, it just won't necessarily produce an optimal (the smallest possible) head alignment when if (r_size <= align) condition is used. Just let me know if that approach is preferred (to save some stack space). --- drivers/pci/setup-bus.c | 53 ++++++++++++++++++++++++++++++++++------- 1 file changed, 44 insertions(+), 9 deletions(-) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 70d021ffb486..93f6b0750174 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -1224,6 +1224,45 @@ static inline resource_size_t calculate_mem_align(resource_size_t *aligns, return min_align; } +/* + * Calculate bridge window head alignment that leaves no gaps in between + * resources. + */ +static resource_size_t calculate_head_align(resource_size_t *aligns, + int max_order) +{ + resource_size_t head_align = 1; + resource_size_t remainder = 0; + int order; + + /* Take the largest alignment as the starting point. */ + head_align <<= max_order + __ffs(SZ_1M); + + for (order = max_order - 1; order >= 0; order--) { + resource_size_t align1 = 1; + + align1 <<= order + __ffs(SZ_1M); + + /* + * Account smaller resources with alignment < max_order that + * could be used to fill head room if alignment less than + * max_order is used. + */ + remainder += aligns[order]; + + /* + * Test if head fill is enough to satisfy the alignment of + * the larger resources after reducing the alignment. + */ + while ((head_align > align1) && (remainder >= head_align / 2)) { + head_align /= 2; + remainder -= head_align; + } + } + + return head_align; +} + /** * pbus_upstream_space_available - Check no upstream resource limits allocation * @bus: The bus @@ -1311,13 +1350,13 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, { struct pci_dev *dev; resource_size_t min_align, win_align, align, size, size0, size1 = 0; - resource_size_t aligns[28]; /* Alignments from 1MB to 128TB */ + resource_size_t aligns[28] = {}; /* Alignments from 1MB to 128TB */ + resource_size_t aligns2[28] = {};/* Alignments from 1MB to 128TB */ int order, max_order; struct resource *b_res = pbus_select_window_for_type(bus, type); resource_size_t children_add_size = 0; resource_size_t children_add_align = 0; resource_size_t add_align = 0; - resource_size_t relaxed_align; resource_size_t old_size; if (!b_res) @@ -1327,7 +1366,6 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, if (b_res->parent) return; - memset(aligns, 0, sizeof(aligns)); max_order = 0; size = 0; @@ -1378,6 +1416,7 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, */ if (r_size <= align) aligns[order] += align; + aligns2[order] += align; if (order > max_order) max_order = order; @@ -1402,9 +1441,7 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, if (bus->self && size0 && !pbus_upstream_space_available(bus, b_res, size0, min_align)) { - relaxed_align = 1ULL << (max_order + __ffs(SZ_1M)); - relaxed_align = max(relaxed_align, win_align); - min_align = min(min_align, relaxed_align); + min_align = calculate_head_align(aligns2, max_order); size0 = calculate_memsize(size, min_size, 0, 0, old_size, win_align); resource_set_range(b_res, min_align, size0); pci_info(bus->self, "bridge window %pR to %pR requires relaxed alignment rules\n", @@ -1418,9 +1455,7 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, if (bus->self && size1 && !pbus_upstream_space_available(bus, b_res, size1, add_align)) { - relaxed_align = 1ULL << (max_order + __ffs(SZ_1M)); - relaxed_align = max(relaxed_align, win_align); - min_align = min(min_align, relaxed_align); + min_align = calculate_head_align(aligns2, max_order); size1 = calculate_memsize(size, min_size, add_size, children_add_size, old_size, win_align); pci_info(bus->self, -- 2.39.5

1 week, 3 days

1
0
0 0

[PATCH 1/4] PCI: Fix bridge window alignment with optional resources

by Ilpo Järvinen

pbus_size_mem() has two alignments, one for required resources in min_align and another in add_align that takes account optional resources. The add_align is applied to the bridge window through the realloc_head list. It can happen, however, that add_align is larger than min_align but calculated size1 and size0 are equal due to extra tailroom (e.g., hotplug reservation, tail alignment), and therefore no entry is created to the realloc_head list. Without the bridge appearing in the realloc head, add_align is lost when pbus_size_mem() returns. The problem is visible in this log for 0000:05:00.0 which lacks add_size ... add_align ... line that would indicate it was added into the realloc_head list: pci 0000:05:00.0: PCI bridge to [bus 06-16] ... pci 0000:06:00.0: bridge window [mem 0x00100000-0x001fffff] to [bus 07] requires relaxed alignment rules pci 0000:06:06.0: bridge window [mem 0x00100000-0x001fffff] to [bus 0a] requires relaxed alignment rules pci 0000:06:07.0: bridge window [mem 0x00100000-0x003fffff] to [bus 0b] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x00800000-0x00ffffff 64bit pref] to [bus 0c-14] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] add_size 100000 add_align 1000000 pci 0000:06:0c.0: bridge window [mem 0x00100000-0x001fffff] to [bus 15] requires relaxed alignment rules pci 0000:06:0d.0: bridge window [mem 0x00100000-0x001fffff] to [bus 16] requires relaxed alignment rules pci 0000:06:0d.0: bridge window [mem 0x00100000-0x001fffff] to [bus 16] requires relaxed alignment rules pci 0000:05:00.0: bridge window [mem 0xd4800000-0xd97fffff]: assigned pci 0000:05:00.0: bridge window [mem 0x1060000000-0x10607fffff 64bit pref]: assigned pci 0000:06:08.0: bridge window [mem size 0x04900000]: can't assign; no space pci 0000:06:08.0: bridge window [mem size 0x04900000]: failed to assign While this bug itself seems old, it has likely become more visible after the relaxed tail alignment that does not grossly overestimate the size needed for the bridge window. Make sure add_align > min_align too results in adding an entry into the realloc head list. In addition, add handling to the cases where add_size is zero while only alignment differs. Fixes: d74b9027a4da ("PCI: Consider additional PF's IOV BAR alignment in sizing and assigning") Reported-by: Malte Schröder <malte+lkml(a)tnxip.de> Tested-by: Malte Schröder <malte+lkml(a)tnxip.de> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- drivers/pci/setup-bus.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 4a8735b275e4..70d021ffb486 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -14,6 +14,7 @@ * tighter packing. Prefetchable range support. */ +#include <linux/align.h> #include <linux/bitops.h> #include <linux/init.h> #include <linux/kernel.h> @@ -452,7 +453,7 @@ static void reassign_resources_sorted(struct list_head *realloc_head, "%s %pR: ignoring failure in optional allocation\n", res_name, res); } - } else if (add_size > 0) { + } else if (add_size > 0 || !IS_ALIGNED(res->start, align)) { res->flags |= add_res->flags & (IORESOURCE_STARTALIGN|IORESOURCE_SIZEALIGN); if (pci_reassign_resource(dev, idx, add_size, align)) @@ -1438,12 +1439,13 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, resource_set_range(b_res, min_align, size0); b_res->flags |= IORESOURCE_STARTALIGN; - if (bus->self && size1 > size0 && realloc_head) { + if (bus->self && realloc_head && (size1 > size0 || add_align > min_align)) { b_res->flags &= ~IORESOURCE_DISABLED; - add_to_list(realloc_head, bus->self, b_res, size1-size0, add_align); + add_size = size1 > size0 ? size1 - size0 : 0; + add_to_list(realloc_head, bus->self, b_res, add_size, add_align); pci_info(bus->self, "bridge window %pR to %pR add_size %llx add_align %llx\n", b_res, &bus->busn_res, - (unsigned long long) (size1 - size0), + (unsigned long long) add_size, (unsigned long long) add_align); } } -- 2.39.5

1 week, 3 days

1
0
0 0

[PATCH v1 2/2] powerpc/pseries/cmm: adjust BALLOON_MIGRATE when migrating pages

by David Hildenbrand

Let's properly adjust BALLOON_MIGRATE like the other drivers. Note that the INFLATE/DEFLATE events are triggered from the core when enqueueing/dequeueing pages. Not completely sure whether really is stable material, but the fix is trivial so let's just CC stable. This was found by code inspection. Fixes: fe030c9b85e6 ("powerpc/pseries/cmm: Implement balloon compaction") Cc: <stable(a)vger.kernel.org> Signed-off-by: David Hildenbrand <david(a)redhat.com> --- arch/powerpc/platforms/pseries/cmm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/pseries/cmm.c b/arch/powerpc/platforms/pseries/cmm.c index 688f5fa1c7245..310dab4bc8679 100644 --- a/arch/powerpc/platforms/pseries/cmm.c +++ b/arch/powerpc/platforms/pseries/cmm.c @@ -532,6 +532,7 @@ static int cmm_migratepage(struct balloon_dev_info *b_dev_info, spin_lock_irqsave(&b_dev_info->pages_lock, flags); balloon_page_insert(b_dev_info, newpage); + __count_vm_event(BALLOON_MIGRATE); b_dev_info->isolated_pages--; spin_unlock_irqrestore(&b_dev_info->pages_lock, flags); -- 2.51.0

1 week, 3 days

2
1
0 0

[PATCH 6.6 0/2] Backport 2 commits to 6.12.y to fix bond issue

by Rajani Kantha

Backport commit: 094ee6017ea0 ("bonding: check xdp prog when set bond mode") to 6.6.y to fix a bond issue. It depends on commit: 22ccb684c1ca ("bonding: return detailed error when loading native XDP fails) In order to make a clean backport on stable kernel, backport 2 commits. Hangbin Liu (1): bonding: return detailed error when loading native XDP fails Wang Liang (1): bonding: check xdp prog when set bond mode drivers/net/bonding/bond_main.c | 11 +++++++---- drivers/net/bonding/bond_options.c | 3 +++ include/net/bonding.h | 1 + 3 files changed, 11 insertions(+), 4 deletions(-) -- 2.17.1

1 week, 3 days

1
2
0 0

[PATCH v1 1/2] powerpc/pseries/cmm: call balloon_devinfo_init() also without CONFIG_BALLOON_COMPACTION

by David Hildenbrand

We always have to initialize the balloon_dev_info, even when compaction is not configured in: otherwise the containing list and the lock are left uninitialized. Likely not many such configs exist in practice, but let's CC stable to be sure. This was found by code inspection. Fixes: fe030c9b85e6 ("powerpc/pseries/cmm: Implement balloon compaction") Cc: <stable(a)vger.kernel.org> Signed-off-by: David Hildenbrand <david(a)redhat.com> --- arch/powerpc/platforms/pseries/cmm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/pseries/cmm.c b/arch/powerpc/platforms/pseries/cmm.c index 0823fa2da1516..688f5fa1c7245 100644 --- a/arch/powerpc/platforms/pseries/cmm.c +++ b/arch/powerpc/platforms/pseries/cmm.c @@ -550,7 +550,6 @@ static int cmm_migratepage(struct balloon_dev_info *b_dev_info, static void cmm_balloon_compaction_init(void) { - balloon_devinfo_init(&b_dev_info); b_dev_info.migratepage = cmm_migratepage; } #else /* CONFIG_BALLOON_COMPACTION */ @@ -572,6 +571,7 @@ static int cmm_init(void) if (!firmware_has_feature(FW_FEATURE_CMO) && !simulate) return -EOPNOTSUPP; + balloon_devinfo_init(&b_dev_info); cmm_balloon_compaction_init(); rc = register_oom_notifier(&cmm_oom_nb); -- 2.51.0

1 week, 3 days

2
1
0 0

[PATCH 6.6.y] net: macb: fix unregister_netdev call order in macb_remove()

by alvalan9＠foxmail.com

From: luoguangfei <15388634752(a)163.com> [ Upstream commit 01b9128c5db1b470575d07b05b67ffa3cb02ebf1 ] When removing a macb device, the driver calls phy_exit() before unregister_netdev(). This leads to a WARN from kernfs: ------------[ cut here ]------------ kernfs: can not remove 'attached_dev', no directory WARNING: CPU: 1 PID: 27146 at fs/kernfs/dir.c:1683 Call trace: kernfs_remove_by_name_ns+0xd8/0xf0 sysfs_remove_link+0x24/0x58 phy_detach+0x5c/0x168 phy_disconnect+0x4c/0x70 phylink_disconnect_phy+0x6c/0xc0 [phylink] macb_close+0x6c/0x170 [macb] ... macb_remove+0x60/0x168 [macb] platform_remove+0x5c/0x80 ... The warning happens because the PHY is being exited while the netdev is still registered. The correct order is to unregister the netdev before shutting down the PHY and cleaning up the MDIO bus. Fix this by moving unregister_netdev() ahead of phy_exit() in macb_remove(). Fixes: 8b73fa3ae02b ("net: macb: Added ZynqMP-specific initialization") Signed-off-by: luoguangfei <15388634752(a)163.com> Link: https://patch.msgid.link/20250818232527.1316-1-15388634752@163.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> [ Minor context change fixed. ] Signed-off-by: Alva Lan <alvalan9(a)foxmail.com> --- drivers/net/ethernet/cadence/macb_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c index 7593255e6e53..bf7b5d1d5616 100644 --- a/drivers/net/ethernet/cadence/macb_main.c +++ b/drivers/net/ethernet/cadence/macb_main.c @@ -5182,11 +5182,11 @@ static int macb_remove(struct platform_device *pdev) if (dev) { bp = netdev_priv(dev); + unregister_netdev(dev); phy_exit(bp->sgmii_phy); mdiobus_unregister(bp->mii_bus); mdiobus_free(bp->mii_bus); - unregister_netdev(dev); tasklet_kill(&bp->hresp_err_tasklet); pm_runtime_disable(&pdev->dev); pm_runtime_dont_use_autosuspend(&pdev->dev); -- 2.43.0

1 week, 3 days

1
0
0 0

TOTAL (RFQ_062573)

by Thomas Pierre

Good day, I am reaching out to invite your company to provide a quotation for the products detailed in the attached request. We recognise that some of these items may not align with your usual supplies, but we expect your expertise in sourcing and supplying these products. Please note that this is a one-time tender, and we require the product and its components delivered on or before the date specified in the attached document. We anticipate your prompt response to enable us to proceed to the next step. Thank you and looking forward to reviewing your proposal soonest. Thomas Pierre Procurement Manager Phone: +1-713-564-2377 fax: +1-713-969-7350 Email: totalenergiesbids(a)contractor.net Note: This message, including any attachments, is intended solely for the use of the individual or entity to whom it is addressed and may contain confidential, proprietary, or legally privileged information. Any unauthorized review, use, disclosure, distribution, reproduction, or any form of dissemination of this communication is strictly prohibited.If you are not the intended recipient, please notify the sender immediately, delete this message from your system, and do not retain, copy, or distribute it.Please note that any views or opinions expressed in this communication are those of the sender and do not necessarily reflect the official views or policies of the company. "Please consider the environment before printing this email."

1 week, 3 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror