February 2025 - Linux-stable-mirror

[PATCH v2] usb: dwc3: Fix timeout issue during controller enter/exit from halt state

by Selvarasu Ganesan

There is a frequent timeout during controller enter/exit from halt state after toggling the run_stop bit by SW. This timeout occurs when performing frequent role switches between host and device, causing device enumeration issues due to the timeout. This issue was not present when USB2 suspend PHY was disabled by passing the SNPS quirks (snps,dis_u2_susphy_quirk and snps,dis_enblslpm_quirk) from the DTS. However, there is a requirement to enable USB2 suspend PHY by setting of GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY bits when controller starts in gadget or host mode results in the timeout issue. This commit addresses this timeout issue by ensuring that the bits GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY are cleared before starting the dwc3_gadget_run_stop sequence and restoring them after the dwc3_gadget_run_stop sequence is completed. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: stable(a)vger.kernel.org Signed-off-by: Selvarasu Ganesan <selvarasu.g(a)samsung.com> --- Changes in v2: - Added some comments before the changes. - And removed "unlikely" in the condition check. - Link to v1: https://lore.kernel.org/linux-usb/20250131110832.438-1-selvarasu.g@samsung.… --- drivers/usb/dwc3/gadget.c | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index d27af65eb08a..ddd6b2ce5710 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -2629,10 +2629,38 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on) { u32 reg; u32 timeout = 2000; + u32 saved_config = 0; if (pm_runtime_suspended(dwc->dev)) return 0; + /* + * When operating in USB 2.0 speeds (HS/FS), ensure that + * GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY are cleared before starting + * or stopping the controller. This resolves timeout issues that occur + * during frequent role switches between host and device modes. + * + * Save and clear these settings, then restore them after completing the + * controller start or stop sequence. + * + * This solution was discovered through experimentation as it is not + * mentioned in the dwc3 programming guide. It has been tested on an + * Exynos platforms. + */ + reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); + if (reg & DWC3_GUSB2PHYCFG_SUSPHY) { + saved_config |= DWC3_GUSB2PHYCFG_SUSPHY; + reg &= ~DWC3_GUSB2PHYCFG_SUSPHY; + } + + if (reg & DWC3_GUSB2PHYCFG_ENBLSLPM) { + saved_config |= DWC3_GUSB2PHYCFG_ENBLSLPM; + reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM; + } + + if (saved_config) + dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); + reg = dwc3_readl(dwc->regs, DWC3_DCTL); if (is_on) { if (DWC3_VER_IS_WITHIN(DWC3, ANY, 187A)) { @@ -2660,6 +2688,12 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on) reg &= DWC3_DSTS_DEVCTRLHLT; } while (--timeout && !(!is_on ^ !reg)); + if (saved_config) { + reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)); + reg |= saved_config; + dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); + } + if (!timeout) return -ETIMEDOUT; -- 2.17.1

10 months, 2 weeks

2
1
0 0

[PATCH] jiffies: Cast to unsigned long for secs_to_jiffies() conversion

by Easwar Hariharan

While converting users of msecs_to_jiffies(), lkp reported that some range checks would always be true because of the mismatch between the implied int value of secs_to_jiffies() vs the unsigned long return value of the msecs_to_jiffies() calls it was replacing. Fix this by casting secs_to_jiffies() values as unsigned long. Fixes: b35108a51cf7ba ("jiffies: Define secs_to_jiffies()") CC: stable(a)vger.kernel.org # 6.12+ CC: Andrew Morton <akpm(a)linux-foundation.org> Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501301334.NB6NszQR-lkp@intel.com/ Signed-off-by: Easwar Hariharan <eahariha(a)linux.microsoft.com> --- include/linux/jiffies.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h index ed945f42e064..0ea8c9887429 100644 --- a/include/linux/jiffies.h +++ b/include/linux/jiffies.h @@ -537,7 +537,7 @@ static __always_inline unsigned long msecs_to_jiffies(const unsigned int m) * * Return: jiffies value */ -#define secs_to_jiffies(_secs) ((_secs) * HZ) +#define secs_to_jiffies(_secs) (unsigned long)((_secs) * HZ) extern unsigned long __usecs_to_jiffies(const unsigned int u); #if !(USEC_PER_SEC % HZ) -- 2.43.0

10 months, 2 weeks

4
7
0 0

[PATCH v1] pwm: microchip-core: fix incorrect comparison with max period

by Conor Dooley

From: Conor Dooley <conor.dooley(a)microchip.com> In mchp_core_pwm_apply_locked(), if hw_period_steps is equal to its max, an error is reported and .apply fails. The max value is actually a permitted value however, and so this check can fail where multiple channels are enabled. For example, the first channel to be configured requests a period that sets hw_period_steps to the maximum value, and when a second channel is enabled the driver reads hw_period_steps back from the hardware and finds it to be the maximum possible value, triggering the warning on a permitted value. The value to be avoided is 255 (PERIOD_STEPS_MAX + 1), as that will produce undesired behaviour, so test for greater than, rather than equal to. Fixes: 2bf7ecf7b4ff ("pwm: add microchip soft ip corePWM driver") CC: stable(a)vger.kernel.org Signed-off-by: Conor Dooley <conor.dooley(a)microchip.com> --- CC: Conor Dooley <conor.dooley(a)microchip.com> CC: Daire McNamara <daire.mcnamara(a)microchip.com> CC: Uwe Kleine-König <ukleinek(a)kernel.org> CC: Thierry Reding <thierry.reding(a)gmail.com> CC: linux-riscv(a)lists.infradead.org CC: linux-pwm(a)vger.kernel.org CC: linux-kernel(a)vger.kernel.org --- drivers/pwm/pwm-microchip-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pwm/pwm-microchip-core.c b/drivers/pwm/pwm-microchip-core.c index c1f2287b8e97..12821b4bbf97 100644 --- a/drivers/pwm/pwm-microchip-core.c +++ b/drivers/pwm/pwm-microchip-core.c @@ -327,7 +327,7 @@ static int mchp_core_pwm_apply_locked(struct pwm_chip *chip, struct pwm_device * * mchp_core_pwm_calc_period(). * The period is locked and we cannot change this, so we abort. */ - if (hw_period_steps == MCHPCOREPWM_PERIOD_STEPS_MAX) + if (hw_period_steps > MCHPCOREPWM_PERIOD_STEPS_MAX) return -EINVAL; prescale = hw_prescale; -- 2.45.2

10 months, 2 weeks

3
2
0 0

Re: [Fix CVE-2024-50217 in v6.6.y] [PATCH] btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()

by Greg KH

On Mon, Feb 03, 2025 at 06:45:55PM +0000, Shubham Pushpkar -X (spushpka - E INFOCHIPS PRIVATE LIMITED at Cisco) wrote: > Thank you, Greg, for your feedback and for highlighting the importance > of thorough testing. I apologize for any oversight in my previous > submission. I will ensure that all future patches are rigorously > tested before submission. Again, they must be tested AND have a second signed-off-by from someone else in your company when you resend them as proof of this testing by both of you. thanks, greg k-h

10 months, 2 weeks

1
0
0 0

stable/linux-6.13.y: new boot regression: WARNING at lib/refcount.c:25 refcount_warn_saturate+0xc8...

by KernelCI bot

Hello, New boot regression found on stable/linux-6.13.y: WARNING at lib/refcount.c:25 refcount_warn_saturate+0xc8/0x148 [logspec:generic_linux_boot,linux.kernel.warning] - Dashboard: https://staging.dashboard.kernelci.org:9000/issue/maestro:9027cb3b2181d813a… - Grafana: https://grafana.kernelci.org/d/issue/issue?var-id=maestro:9027cb3b2181d813a… Log excerpt: [ 4.653252] refcount_t: addition on 0; use-after-free. [ 4.653261] WARNING: CPU: 5 PID: 187 at lib/refcount.c:25 refcount_warn_saturate+0xc8/0x148 [ 4.653271] Modules linked in: v4l2_mem2mem pcie_mediatek_gen3(+) mt6359_auxadc mtk_rpmsg joydev videobuf2_dma_contig rpmsg_core elan_i2c lvts_thermal(+) mt6577_auxadc snd_soc_mt8195_afe(+) mtk_svs mtk_scp_ipi snd_sof_utils mtk_wdt btusb btintel btbcm btmtk btrtl uvcvideo videobuf2_vmalloc uvc videobuf2_v4l2 mt8195_mt6359 bluetooth ecdh_generic videobuf2_memops ecc videobuf2_common [ 4.653293] CPU: 5 UID: 0 PID: 187 Comm: (udev-worker) Not tainted 6.13.0 #1 c0bd9fe43a50105c5d4fe2d8da4d493a3771f650 [ 4.653296] Hardware name: Acer Tomato (rev2) board (DT) [ 4.653297] pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.653298] pc : refcount_warn_saturate+0xc8/0x148 [ 4.653301] lr : refcount_warn_saturate+0xc8/0x148 [ 4.653303] sp : ffff800080c23620 [ 4.653304] x29: ffff800080c23620 x28: ffffda629c274b18 x27: 0000000000000001 [ 4.653306] x26: ffff800080c23930 x25: ffffda62d3588f10 x24: ffff07808558e7f8 [ 4.653308] x23: 0000000000000000 x22: ffff078081075478 x21: ffff800080c236a8 [ 4.653309] x20: 0000000000000000 x19: ffff078081074078 x18: 00000000ffffffff [ 4.653311] x17: 00000000ffffb060 x16: ffffda62d111f5f8 x15: 612d35393138746d [ 4.653313] x14: ffffda62d37fd750 x13: 0a2e656572662d72 x12: ffffda62d3551950 [ 4.653315] x11: 0000000000000001 x10: 0000000000000001 x9 : ffffda62d0943280 [ 4.653316] x8 : c0000000ffffdfff x7 : ffffda62d34a18b0 x6 : 00000000000affa8 [ 4.653318] x5 : ffffda62d35518f8 x4 : 0000000000000000 x3 : 00000000ffffffff [ 4.653320] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff078088140000 [ 4.653322] Call trace: [ 4.653323] refcount_warn_saturate+0xc8/0x148 (P) [ 4.653326] klist_next+0x180/0x1a8 [ 4.653329] bus_for_each_dev+0x6c/0xe8 [ 4.653334] driver_attach+0x2c/0x40 [ 4.653336] bus_add_driver+0xec/0x218 [ 4.653337] driver_register+0x68/0x138 [ 4.653339] __platform_driver_register+0x2c/0x40 [ 4.653341] mt8195_afe_pcm_driver_init+0x28/0xff8 [snd_soc_mt8195_afe 41f903257dcc6a1560bfbd0ddb4cf7a5b6deb9f1] [ 4.653350] do_one_initcall+0x60/0x320 [ 4.653354] do_init_module+0x68/0x258 [ 4.653357] load_module+0x1cf8/0x1de8 [ 4.653359] init_module_from_file+0x8c/0xd8 [ 4.653361] __arm64_sys_finit_module+0x150/0x338 [ 4.653363] invoke_syscall+0x70/0x100 [ 4.653367] el0_svc_common.constprop.0+0x48/0xf0 [ 4.653370] do_el0_svc+0x24/0x38 [ 4.653372] el0_svc+0x34/0xf0 [ 4.653375] el0t_64_sync_handler+0x10c/0x138 [ 4.653377] el0t_64_sync+0x1b0/0x1b8 # Hardware platforms affected: ## mt8195-cherry-tomato-r2 - Compatibles: google,tomato-rev2 | google,tomato | mediatek,mt8195 - Dashboard: https://staging.dashboard.kernelci.org:9000/test/maestro:67a0b86a661a7bc874… #kernelci issue maestro:9027cb3b2181d813ac566c16982a6748748d7ae7 -- This is an experimental report format. Please send feedback in! Talk to us at kerneci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

10 months, 2 weeks

1
0
0 0

[Fix CVE-2024-50217 in v6.6.y] [PATCH] btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()

by Shubham Pushpkar

From: Zhihao Cheng <chengzhihao1(a)huawei.com> commit aec8e6bf839101784f3ef037dcdb9432c3f32343 ("btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()") Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 → loop0 fs_device \ btrfs_device_2 → loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) // btrfs_device_1->bdev_file is freed btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device(). Fixes: CVE-2024-50217 Fixes: 142388194191 ("btrfs: do not background blkdev_put()") CC: stable(a)vger.kernel.org # 4.19+ Link: https://bugzilla.kernel.org/show_bug.cgi?id=219408 Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> (cherry picked from commit aec8e6bf839101784f3ef037dcdb9432c3f32343) Signed-off-by: Shubham Pushpkar <spushpka(a)cisco.com> --- fs/btrfs/volumes.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index b9a0b26d08e1..ab2412542ce5 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -1176,6 +1176,7 @@ static void btrfs_close_one_device(struct btrfs_device *device) if (device->bdev) { fs_devices->open_devices--; device->bdev = NULL; + device->bdev_file = NULL; } clear_bit(BTRFS_DEV_STATE_WRITEABLE, &device->dev_state); btrfs_destroy_dev_zone_info(device); -- 2.35.6

10 months, 2 weeks

3
2
0 0

[Fix CVE-2024-50217 in v6.6.y] [PATCH] btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()

by Shubham Pushpkar

From: Zhihao Cheng <chengzhihao1(a)huawei.com> commit aec8e6bf839101784f3ef037dcdb9432c3f32343 ("btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()") Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 → loop0 fs_device \ btrfs_device_2 → loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) // btrfs_device_1->bdev_file is freed btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device(). Fixes: 142388194191 ("btrfs: do not background blkdev_put()") CC: stable(a)vger.kernel.org # 4.19+ Link: https://bugzilla.kernel.org/show_bug.cgi?id=219408 Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> (cherry picked from commit aec8e6bf839101784f3ef037dcdb9432c3f32343) Signed-off-by: Shubham Pushpkar <spushpka(a)cisco.com> --- fs/btrfs/volumes.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index b9a0b26d08e1..ab2412542ce5 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -1176,6 +1176,7 @@ static void btrfs_close_one_device(struct btrfs_device *device) if (device->bdev) { fs_devices->open_devices--; device->bdev = NULL; + device->bdev_file = NULL; } clear_bit(BTRFS_DEV_STATE_WRITEABLE, &device->dev_state); btrfs_destroy_dev_zone_info(device); -- 2.35.6

10 months, 2 weeks

3
2
0 0

[PATCH V2] usb: gadget: udc: renesas_usb3: Fix compiler warning

by guoren＠kernel.org

From: Guo Ren <guoren(a)linux.alibaba.com> drivers/usb/gadget/udc/renesas_usb3.c: In function 'renesas_usb3_probe': drivers/usb/gadget/udc/renesas_usb3.c:2638:73: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size 6 [-Wformat-truncation=] 2638 | snprintf(usb3_ep->ep_name, sizeof(usb3_ep->ep_name), "ep%d", i); ^~~~~~~~~~~~~~~~~~~~~~~~ ^~ ^ Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller") Cc: stable(a)vger.kernel.org Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501201409.BIQPtkeB-lkp@intel.com/ Signed-off-by: Guo Ren <guoren(a)linux.alibaba.com> Signed-off-by: Guo Ren <guoren(a)kernel.org> --- drivers/usb/gadget/udc/renesas_usb3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/renesas_usb3.c b/drivers/usb/gadget/udc/renesas_usb3.c index fce5c41d9f29..89b304cf6d03 100644 --- a/drivers/usb/gadget/udc/renesas_usb3.c +++ b/drivers/usb/gadget/udc/renesas_usb3.c @@ -310,7 +310,7 @@ struct renesas_usb3_request { struct list_head queue; }; -#define USB3_EP_NAME_SIZE 8 +#define USB3_EP_NAME_SIZE 16 struct renesas_usb3_ep { struct usb_ep ep; struct renesas_usb3 *usb3; -- 2.40.1

10 months, 2 weeks

2
2
0 0

[PATCH] usb: xhci: Restore Renesas uPD72020x support in xhci-pci

by nb＠tipi-net.de

From: Nicolai Buchwitz <nb(a)tipi-net.de> Before commit 25f51b76f90f1 ("xhci-pci: Make xhci-pci-renesas a proper modular driver"), the xhci-pci driver handled the Renesas uPD72020x USB3 PHY and only utilized features of xhci-pci-renesas when no external firmware EEPROM was attached. This allowed devices with a valid firmware stored in EEPROM to function without requiring xhci-pci-renesas. That commit changed the behavior, making xhci-pci-renesas responsible for handling these devices entirely, even when firmware was already present in EEPROM. As a result, unnecessary warnings about missing firmware files appeared, and more critically, USB functionality broke whens CONFIG_USB_XHCI_PCI_RENESAS was not enabled—despite previously workings without it. Fix this by ensuring that devices are only handed over to xhci-pci-renesas if the config option is enabled. Otherwise, restore the original behavior and handle them as standard xhci-pci devices. Signed-off-by: Nicolai Buchwitz <nb(a)tipi-net.de> Fixes: 25f51b76f90f ("xhci-pci: Make xhci-pci-renesas a proper modular driver") --- drivers/usb/host/xhci-pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 2d1e205c14c60..4ce80d8ac603e 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -654,9 +654,11 @@ int xhci_pci_common_probe(struct pci_dev *dev, const struct pci_device_id *id) EXPORT_SYMBOL_NS_GPL(xhci_pci_common_probe, "xhci"); static const struct pci_device_id pci_ids_reject[] = { +#if IS_ENABLED(CONFIG_USB_XHCI_PCI_RENESAS) /* handled by xhci-pci-renesas */ { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, 0x0014) }, { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, 0x0015) }, +#endif { /* end: all zeroes */ } }; -- 2.39.5

10 months, 2 weeks

3
4
0 0

[PATCH 6.1] efivars: Fix "BUG: corrupted list in efivar_entry_remove"

by Alexey Nepomnyashih

Prevent list corruption in efivar_entry_remove() and efivar_entry_list_del_unlock() by verifying that an entry is still in the list (list_empty() == false) before calling list_del(). Also reset the list pointers with INIT_LIST_HEAD() to avoid potential double-removal issues. Ensure robust handling of entries and prevent the kernel BUG observed when list_del() was called on an already-removed entry. Fix https://syzkaller.appspot.com/bug?extid=246ea4feed277471958a Syzkaller report: list_del corruption. prev->next should be ffff0000d86d6828, but was ffff800016216e60. (prev=ffff800016216e60) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:61! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 4299 Comm: syz-executor237 Not tainted 6.1.119-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __list_del_entry_valid+0x13c/0x158 lib/list_debug.c:59 lr : __list_del_entry_valid+0x13c/0x158 lib/list_debug.c:59 Call trace: __list_del_entry_valid+0x13c/0x158 lib/list_debug.c:59 __list_del_entry include/linux/list.h:134 [inline] list_del include/linux/list.h:148 [inline] efivar_entry_remove+0x38/0x110 fs/efivarfs/vars.c:493 efivarfs_destroy+0x20/0x3c fs/efivarfs/super.c:184 efivar_entry_iter+0x94/0xdc fs/efivarfs/vars.c:720 efivarfs_kill_sb+0x58/0x70 fs/efivarfs/super.c:258 deactivate_locked_super+0xac/0x124 fs/super.c:332 deactivate_super+0xf0/0x110 fs/super.c:363 cleanup_mnt+0x394/0x41c fs/namespace.c:1186 __cleanup_mnt+0x20/0x30 fs/namespace.c:1193 task_work_run+0x240/0x2f0 kernel/task_work.c:203 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] do_notify_resume+0x2080/0x2cb8 arch/arm64/kernel/signal.c:1132 prepare_exit_to_user_mode arch/arm64/kernel/entry-common.c:137 [inline] exit_to_user_mode arch/arm64/kernel/entry-common.c:142 [inline] el0_svc+0x9c/0x168 arch/arm64/kernel/entry-common.c:638 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655 el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:585 Reported-by: syzbot+75dc11...(a)syzkaller.appspotmail.com Fixes: 2d82e6227ea1 ("efi: vars: Move efivar caching layer into efivarfs") Cc: stable(a)vger.kernel.org Signed-off-by: Alexey Nepomnyashih <sdl(a)nppct.ru> --- fs/efivarfs/vars.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/fs/efivarfs/vars.c b/fs/efivarfs/vars.c index 13bc60698955..42977138e30b 100644 --- a/fs/efivarfs/vars.c +++ b/fs/efivarfs/vars.c @@ -490,7 +490,10 @@ void __efivar_entry_add(struct efivar_entry *entry, struct list_head *head) */ void efivar_entry_remove(struct efivar_entry *entry) { - list_del(&entry->list); + if (!list_empty(&entry->list)) { + list_del(&entry->list); + INIT_LIST_HEAD(&entry->list); + } } /* @@ -506,7 +509,10 @@ void efivar_entry_remove(struct efivar_entry *entry) */ static void efivar_entry_list_del_unlock(struct efivar_entry *entry) { - list_del(&entry->list); + if (!list_empty(&entry->list)) { + list_del(&entry->list); + INIT_LIST_HEAD(&entry->list); + } efivar_unlock(); } -- 2.43.0

10 months, 2 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2025