Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

264 participants
124084 discussions

[PATCH] net: usb: pegasus: fix memory leak on usb_submit_urb() failure

by Petko Manolov

In update_eth_regs_async() neither the URB nor the request structure are being freed if usb_submit_urb() fails. The patch fixes this long lurking bug in the error path. Signed-off-by: Petko Manolov <petko.manolov(a)konsulko.com> --- drivers/net/usb/pegasus.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c index 81ca64debc5b..7a70207e7364 100644 --- a/drivers/net/usb/pegasus.c +++ b/drivers/net/usb/pegasus.c @@ -168,6 +168,8 @@ static int update_eth_regs_async(pegasus_t *pegasus) netif_device_detach(pegasus->net); netif_err(pegasus, drv, pegasus->net, "%s returned %d\n", __func__, ret); + kfree(req); + usb_free_urb(async_urb); } return ret; } -- 2.52.0

2 days, 16 hours

Re: [PATCH v2] fbdev: bitblit: bound-check glyph index in bit_putcs*

by Vitaly Chikunov

Dear linux-fbdev, stable, On Mon, Oct 20, 2025 at 09:47:01PM +0800, Junjie Cao wrote: > bit_putcs_aligned()/unaligned() derived the glyph pointer from the > character value masked by 0xff/0x1ff, which may exceed the actual font's > glyph count and read past the end of the built-in font array. > Clamp the index to the actual glyph count before computing the address. > > This fixes a global out-of-bounds read reported by syzbot. > > Reported-by: syzbot+793cf822d213be1a74f2(a)syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2 > Tested-by: syzbot+793cf822d213be1a74f2(a)syzkaller.appspotmail.com > Signed-off-by: Junjie Cao <junjie.cao(a)intel.com> This commit is applied to v5.10.247 and causes a regression: when switching VT with ctrl-alt-f2 the screen is blank or completely filled with angle characters, then new text is not appearing (or not visible). This commit is found with git bisect from v5.10.246 to v5.10.247: 0998a6cb232674408a03e8561dc15aa266b2f53b is the first bad commit commit 0998a6cb232674408a03e8561dc15aa266b2f53b Author: Junjie Cao <junjie.cao(a)intel.com> AuthorDate: 2025-10-20 21:47:01 +0800 Commit: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> CommitDate: 2025-12-07 06:08:07 +0900 fbdev: bitblit: bound-check glyph index in bit_putcs* commit 18c4ef4e765a798b47980555ed665d78b71aeadf upstream. bit_putcs_aligned()/unaligned() derived the glyph pointer from the character value masked by 0xff/0x1ff, which may exceed the actual font's glyph count and read past the end of the built-in font array. Clamp the index to the actual glyph count before computing the address. This fixes a global out-of-bounds read reported by syzbot. Reported-by: syzbot+793cf822d213be1a74f2(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2 Tested-by: syzbot+793cf822d213be1a74f2(a)syzkaller.appspotmail.com Signed-off-by: Junjie Cao <junjie.cao(a)intel.com> Reviewed-by: Thomas Zimmermann <tzimmermann(a)suse.de> Signed-off-by: Helge Deller <deller(a)gmx.de> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> drivers/video/fbdev/core/bitblit.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) The minimal reproducer in cli, after kernel is booted: date >/dev/tty2; chvt 2 and the date does not appear. Thanks, #regzbot introduced: 0998a6cb232674408a03e8561dc15aa266b2f53b > --- > v1: https://lore.kernel.org/linux-fbdev/5d237d1a-a528-4205-a4d8-71709134f1e1@su… > v1 -> v2: > - Fix indentation and add blank line after declarations with the .pl helper > - No functional changes > > drivers/video/fbdev/core/bitblit.c | 16 ++++++++++++---- > 1 file changed, 12 insertions(+), 4 deletions(-) > > diff --git a/drivers/video/fbdev/core/bitblit.c b/drivers/video/fbdev/core/bitblit.c > index 9d2e59796c3e..085ffb44c51a 100644 > --- a/drivers/video/fbdev/core/bitblit.c > +++ b/drivers/video/fbdev/core/bitblit.c > @@ -79,12 +79,16 @@ static inline void bit_putcs_aligned(struct vc_data *vc, struct fb_info *info, > struct fb_image *image, u8 *buf, u8 *dst) > { > u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff; > + unsigned int charcnt = vc->vc_font.charcount; > u32 idx = vc->vc_font.width >> 3; > u8 *src; > > while (cnt--) { > - src = vc->vc_font.data + (scr_readw(s++)& > - charmask)*cellsize; > + u16 ch = scr_readw(s++) & charmask; > + > + if (ch >= charcnt) > + ch = 0; > + src = vc->vc_font.data + (unsigned int)ch * cellsize; > > if (attr) { > update_attr(buf, src, attr, vc); > @@ -112,14 +116,18 @@ static inline void bit_putcs_unaligned(struct vc_data *vc, > u8 *dst) > { > u16 charmask = vc->vc_hi_font_mask ? 0x1ff : 0xff; > + unsigned int charcnt = vc->vc_font.charcount; > u32 shift_low = 0, mod = vc->vc_font.width % 8; > u32 shift_high = 8; > u32 idx = vc->vc_font.width >> 3; > u8 *src; > > while (cnt--) { > - src = vc->vc_font.data + (scr_readw(s++)& > - charmask)*cellsize; > + u16 ch = scr_readw(s++) & charmask; > + > + if (ch >= charcnt) > + ch = 0; > + src = vc->vc_font.data + (unsigned int)ch * cellsize; > > if (attr) { > update_attr(buf, src, attr, vc); > -- > 2.48.1 >

2 days, 17 hours

[PATCH] pinctrl: meson: mark the GPIO controller as sleeping

by Bartosz Golaszewski

The GPIO controller is configured as non-sleeping but it uses generic pinctrl helpers which use a mutex for synchronization. This can cause the following lockdep splat with shared GPIOs enabled on boards which have multiple devices using the same GPIO: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 142, name: kworker/u25:3 preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. irq event stamp: 46379 hardirqs last enabled at (46379): [<ffff8000813acb24>] _raw_spin_unlock_irqrestore+0x74/0x78 hardirqs last disabled at (46378): [<ffff8000813abf38>] _raw_spin_lock_irqsave+0x84/0x88 softirqs last enabled at (46330): [<ffff8000800c71b4>] handle_softirqs+0x4c4/0x4dc softirqs last disabled at (46295): [<ffff800080010674>] __do_softirq+0x14/0x20 CPU: 1 UID: 0 PID: 142 Comm: kworker/u25:3 Tainted: G C 6.19.0-rc4-next-20260105+ #11963 PREEMPT Tainted: [C]=CRAP Hardware name: Khadas VIM3 (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x24 __might_resched+0x144/0x248 __might_sleep+0x48/0x98 __mutex_lock+0x5c/0x894 mutex_lock_nested+0x24/0x30 pinctrl_get_device_gpio_range+0x44/0x128 pinctrl_gpio_set_config+0x40/0xdc gpiochip_generic_config+0x28/0x3c gpio_do_set_config+0xa8/0x194 gpiod_set_config+0x34/0xfc gpio_shared_proxy_set_config+0x6c/0xfc [gpio_shared_proxy] gpio_do_set_config+0xa8/0x194 gpiod_set_transitory+0x4c/0xf0 gpiod_configure_flags+0xa4/0x480 gpiod_find_and_request+0x1a0/0x574 gpiod_get_index+0x58/0x84 devm_gpiod_get_index+0x20/0xb4 devm_gpiod_get+0x18/0x24 mmc_pwrseq_emmc_probe+0x40/0xb8 platform_probe+0x5c/0xac really_probe+0xbc/0x298 __driver_probe_device+0x78/0x12c driver_probe_device+0xdc/0x164 __device_attach_driver+0xb8/0x138 bus_for_each_drv+0x80/0xdc __device_attach+0xa8/0x1b0 Fixes: 6ac730951104 ("pinctrl: add driver for Amlogic Meson SoCs") Cc: stable(a)vger.kernel.org Reported-by: Marek Szyprowski <m.szyprowski(a)samsung.com> Closes: https://lore.kernel.org/all/00107523-7737-4b92-a785-14ce4e93b8cb@samsung.co… Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski(a)oss.qualcomm.com> --- drivers/pinctrl/meson/pinctrl-meson.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/meson/pinctrl-meson.c b/drivers/pinctrl/meson/pinctrl-meson.c index 18295b15ecd9..4507dc8b5563 100644 --- a/drivers/pinctrl/meson/pinctrl-meson.c +++ b/drivers/pinctrl/meson/pinctrl-meson.c @@ -619,7 +619,7 @@ static int meson_gpiolib_register(struct meson_pinctrl *pc) pc->chip.set = meson_gpio_set; pc->chip.base = -1; pc->chip.ngpio = pc->data->num_pins; - pc->chip.can_sleep = false; + pc->chip.can_sleep = true; ret = gpiochip_add_data(&pc->chip, pc); if (ret) { -- 2.47.3

2 days, 17 hours

[PATCH 2/2] drm: xlnx: zynqmp_kms: set preferred_depth to 16 bpp

by Mikko Rapeli

Xorg fails to start with defaults on AMD KV260, /var/log/Xorg.0.log: [ 23.491] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [ 23.491] (II) Module fbdev: vendor="X.Org Foundation" [ 23.491] compiled for 1.21.1.18, module version = 0.5.1 [ 23.491] Module class: X.Org Video Driver [ 23.491] ABI class: X.Org Video Driver, version 25.2 [ 23.491] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 23.491] (II) FBDEV: driver for framebuffer: fbdev [ 23.510] (II) modeset(0): using drv /dev/dri/card1 [ 23.511] (WW) Falling back to old probe method for fbdev [ 23.511] (II) Loading sub module "fbdevhw" [ 23.511] (II) LoadModule: "fbdevhw" [ 23.511] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [ 23.511] (II) Module fbdevhw: vendor="X.Org Foundation" [ 23.511] compiled for 1.21.1.18, module version = 0.0.2 [ 23.511] ABI class: X.Org Video Driver, version 25.2 [ 23.512] (II) modeset(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 23.512] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 23.512] (==) modeset(0): RGB weight 888 [ 23.512] (==) modeset(0): Default visual is TrueColor ... [ 23.911] (II) Loading sub module "fb" [ 23.911] (II) LoadModule: "fb" [ 23.911] (II) Module "fb" already built-in [ 23.911] (II) UnloadModule: "fbdev" [ 23.911] (II) Unloading fbdev [ 23.912] (II) UnloadSubModule: "fbdevhw" [ 23.912] (II) Unloading fbdevhw [ 24.238] (==) modeset(0): Backing store enabled [ 24.238] (==) modeset(0): Silken mouse enabled [ 24.249] (II) modeset(0): Initializing kms color map for depth 24, 8 bpc. [ 24.250] (==) modeset(0): DPMS enabled [ 24.250] (II) modeset(0): [DRI2] Setup complete [ 24.250] (II) modeset(0): [DRI2] DRI driver: kms_swrast [ 24.250] (II) modeset(0): [DRI2] VDPAU driver: kms_swrast ... [ 24.770] (II) modeset(0): Disabling kernel dirty updates, not required. [ 24.770] (EE) modeset(0): failed to set mode: Invalid argument xorg tries to use 24 and 32 bpp which pass on the fb API but which don't actually work on AMD KV260 when Xorg starts. As a workaround Xorg config can set color depth to 16 using /etc/X11/xorg.conf snippet: Section "Screen" Identifier "Default Screen" Monitor "Configured Monitor" Device "Configured Video Device" DefaultDepth 16 EndSection But this is cumbersome on images meant for multiple different arm64 devices and boards. So instead set 16 bpp as preferred depth in zynqmp_kms fb driver which is used by Xorg in the logic to find out a working depth. Now Xorg startup and bpp query using fb API works and HDMI display shows graphics. /var/log/Xorg.0.log shows: [ 23.219] (II) LoadModule: "fbdev" [ 23.219] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [ 23.219] (II) Module fbdev: vendor="X.Org Foundation" [ 23.219] compiled for 1.21.1.18, module version = 0.5.1 [ 23.219] Module class: X.Org Video Driver [ 23.219] ABI class: X.Org Video Driver, version 25.2 [ 23.219] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 23.219] (II) FBDEV: driver for framebuffer: fbdev [ 23.238] (II) modeset(0): using drv /dev/dri/card1 [ 23.238] (WW) Falling back to old probe method for fbdev [ 23.238] (II) Loading sub module "fbdevhw" [ 23.238] (II) LoadModule: "fbdevhw" [ 23.239] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [ 23.239] (II) Module fbdevhw: vendor="X.Org Foundation" [ 23.239] compiled for 1.21.1.18, module version = 0.0.2 [ 23.239] ABI class: X.Org Video Driver, version 25.2 [ 23.240] (II) modeset(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 16/16 [ 23.240] (==) modeset(0): Depth 16, (==) framebuffer bpp 16 [ 23.240] (==) modeset(0): RGB weight 565 [ 23.240] (==) modeset(0): Default visual is TrueColor ... [ 24.015] (==) modeset(0): Backing store enabled [ 24.015] (==) modeset(0): Silken mouse enabled [ 24.027] (II) modeset(0): Initializing kms color map for depth 16, 6 bpc. [ 24.028] (==) modeset(0): DPMS enabled [ 24.028] (II) modeset(0): [DRI2] Setup complete [ 24.028] (II) modeset(0): [DRI2] DRI driver: kms_swrast [ 24.028] (II) modeset(0): [DRI2] VDPAU driver: kms_swrast Cc: Bill Mills <bill.mills(a)linaro.org> Cc: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> Cc: Anatoliy Klymenko <anatoliy.klymenko(a)amd.com> Cc: stable(a)vger.kernel.org Signed-off-by: Mikko Rapeli <mikko.rapeli(a)linaro.org> --- drivers/gpu/drm/xlnx/zynqmp_kms.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c index ccc35cacd10cb..a42192c827af0 100644 --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c @@ -506,6 +506,7 @@ int zynqmp_dpsub_drm_init(struct zynqmp_dpsub *dpsub) drm->mode_config.min_height = 0; drm->mode_config.max_width = ZYNQMP_DISP_MAX_WIDTH; drm->mode_config.max_height = ZYNQMP_DISP_MAX_HEIGHT; + drm->mode_config.preferred_depth = 16; ret = drm_vblank_init(drm, 1); if (ret) -- 2.34.1

2 days, 18 hours

[PATCH 1/2] drm: xlnx: zynqmp_kms: Init fbdev with 16 bit color

by Mikko Rapeli

From: Anatoliy Klymenko <anatoliy.klymenko(a)amd.com> Use RG16 buffer format for fbdev emulation. Fbdev backend is being used by Mali 400 userspace driver which expects 16 bit RGB pixel color format. This change should not affect console or other fbdev applications as we still have plenty of colors left. Cc: Bill Mills <bill.mills(a)linaro.org> Cc: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> Cc: stable(a)vger.kernel.org Signed-off-by: Anatoliy Klymenko <anatoliy.klymenko(a)amd.com> Signed-off-by: Mikko Rapeli <mikko.rapeli(a)linaro.org> --- drivers/gpu/drm/xlnx/zynqmp_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c b/drivers/gpu/drm/xlnx/zynqmp_kms.c index 2bee0a2275ede..ccc35cacd10cb 100644 --- a/drivers/gpu/drm/xlnx/zynqmp_kms.c +++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c @@ -525,7 +525,7 @@ int zynqmp_dpsub_drm_init(struct zynqmp_dpsub *dpsub) goto err_poll_fini; /* Initialize fbdev generic emulation. */ - drm_client_setup_with_fourcc(drm, DRM_FORMAT_RGB888); + drm_client_setup_with_fourcc(drm, DRM_FORMAT_RGB565); return 0; -- 2.34.1

2 days, 18 hours

[PATCH 3/5] ceph: Free page array when ceph_submit_write fails

by Sam Edwards

If `locked_pages` is zero, the page array must not be allocated: ceph_process_folio_batch() uses `locked_pages` to decide when to allocate `pages`, and redundant allocations trigger ceph_allocate_page_array()'s BUG_ON(), resulting in a worker oops (and writeback stall) or even a kernel panic. Consequently, the main loop in ceph_writepages_start() assumes that the lifetime of `pages` is confined to a single iteration. The ceph_submit_write() function claims ownership of the page array on success. But failures only redirty/unlock the pages and fail to free the array, making the failure case in ceph_submit_write() fatal. Free the page array in ceph_submit_write()'s error-handling 'if' block so that the caller's invariant (that the array does not outlive the iteration) is maintained unconditionally, allowing failures in ceph_submit_write() to be recoverable as originally intended. Fixes: 1551ec61dc55 ("ceph: introduce ceph_submit_write() method") Cc: stable(a)vger.kernel.org Signed-off-by: Sam Edwards <CFSworks(a)gmail.com> --- fs/ceph/addr.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c index 2b722916fb9b..91cc43950162 100644 --- a/fs/ceph/addr.c +++ b/fs/ceph/addr.c @@ -1466,6 +1466,13 @@ int ceph_submit_write(struct address_space *mapping, unlock_page(page); } + if (ceph_wbc->from_pool) { + mempool_free(ceph_wbc->pages, ceph_wb_pagevec_pool); + ceph_wbc->from_pool = false; + } else + kfree(ceph_wbc->pages); + ceph_wbc->pages = NULL; + ceph_osdc_put_request(req); return -EIO; } -- 2.51.2

2 days, 19 hours

[PATCH] media: v4l2-flash: Enter LED off state after file handle closed

by cy_huang＠richtek.com

From: ChiYuan Huang <cy_huang(a)richtek.com> To make sure LED enter off state after file handle is closed, initiatively configure LED_MODE to NONE. This can guarantee whatever the previous state is torch or strobe mode, the final state will be off. Cc: stable(a)vger.kernel.org Fixes : 42bd6f59ae90 ("media: Add registration helpers for V4L2 flash sub-devices") Reported-by: Roger Wang <roger-hy.wang(a)mediatek.com> Signed-off-by: ChiYuan Huang <cy_huang(a)richtek.com> --- Hi, We encounter an issue. When the upper layer camera process is crashed, if the new process did not reinit the LED, it will keeps the previous state whatever it's in torch or strobe mode OS will handle the resource management. So when the process is crashed or terminated, the 'close' API will be called to release resources. That's why we add the initiative action to trigger LED off in file handle close is called. --- drivers/media/v4l2-core/v4l2-flash-led-class.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c b/drivers/media/v4l2-core/v4l2-flash-led-class.c index 355595a0fefa..347b37f3ef69 100644 --- a/drivers/media/v4l2-core/v4l2-flash-led-class.c +++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c @@ -623,6 +623,12 @@ static int v4l2_flash_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh) return 0; if (led_cdev) { + /* If file handle is released, make sure LED enter off state */ + ret = v4l2_ctrl_s_ctrl(v4l2_flash->ctrls[LED_MODE], + V4L2_FLASH_LED_MODE_NONE); + if (ret) + return ret; + mutex_lock(&led_cdev->led_access); if (v4l2_flash->ctrls[STROBE_SOURCE]) -- 2.34.1

2 days, 20 hours

Action Needed: Mailbox Quota Exceeded – Manage Emails Now

by Urgent!!

2 days, 20 hours

FAILED: patch "[PATCH] vfio/pci: Disable qword access to the PCI ROM bar" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x dc85a46928c41423ad89869baf05a589e2975575 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2026010500-herself-pentagon-8cde@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From dc85a46928c41423ad89869baf05a589e2975575 Mon Sep 17 00:00:00 2001 From: Kevin Tian <kevin.tian(a)intel.com> Date: Thu, 18 Dec 2025 08:16:49 +0000 Subject: [PATCH] vfio/pci: Disable qword access to the PCI ROM bar Commit 2b938e3db335 ("vfio/pci: Enable iowrite64 and ioread64 for vfio pci") enables qword access to the PCI bar resources. However certain devices (e.g. Intel X710) are observed with problem upon qword accesses to the rom bar, e.g. triggering PCI aer errors. This is triggered by Qemu which caches the rom content by simply does a pread() of the remaining size until it gets the full contents. The other bars would only perform operations at the same access width as their guest drivers. Instead of trying to identify all broken devices, universally disable qword access to the rom bar i.e. going back to the old way which worked reliably for years. Reported-by: Farrah Chen <farrah.chen(a)intel.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220740 Fixes: 2b938e3db335 ("vfio/pci: Enable iowrite64 and ioread64 for vfio pci") Cc: stable(a)vger.kernel.org Signed-off-by: Kevin Tian <kevin.tian(a)intel.com> Tested-by: Farrah Chen <farrah.chen(a)intel.com> Link: https://lore.kernel.org/r/20251218081650.555015-2-kevin.tian@intel.com Signed-off-by: Alex Williamson <alex(a)shazbot.org> diff --git a/drivers/vfio/pci/nvgrace-gpu/main.c b/drivers/vfio/pci/nvgrace-gpu/main.c index 84d142a47ec6..b45a24d00387 100644 --- a/drivers/vfio/pci/nvgrace-gpu/main.c +++ b/drivers/vfio/pci/nvgrace-gpu/main.c @@ -561,7 +561,7 @@ nvgrace_gpu_map_and_read(struct nvgrace_gpu_pci_core_device *nvdev, ret = vfio_pci_core_do_io_rw(&nvdev->core_device, false, nvdev->resmem.ioaddr, buf, offset, mem_count, - 0, 0, false); + 0, 0, false, VFIO_PCI_IO_WIDTH_8); } return ret; @@ -693,7 +693,7 @@ nvgrace_gpu_map_and_write(struct nvgrace_gpu_pci_core_device *nvdev, ret = vfio_pci_core_do_io_rw(&nvdev->core_device, false, nvdev->resmem.ioaddr, (char __user *)buf, pos, mem_count, - 0, 0, true); + 0, 0, true, VFIO_PCI_IO_WIDTH_8); } return ret; diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c index 6192788c8ba3..25380b7dfe18 100644 --- a/drivers/vfio/pci/vfio_pci_rdwr.c +++ b/drivers/vfio/pci/vfio_pci_rdwr.c @@ -135,7 +135,8 @@ VFIO_IORDWR(64) ssize_t vfio_pci_core_do_io_rw(struct vfio_pci_core_device *vdev, bool test_mem, void __iomem *io, char __user *buf, loff_t off, size_t count, size_t x_start, - size_t x_end, bool iswrite) + size_t x_end, bool iswrite, + enum vfio_pci_io_width max_width) { ssize_t done = 0; int ret; @@ -150,20 +151,19 @@ ssize_t vfio_pci_core_do_io_rw(struct vfio_pci_core_device *vdev, bool test_mem, else fillable = 0; - if (fillable >= 8 && !(off % 8)) { + if (fillable >= 8 && !(off % 8) && max_width >= 8) { ret = vfio_pci_iordwr64(vdev, iswrite, test_mem, io, buf, off, &filled); if (ret) return ret; - } else - if (fillable >= 4 && !(off % 4)) { + } else if (fillable >= 4 && !(off % 4) && max_width >= 4) { ret = vfio_pci_iordwr32(vdev, iswrite, test_mem, io, buf, off, &filled); if (ret) return ret; - } else if (fillable >= 2 && !(off % 2)) { + } else if (fillable >= 2 && !(off % 2) && max_width >= 2) { ret = vfio_pci_iordwr16(vdev, iswrite, test_mem, io, buf, off, &filled); if (ret) @@ -234,6 +234,7 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_core_device *vdev, char __user *buf, void __iomem *io; struct resource *res = &vdev->pdev->resource[bar]; ssize_t done; + enum vfio_pci_io_width max_width = VFIO_PCI_IO_WIDTH_8; if (pci_resource_start(pdev, bar)) end = pci_resource_len(pdev, bar); @@ -262,6 +263,16 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_core_device *vdev, char __user *buf, if (!io) return -ENOMEM; x_end = end; + + /* + * Certain devices (e.g. Intel X710) don't support qword + * access to the ROM bar. Otherwise PCI AER errors might be + * triggered. + * + * Disable qword access to the ROM bar universally, which + * worked reliably for years before qword access is enabled. + */ + max_width = VFIO_PCI_IO_WIDTH_4; } else { int ret = vfio_pci_core_setup_barmap(vdev, bar); if (ret) { @@ -278,7 +289,7 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_core_device *vdev, char __user *buf, } done = vfio_pci_core_do_io_rw(vdev, res->flags & IORESOURCE_MEM, io, buf, pos, - count, x_start, x_end, iswrite); + count, x_start, x_end, iswrite, max_width); if (done >= 0) *ppos += done; @@ -352,7 +363,7 @@ ssize_t vfio_pci_vga_rw(struct vfio_pci_core_device *vdev, char __user *buf, * to the memory enable bit in the command register. */ done = vfio_pci_core_do_io_rw(vdev, false, iomem, buf, off, count, - 0, 0, iswrite); + 0, 0, iswrite, VFIO_PCI_IO_WIDTH_8); vga_put(vdev->pdev, rsrc); diff --git a/include/linux/vfio_pci_core.h b/include/linux/vfio_pci_core.h index 706877f998ff..1ac86896875c 100644 --- a/include/linux/vfio_pci_core.h +++ b/include/linux/vfio_pci_core.h @@ -145,6 +145,13 @@ struct vfio_pci_core_device { struct list_head dmabufs; }; +enum vfio_pci_io_width { + VFIO_PCI_IO_WIDTH_1 = 1, + VFIO_PCI_IO_WIDTH_2 = 2, + VFIO_PCI_IO_WIDTH_4 = 4, + VFIO_PCI_IO_WIDTH_8 = 8, +}; + /* Will be exported for vfio pci drivers usage */ int vfio_pci_core_register_dev_region(struct vfio_pci_core_device *vdev, unsigned int type, unsigned int subtype, @@ -188,7 +195,8 @@ pci_ers_result_t vfio_pci_core_aer_err_detected(struct pci_dev *pdev, ssize_t vfio_pci_core_do_io_rw(struct vfio_pci_core_device *vdev, bool test_mem, void __iomem *io, char __user *buf, loff_t off, size_t count, size_t x_start, - size_t x_end, bool iswrite); + size_t x_end, bool iswrite, + enum vfio_pci_io_width max_width); bool __vfio_pci_memory_enabled(struct vfio_pci_core_device *vdev); bool vfio_pci_core_range_intersect_range(loff_t buf_start, size_t buf_cnt, loff_t reg_start, size_t reg_cnt,

2 days, 20 hours

[to-be-updated] maple_tree-add-dead-node-check-in-mas_dup_alloc.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: maple_tree: add dead node check in mas_dup_alloc() has been removed from the -mm tree. Its filename was maple_tree-add-dead-node-check-in-mas_dup_alloc.patch This patch was dropped because an updated version will be issued ------------------------------------------------------ From: Boudewijn van der Heide <boudewijn(a)delta-utec.com> Subject: maple_tree: add dead node check in mas_dup_alloc() Date: Sat, 3 Jan 2026 17:57:58 +0100 __mt_dup() is exported and can be called without internal locking, relying on the caller to provide appropriate synchronization. If a caller fails to hold proper locks, the source tree may be modified concurrently, potentially resulting in dead nodes during traversal. The call stack is: __mt_dup() �� mas_dup_build() �� mas_dup_alloc() [accesses node->slot[]] mas_dup_alloc() may access node slots without first verifying that the node is still alive. If a dead node is encountered, its memory layout may have been switched to the RCU union member, making slot array access undefined behavior as we would be reading from the rcu_head structure instead. If __mt_dup() is invoked without the required external locking and the source tree is concurrently modified, a node can transition to the dead RCU layout while mas_dup_alloc() is still traversing it. In that case the code may interpret the rcu_head contents as slot pointers. Practically, this could lead to invalid pointer dereferences (kernel oops) or corruption of the duplicated tree. Depending on how that duplicated tree is later used (e.g. in mm/VMA paths), the effects could be userspace-visible, such as fork() failures, process crashes, or broader system instability. My understanding is that current in-tree users hold the appropriate locks and should not hit this, as triggering it requires violating the __mt_dup() synchronization contract. The risk primarily comes from the fact that __mt_dup() is exported (EXPORT_SYMBOL), making it reachable by out-of-tree modules or future callers which may not follow the locking rules. Add an explicit dead node check to detect concurrent modification during duplication. When a dead node is detected, return -EBUSY to indicate that the tree is undergoing concurrent modification. Link: https://lkml.kernel.org/r/20260103165758.74094-1-boudewijn@delta-utec.com Fixes: fd32e4e9b764 ("maple_tree: introduce interfaces __mt_dup() and mtree_dup()") Signed-off-by: Boudewijn van der Heide <boudewijn(a)delta-utec.com> Cc: Alice Ryhl <aliceryhl(a)google.com> Cc: Andrew Ballance <andrewjballance(a)gmail.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/maple_tree.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/lib/maple_tree.c~maple_tree-add-dead-node-check-in-mas_dup_alloc +++ a/lib/maple_tree.c @@ -6251,6 +6251,11 @@ static inline void mas_dup_alloc(struct /* Allocate memory for child nodes. */ type = mte_node_type(mas->node); new_slots = ma_slots(new_node, type); + if (unlikely(ma_dead_node(node))) { + mas_set_err(mas, -EBUSY); + return; + } + count = mas->node_request = mas_data_end(mas) + 1; mas_alloc_nodes(mas, gfp); if (unlikely(mas_is_err(mas))) _ Patches currently in -mm which might be from boudewijn(a)delta-utec.com are

2 days, 22 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror