September 2025 - Linux-stable-mirror

by Greg Kroah-Hartman

I'm announcing the release of the 6.16.7 kernel. All users of the 6.16 kernel series must upgrade. The updated 6.16.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-6.16.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h ------------ Documentation/ABI/testing/sysfs-devices-system-cpu | 1 Documentation/admin-guide/hw-vuln/index.rst | 1 Documentation/admin-guide/hw-vuln/vmscape.rst | 110 ++++++++ Documentation/admin-guide/kernel-parameters.txt | 11 Makefile | 2 arch/x86/Kconfig | 9 arch/x86/include/asm/cpufeatures.h | 2 arch/x86/include/asm/entry-common.h | 7 arch/x86/include/asm/nospec-branch.h | 2 arch/x86/kernel/cpu/bugs.c | 285 ++++++++++++++------- arch/x86/kernel/cpu/common.c | 86 ++++-- arch/x86/kvm/x86.c | 9 drivers/base/cpu.c | 3 include/linux/cpu.h | 1 14 files changed, 415 insertions(+), 114 deletions(-) Greg Kroah-Hartman (1): Linux 6.16.7 Pawan Gupta (7): Documentation/hw-vuln: Add VMSCAPE documentation x86/vmscape: Enumerate VMSCAPE bug x86/vmscape: Add conditional IBPB mitigation x86/vmscape: Enable the mitigation x86/bugs: Move cpu_bugs_smt_update() down x86/vmscape: Warn when STIBP is disabled with SMT x86/vmscape: Add old Intel CPUs to affected list

1 week, 3 days

1
1
0 0

Linux 6.12.47

by Greg Kroah-Hartman

I'm announcing the release of the 6.12.47 kernel. All users of the 6.12 kernel series must upgrade. The updated 6.12.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-6.12.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h ------------ Documentation/ABI/testing/sysfs-devices-system-cpu | 1 Documentation/admin-guide/hw-vuln/index.rst | 1 Documentation/admin-guide/hw-vuln/vmscape.rst | 110 ++++++++ Documentation/admin-guide/kernel-parameters.txt | 11 Makefile | 2 arch/x86/Kconfig | 9 arch/x86/include/asm/cpufeatures.h | 2 arch/x86/include/asm/entry-common.h | 7 arch/x86/include/asm/nospec-branch.h | 2 arch/x86/kernel/cpu/bugs.c | 257 ++++++++++++++------- arch/x86/kernel/cpu/common.c | 84 ++++-- arch/x86/kvm/x86.c | 9 drivers/base/cpu.c | 3 include/linux/cpu.h | 1 14 files changed, 394 insertions(+), 105 deletions(-) Greg Kroah-Hartman (1): Linux 6.12.47 Pawan Gupta (7): Documentation/hw-vuln: Add VMSCAPE documentation x86/vmscape: Enumerate VMSCAPE bug x86/vmscape: Add conditional IBPB mitigation x86/vmscape: Enable the mitigation x86/bugs: Move cpu_bugs_smt_update() down x86/vmscape: Warn when STIBP is disabled with SMT x86/vmscape: Add old Intel CPUs to affected list

1 week, 3 days

1
1
0 0

Linux 6.6.106

by Greg Kroah-Hartman

I'm announcing the release of the 6.6.106 kernel. All users of the 6.6 kernel series must upgrade. The updated 6.6.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-6.6.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h ------------ Documentation/ABI/testing/sysfs-devices-system-cpu | 1 Documentation/admin-guide/hw-vuln/index.rst | 1 Documentation/admin-guide/hw-vuln/vmscape.rst | 110 ++++++++ Documentation/admin-guide/kernel-parameters.txt | 11 Makefile | 2 arch/x86/Kconfig | 9 arch/x86/include/asm/cpufeatures.h | 2 arch/x86/include/asm/entry-common.h | 7 arch/x86/include/asm/nospec-branch.h | 2 arch/x86/kernel/cpu/bugs.c | 257 ++++++++++++++------- arch/x86/kernel/cpu/common.c | 82 ++++-- arch/x86/kvm/x86.c | 9 drivers/base/cpu.c | 3 include/linux/cpu.h | 1 14 files changed, 392 insertions(+), 105 deletions(-) Greg Kroah-Hartman (1): Linux 6.6.106 Pawan Gupta (7): Documentation/hw-vuln: Add VMSCAPE documentation x86/vmscape: Enumerate VMSCAPE bug x86/vmscape: Add conditional IBPB mitigation x86/vmscape: Enable the mitigation x86/bugs: Move cpu_bugs_smt_update() down x86/vmscape: Warn when STIBP is disabled with SMT x86/vmscape: Add old Intel CPUs to affected list

1 week, 3 days

1
1
0 0

Linux 6.1.152

by Greg Kroah-Hartman

I'm announcing the release of the 6.1.152 kernel. All users of the 6.1 kernel series must upgrade. The updated 6.1.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-6.1.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h ------------ Documentation/ABI/testing/sysfs-devices-system-cpu | 1 Documentation/admin-guide/hw-vuln/index.rst | 1 Documentation/admin-guide/hw-vuln/vmscape.rst | 110 ++++++++ Documentation/admin-guide/kernel-parameters.txt | 11 Makefile | 2 arch/x86/Kconfig | 9 arch/x86/include/asm/cpufeatures.h | 2 arch/x86/include/asm/entry-common.h | 7 arch/x86/include/asm/nospec-branch.h | 2 arch/x86/kernel/cpu/bugs.c | 257 ++++++++++++++------- arch/x86/kernel/cpu/common.c | 80 ++++-- arch/x86/kvm/x86.c | 9 drivers/base/cpu.c | 7 include/linux/cpu.h | 1 14 files changed, 394 insertions(+), 105 deletions(-) Greg Kroah-Hartman (1): Linux 6.1.152 Pawan Gupta (7): Documentation/hw-vuln: Add VMSCAPE documentation x86/vmscape: Enumerate VMSCAPE bug x86/vmscape: Add conditional IBPB mitigation x86/vmscape: Enable the mitigation x86/bugs: Move cpu_bugs_smt_update() down x86/vmscape: Warn when STIBP is disabled with SMT x86/vmscape: Add old Intel CPUs to affected list

1 week, 3 days

1
1
0 0

Linux 5.15.193

by Greg Kroah-Hartman

I'm announcing the release of the 5.15.193 kernel. All users of the 5.15 kernel series must upgrade. The updated 5.15.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.15.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h ------------ Documentation/ABI/testing/sysfs-devices-system-cpu | 1 Documentation/admin-guide/hw-vuln/index.rst | 1 Documentation/admin-guide/hw-vuln/vmscape.rst | 110 ++++++++ Documentation/admin-guide/kernel-parameters.txt | 11 Makefile | 2 arch/x86/Kconfig | 9 arch/x86/include/asm/cpufeatures.h | 2 arch/x86/include/asm/entry-common.h | 7 arch/x86/include/asm/nospec-branch.h | 2 arch/x86/kernel/cpu/bugs.c | 264 ++++++++++++++------- arch/x86/kernel/cpu/common.c | 77 +++--- arch/x86/kvm/x86.c | 9 drivers/base/cpu.c | 6 include/linux/cpu.h | 1 14 files changed, 393 insertions(+), 109 deletions(-) Greg Kroah-Hartman (1): Linux 5.15.193 Pawan Gupta (7): Documentation/hw-vuln: Add VMSCAPE documentation x86/vmscape: Enumerate VMSCAPE bug x86/vmscape: Add conditional IBPB mitigation x86/vmscape: Enable the mitigation x86/bugs: Move cpu_bugs_smt_update() down x86/vmscape: Warn when STIBP is disabled with SMT x86/vmscape: Add old Intel CPUs to affected list

1 week, 3 days

1
1
0 0

Linux 5.10.244

by Greg Kroah-Hartman

I'm announcing the release of the 5.10.244 kernel. All users of the 5.10 kernel series must upgrade. The updated 5.10.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.10.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h ------------ Documentation/ABI/testing/sysfs-devices-system-cpu | 1 Documentation/admin-guide/hw-vuln/index.rst | 1 Documentation/admin-guide/hw-vuln/vmscape.rst | 110 ++++++++ Documentation/admin-guide/kernel-parameters.txt | 11 Makefile | 2 arch/x86/Kconfig | 9 arch/x86/include/asm/cpufeatures.h | 2 arch/x86/include/asm/entry-common.h | 7 arch/x86/include/asm/nospec-branch.h | 2 arch/x86/kernel/cpu/bugs.c | 264 ++++++++++++++------- arch/x86/kernel/cpu/common.c | 74 +++-- arch/x86/kvm/x86.c | 9 drivers/base/cpu.c | 6 include/linux/cpu.h | 1 14 files changed, 390 insertions(+), 109 deletions(-) Greg Kroah-Hartman (1): Linux 5.10.244 Pawan Gupta (7): Documentation/hw-vuln: Add VMSCAPE documentation x86/vmscape: Enumerate VMSCAPE bug x86/vmscape: Add conditional IBPB mitigation x86/vmscape: Enable the mitigation x86/bugs: Move cpu_bugs_smt_update() down x86/vmscape: Warn when STIBP is disabled with SMT x86/vmscape: Add old Intel CPUs to affected list

1 week, 3 days

1
1
0 0

[PATCH] sched/core: Fix potential deadlock on rq lock

by Wang Tao

When CPU 1 enters the nohz_full state, and the kworker on CPU 0 executes the function sched_tick_remote, holding the lock on CPU1's rq and triggering the warning WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 3). This leads to the process of printing the warning message, where the console_sem semaphore is held. At this point, the print task on the CPU1's rq cannot acquire the console_sem and joins the wait queue, entering the UNINTERRUPTIBLE state. It waits for the console_sem to be released and then wakes up. After the task on CPU 0 releases the console_sem, it wakes up the waiting console_sem task. In try_to_wake_up, it attempts to acquire the lock on CPU1's rq again, resulting in a deadlock. The triggering scenario is as follows: CPU0 CPU1 sched_tick_remote WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 3) report_bug con_write printk console_unlock do_con_write console_lock down(&console_sem) list_add_tail(&waiter.list, &sem->wait_list); up(&console_sem) wake_up_q(&wake_q) try_to_wake_up __task_rq_lock _raw_spin_lock This patch fixes the issue by deffering all printk console printing during the lock holding period. Fixes: d84b31313ef8 ("sched/isolation: Offload residual 1Hz scheduler tick") Signed-off-by: Wang Tao <wangtao554(a)huawei.com> --- kernel/sched/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index be00629f0ba4..8b2d5b5bfb93 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5723,8 +5723,10 @@ static void sched_tick_remote(struct work_struct *work) * Make sure the next tick runs within a * reasonable amount of time. */ + printk_deferred_enter(); u64 delta = rq_clock_task(rq) - curr->se.exec_start; WARN_ON_ONCE(delta > (u64)NSEC_PER_SEC * 3); + printk_deferred_exit(); } curr->sched_class->task_tick(rq, curr, 0); -- 2.34.1

1 week, 3 days

4
4
0 0

[PATCH v2] mtd: core: always verify OOB offset in mtd_check_oob_ops()

by Gabor Juhos

Using an OOB offset past end of the available OOB data is invalid, irregardless of whether the 'ooblen' is set in the ops or not. Move the relevant check out from the if statement to always verify that. The 'oobtest' module executes four tests to verify how reading/writing OOB data past end of the devices is handled. It expects errors in case of these tests, but this expectation fails in the last two tests on MTD devices, which have no OOB bytes available. This is indicated in the test output like the following: [ 212.059416] mtd_oobtest: attempting to write past end of device [ 212.060379] mtd_oobtest: an error is expected... [ 212.066353] mtd_oobtest: error: wrote past end of device [ 212.071142] mtd_oobtest: attempting to read past end of device [ 212.076507] mtd_oobtest: an error is expected... [ 212.082080] mtd_oobtest: error: read past end of device ... [ 212.330508] mtd_oobtest: finished with 2 errors For reference, here is the corresponding code from the oobtest module: /* Attempt to write off end of device */ ops.mode = MTD_OPS_AUTO_OOB; ops.len = 0; ops.retlen = 0; ops.ooblen = mtd->oobavail; ops.oobretlen = 0; ops.ooboffs = 1; ops.datbuf = NULL; ops.oobbuf = writebuf; pr_info("attempting to write past end of device\n"); pr_info("an error is expected...\n"); err = mtd_write_oob(mtd, mtd->size - mtd->writesize, &ops); if (err) { pr_info("error occurred as expected\n"); } else { pr_err("error: wrote past end of device\n"); errcnt += 1; } As it can be seen, the code sets 'ooboffs' to 1, and 'ooblen' to mtd->oobavail which is zero in our case. Since the mtd_check_oob_ops() function only verifies 'ooboffs' if 'ooblen' is not zero, the 'ooboffs' value does not gets validated and the function returns success whereas it should fail. After the change, the oobtest module will bail out early with an error if there are no OOB bytes available on the MDT device under test: # cat /sys/class/mtd/mtd0/oobavail 0 # insmod mtd_test; insmod mtd_oobtest dev=0 [ 943.606228] [ 943.606259] ================================================= [ 943.606784] mtd_oobtest: MTD device: 0 [ 943.612660] mtd_oobtest: MTD device size 524288, eraseblock size 131072, page size 2048, count of eraseblocks 4, pages per eraseblock 64, OOB size 128 [ 943.616091] mtd_test: scanning for bad eraseblocks [ 943.629571] mtd_test: scanned 4 eraseblocks, 0 are bad [ 943.634313] mtd_oobtest: test 1 of 5 [ 943.653402] mtd_oobtest: writing OOBs of whole device [ 943.653424] mtd_oobtest: error: writeoob failed at 0x0 [ 943.657419] mtd_oobtest: error: use_len 0, use_offset 0 [ 943.662493] mtd_oobtest: error -22 occurred [ 943.667574] ================================================= This behaviour is more accurate than the current one where most tests are indicating successful writing of OOB data even that in fact nothing gets written into the device, which is quite misleading. Cc: stable(a)vger.kernel.org Fixes: 5cdd929da53d ("mtd: Add sanity checks in mtd_write/read_oob()") Reviewed-by: Daniel Golle <daniel(a)makrotopia.org> Signed-off-by: Gabor Juhos <j4g8y7(a)gmail.com> --- Changes in v2: - add Reviewed-by tag from Daniel - add stable and Fixes tags - Link to v1: https://lore.kernel.org/r/20250831-mtd-validate-ooboffs-v1-1-d3fdce7a8698@g… --- drivers/mtd/mtdcore.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c index 5ba9a741f5ac3c297ae21329c2827baf5dc471f0..9a3c9f163219bcb9fde66839f228fd8d38310f2d 100644 --- a/drivers/mtd/mtdcore.c +++ b/drivers/mtd/mtdcore.c @@ -1590,12 +1590,12 @@ static int mtd_check_oob_ops(struct mtd_info *mtd, loff_t offs, if (offs < 0 || offs + ops->len > mtd->size) return -EINVAL; + if (ops->ooboffs >= mtd_oobavail(mtd, ops)) + return -EINVAL; + if (ops->ooblen) { size_t maxooblen; - if (ops->ooboffs >= mtd_oobavail(mtd, ops)) - return -EINVAL; - maxooblen = ((size_t)(mtd_div_by_ws(mtd->size, mtd) - mtd_div_by_ws(offs, mtd)) * mtd_oobavail(mtd, ops)) - ops->ooboffs; --- base-commit: 1b237f190eb3d36f52dffe07a40b5eb210280e00 change-id: 20250831-mtd-validate-ooboffs-e35c796540fe Best regards, -- Gabor Juhos <j4g8y7(a)gmail.com>

1 week, 3 days

4
8
0 0

[PATCH] pinctrl: renesas: rzg2l: Fix ISEL restore on resume

by Claudiu

From: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> Commit 1d2da79708cb ("pinctrl: renesas: rzg2l: Avoid configuring ISEL in gpio_irq_{en,dis}able*()") dropped the configuration of ISEL from rzg2l_gpio_irq_enable()/rzg2l_gpio_irq_disable() and moved it to rzg2l_gpio_child_to_parent_hwirq()/rzg2l_gpio_irq_domain_free() to fix spurious IRQs. The resume code used rzg2l_gpio_irq_enable() (called from rzg2l_gpio_irq_restore()) to reconfigure the wakeup interrupts. Some drivers (e.g. Ethernet) may also reconfigure interrupts in their own code, eventually calling rzg2l_gpio_irq_enable(), when these are not wakeup interrupts. After commit 1d2da79708cb ("pinctrl: renesas: rzg2l: Avoid configuring ISEL in gpio_irq_{en,dis}able*()"), ISEL was no longer configured properly after resume. Fix this by adding rzg2l_gpio_irq_endisable() back into rzg2l_gpio_irq_enable(), and by using its unlocked variant in rzg2l_gpio_irq_restore(). Having IRQs enable in rzg2l_gpio_irq_enable() should be safe with respect to spurious IRQs, as in the probe case IRQs are enabled anyway in rzg2l_gpio_child_to_parent_hwirq(). No spurious IRQs were detected on suspend/resume tests (executed on RZ/G3S). Fixes: 1d2da79708cb ("pinctrl: renesas: rzg2l: Avoid configuring ISEL in gpio_irq_{en,dis}able*(") Cc: stable(a)vger.kernel.org Signed-off-by: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> --- drivers/pinctrl/renesas/pinctrl-rzg2l.c | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/drivers/pinctrl/renesas/pinctrl-rzg2l.c b/drivers/pinctrl/renesas/pinctrl-rzg2l.c index b182b3b8a542..6ae1ee3ffc81 100644 --- a/drivers/pinctrl/renesas/pinctrl-rzg2l.c +++ b/drivers/pinctrl/renesas/pinctrl-rzg2l.c @@ -2428,7 +2428,7 @@ static int rzg2l_gpio_get_gpioint(unsigned int virq, struct rzg2l_pinctrl *pctrl } static void rzg2l_gpio_irq_endisable(struct rzg2l_pinctrl *pctrl, - unsigned int hwirq, bool enable) + unsigned int hwirq, bool enable, bool lock) { const struct pinctrl_pin_desc *pin_desc = &pctrl->desc.pins[hwirq]; u64 *pin_data = pin_desc->drv_data; @@ -2443,12 +2443,16 @@ static void rzg2l_gpio_irq_endisable(struct rzg2l_pinctrl *pctrl, addr += 4; } - spin_lock_irqsave(&pctrl->lock, flags); + if (lock) + spin_lock_irqsave(&pctrl->lock, flags); + if (enable) writel(readl(addr) | BIT(bit * 8), addr); else writel(readl(addr) & ~BIT(bit * 8), addr); - spin_unlock_irqrestore(&pctrl->lock, flags); + + if (lock) + spin_unlock_irqrestore(&pctrl->lock, flags); } static void rzg2l_gpio_irq_disable(struct irq_data *d) @@ -2460,15 +2464,22 @@ static void rzg2l_gpio_irq_disable(struct irq_data *d) gpiochip_disable_irq(gc, hwirq); } -static void rzg2l_gpio_irq_enable(struct irq_data *d) +static void rzg2l_gpio_irq_enable_helper(struct irq_data *d, bool lock) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + struct rzg2l_pinctrl *pctrl = container_of(gc, struct rzg2l_pinctrl, gpio_chip); unsigned int hwirq = irqd_to_hwirq(d); gpiochip_enable_irq(gc, hwirq); + rzg2l_gpio_irq_endisable(pctrl, hwirq, true, lock); irq_chip_enable_parent(d); } +static void rzg2l_gpio_irq_enable(struct irq_data *d) +{ + rzg2l_gpio_irq_enable_helper(d, true); +} + static int rzg2l_gpio_irq_set_type(struct irq_data *d, unsigned int type) { return irq_chip_set_type_parent(d, type); @@ -2570,7 +2581,7 @@ static int rzg2l_gpio_child_to_parent_hwirq(struct gpio_chip *gc, goto err; } - rzg2l_gpio_irq_endisable(pctrl, child, true); + rzg2l_gpio_irq_endisable(pctrl, child, true, true); pctrl->hwirq[irq] = child; irq += pctrl->data->hwcfg->tint_start_index; @@ -2617,7 +2628,7 @@ static void rzg2l_gpio_irq_restore(struct rzg2l_pinctrl *pctrl) spin_lock_irqsave(&pctrl->lock, flags); ret = rzg2l_gpio_irq_set_type(data, irqd_get_trigger_type(data)); if (!ret && !irqd_irq_disabled(data)) - rzg2l_gpio_irq_enable(data); + rzg2l_gpio_irq_enable_helper(data, false); spin_unlock_irqrestore(&pctrl->lock, flags); if (ret) @@ -2640,7 +2651,7 @@ static void rzg2l_gpio_irq_domain_free(struct irq_domain *domain, unsigned int v for (i = 0; i < RZG2L_TINT_MAX_INTERRUPT; i++) { if (pctrl->hwirq[i] == hwirq) { - rzg2l_gpio_irq_endisable(pctrl, hwirq, false); + rzg2l_gpio_irq_endisable(pctrl, hwirq, false, true); rzg2l_gpio_free(gc, hwirq); spin_lock_irqsave(&pctrl->bitmap_lock, flags); bitmap_release_region(pctrl->tint_slot, i, get_order(1)); -- 2.43.0

1 week, 3 days

4
6
0 0

Vendor / Contractor Registration Request 2025/2026

by Etihad Aviation Group PJSC

-- Attn: Sir/Madam, We are interested in your services and invite your company to register for Vendor/Contractor Partnership with Etihad Aviation Group for our 2025/2026 projects. If you wish to participate, please confirm your interest, and we will send the Vendor Questionnaire and EOI. Thank you. Kind Regards, Engr, Tami Hassan, Vendor Procurement & Contracts Shared Services Center Etihad Aviation Group PJSC

1 week, 3 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2025