May 2024 - Linux-stable-mirror

commits for stable 2024-05-11

by Ronnie Sahlberg

Please find attached a report generated by keyword matching commits from upstream that may be suitable for stable and probably as CVEs as well. I exclude commits that are already tagged with CC stable in upstream and also commits already in stable/linux-rolling-stable. I can send these type of reports weekly if you want. I plan to add more keywords to check for. But let's start small. A question about commits that have a Fixes: tag. There are ~2000 of them since v6.8. As these are definitely bugfixes, do you want me to add commits that include a Fixes: tag in future reports/scans? Also let me know if/how I can change the format of the scan so that it is easier for you to parse in your tooling. regards ronnie sahlberg -- Ronnie Sahlberg [Principal Software Engineer, Linux] P 775 384 8203 | E [email] | W ciq.com

1 year

2
4
0 0

[PATCH v2 0/3] QCM2290 LMH

by Konrad Dybcio

Wire up LMH on QCM2290 and fix a bad bug while at it. P1-2 for thermal, P3 for qcom Signed-off-by: Konrad Dybcio <konrad.dybcio(a)linaro.org> --- Changes in v2: - Pick up tags - Fix a couple typos in commit messages - Drop stray msm8998 binding addition - Link to v1: https://lore.kernel.org/r/20240308-topic-rb1_lmh-v1-0-50c60ffe1130@linaro.o… --- Konrad Dybcio (2): dt-bindings: thermal: lmh: Add QCM2290 compatible thermal: qcom: lmh: Check for SCM availability at probe Loic Poulain (1): arm64: dts: qcom: qcm2290: Add LMH node Documentation/devicetree/bindings/thermal/qcom-lmh.yaml | 12 ++++++++---- arch/arm64/boot/dts/qcom/qcm2290.dtsi | 14 +++++++++++++- drivers/thermal/qcom/lmh.c | 3 +++ 3 files changed, 24 insertions(+), 5 deletions(-) --- base-commit: 8ffc8b1bbd505e27e2c8439d326b6059c906c9dd change-id: 20240308-topic-rb1_lmh-1e0f440c392a Best regards, -- Konrad Dybcio <konrad.dybcio(a)linaro.org>

1 year

6
12
0 0

Bags

by Carrie Pan

1 year

1
0
0 0

[PATCH] drm/exynos: hdmi: report safe 640x480 mode as a fallback when no EDID found

by Marek Szyprowski

When reading EDID fails and driver reports no modes available, the DRM core adds an artificial 1024x786 mode to the connector. Unfortunately some variants of the Exynos HDMI (like the one in Exynos4 SoCs) are not able to drive such mode, so report a safe 640x480 mode instead of nothing in case of the EDID reading failure. This fixes the following issue observed on Trats2 board since commit 13d5b040363c ("drm/exynos: do not return negative values from .get_modes()"): [drm] Exynos DRM: using 11c00000.fimd device for DMA mapping operations exynos-drm exynos-drm: bound 11c00000.fimd (ops fimd_component_ops) exynos-drm exynos-drm: bound 12c10000.mixer (ops mixer_component_ops) exynos-dsi 11c80000.dsi: [drm:samsung_dsim_host_attach] Attached s6e8aa0 device (lanes:4 bpp:24 mode-flags:0x10b) exynos-drm exynos-drm: bound 11c80000.dsi (ops exynos_dsi_component_ops) exynos-drm exynos-drm: bound 12d00000.hdmi (ops hdmi_component_ops) [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1 exynos-hdmi 12d00000.hdmi: [drm:hdmiphy_enable.part.0] *ERROR* PLL could not reach steady state panel-samsung-s6e8aa0 11c80000.dsi.0: ID: 0xa2, 0x20, 0x8c exynos-mixer 12c10000.mixer: timeout waiting for VSYNC ------------[ cut here ]------------ WARNING: CPU: 1 PID: 11 at drivers/gpu/drm/drm_atomic_helper.c:1682 drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8 [CRTC:70:crtc-1] vblank wait timed out Modules linked in: CPU: 1 PID: 11 Comm: kworker/u16:0 Not tainted 6.9.0-rc5-next-20240424 #14913 Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_unbound deferred_probe_work_func Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x68/0x88 dump_stack_lvl from __warn+0x7c/0x1c4 __warn from warn_slowpath_fmt+0x11c/0x1a8 warn_slowpath_fmt from drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8 drm_atomic_helper_wait_for_vblanks.part.0 from drm_atomic_helper_commit_tail_rpm+0x7c/0x8c drm_atomic_helper_commit_tail_rpm from commit_tail+0x9c/0x184 commit_tail from drm_atomic_helper_commit+0x168/0x190 drm_atomic_helper_commit from drm_atomic_commit+0xb4/0xe0 drm_atomic_commit from drm_client_modeset_commit_atomic+0x23c/0x27c drm_client_modeset_commit_atomic from drm_client_modeset_commit_locked+0x60/0x1cc drm_client_modeset_commit_locked from drm_client_modeset_commit+0x24/0x40 drm_client_modeset_commit from __drm_fb_helper_restore_fbdev_mode_unlocked+0x9c/0xc4 __drm_fb_helper_restore_fbdev_mode_unlocked from drm_fb_helper_set_par+0x2c/0x3c drm_fb_helper_set_par from fbcon_init+0x3d8/0x550 fbcon_init from visual_init+0xc0/0x108 visual_init from do_bind_con_driver+0x1b8/0x3a4 do_bind_con_driver from do_take_over_console+0x140/0x1ec do_take_over_console from do_fbcon_takeover+0x70/0xd0 do_fbcon_takeover from fbcon_fb_registered+0x19c/0x1ac fbcon_fb_registered from register_framebuffer+0x190/0x21c register_framebuffer from __drm_fb_helper_initial_config_and_unlock+0x350/0x574 __drm_fb_helper_initial_config_and_unlock from exynos_drm_fbdev_client_hotplug+0x6c/0xb0 exynos_drm_fbdev_client_hotplug from drm_client_register+0x58/0x94 drm_client_register from exynos_drm_bind+0x160/0x190 exynos_drm_bind from try_to_bring_up_aggregate_device+0x200/0x2d8 try_to_bring_up_aggregate_device from __component_add+0xb0/0x170 __component_add from mixer_probe+0x74/0xcc mixer_probe from platform_probe+0x5c/0xb8 platform_probe from really_probe+0xe0/0x3d8 really_probe from __driver_probe_device+0x9c/0x1e4 __driver_probe_device from driver_probe_device+0x30/0xc0 driver_probe_device from __device_attach_driver+0xa8/0x120 __device_attach_driver from bus_for_each_drv+0x80/0xcc bus_for_each_drv from __device_attach+0xac/0x1fc __device_attach from bus_probe_device+0x8c/0x90 bus_probe_device from deferred_probe_work_func+0x98/0xe0 deferred_probe_work_func from process_one_work+0x240/0x6d0 process_one_work from worker_thread+0x1a0/0x3f4 worker_thread from kthread+0x104/0x138 kthread from ret_from_fork+0x14/0x28 Exception stack(0xf0895fb0 to 0xf0895ff8) ... irq event stamp: 82357 hardirqs last enabled at (82363): [<c01a96e8>] vprintk_emit+0x308/0x33c hardirqs last disabled at (82368): [<c01a969c>] vprintk_emit+0x2bc/0x33c softirqs last enabled at (81614): [<c0101644>] __do_softirq+0x320/0x500 softirqs last disabled at (81609): [<c012dfe0>] __irq_exit_rcu+0x130/0x184 ---[ end trace 0000000000000000 ]--- exynos-drm exynos-drm: [drm] *ERROR* flip_done timed out exynos-drm exynos-drm: [drm] *ERROR* [CRTC:70:crtc-1] commit wait timed out exynos-drm exynos-drm: [drm] *ERROR* flip_done timed out exynos-drm exynos-drm: [drm] *ERROR* [CONNECTOR:74:HDMI-A-1] commit wait timed out exynos-drm exynos-drm: [drm] *ERROR* flip_done timed out exynos-drm exynos-drm: [drm] *ERROR* [PLANE:56:plane-5] commit wait timed out exynos-mixer 12c10000.mixer: timeout waiting for VSYNC Cc: stable(a)vger.kernel.org Fixes: 13d5b040363c ("drm/exynos: do not return negative values from .get_modes()") Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- drivers/gpu/drm/exynos/exynos_hdmi.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index 5fdeec8a3875..9d246db6ef2b 100644 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c @@ -887,11 +887,11 @@ static int hdmi_get_modes(struct drm_connector *connector) int ret; if (!hdata->ddc_adpt) - return 0; + goto no_edid; edid = drm_get_edid(connector, hdata->ddc_adpt); if (!edid) - return 0; + goto no_edid; hdata->dvi_mode = !connector->display_info.is_hdmi; DRM_DEV_DEBUG_KMS(hdata->dev, "%s : width[%d] x height[%d]\n", @@ -906,6 +906,9 @@ static int hdmi_get_modes(struct drm_connector *connector) kfree(edid); return ret; + +no_edid: + return drm_add_modes_noedid(connector, 640, 480); } static int hdmi_find_phy_conf(struct hdmi_context *hdata, u32 pixel_clock) -- 2.34.1

1 year

2
1
0 0

[PATCH 0/2] Bluetooth: hci_bcm4377 fixes

by Sven Peter via B4 Relay

Hi, There are just two minor fixes from Hector that we've been carrying downstream for a while now. One increases the timeout while waiting for the firmware to boot which is optional for the controller already supported upstream but required for a newer 4388 board for which we'll also submit support soon. It also fixes the units for the timeouts which is why I've already included it here. The other one fixes a call to bitmap_release_region where we only wanted to release a single bit but are actually releasing much more. Best, Sven Signed-off-by: Sven Peter <sven(a)svenpeter.dev> --- Hector Martin (2): Bluetooth: hci_bcm4377: Increase boot timeout Bluetooth: hci_bcm4377: Fix msgid release drivers/bluetooth/hci_bcm4377.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- base-commit: cf87f46fd34d6c19283d9625a7822f20d90b64a4 change-id: 20240512-btfix-msgid-d76029a7d917 Best regards, -- Sven Peter <sven(a)svenpeter.dev>

1 year

2
2
0 0

[PATCH v2] KEYS: trusted: Do not use WARN when encode fails

by Jarkko Sakkinen

When asn1_encode_sequence() fails, WARN is not the correct solution. 1. asn1_encode_sequence() is not an internal function (located in lib/asn1_encode.c). 2. Location is known, which makes the stack trace useless. 3. Results a crash if panic_on_warn is set. It is also noteworthy that the use of WARN is undocumented, and it should be avoided unless there is a carefully considered rationale to use it. Replace WARN with pr_err, and print the return value instead, which is only useful piece of information. Cc: stable(a)vger.kernel.org # v5.13+ Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs") Signed-off-by: Jarkko Sakkinen <jarkko(a)kernel.org> --- v2: Fix typos in the commit message --- security/keys/trusted-keys/trusted_tpm2.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c index dfeec06301ce..dbdd6a318b8b 100644 --- a/security/keys/trusted-keys/trusted_tpm2.c +++ b/security/keys/trusted-keys/trusted_tpm2.c @@ -38,6 +38,7 @@ static int tpm2_key_encode(struct trusted_key_payload *payload, u8 *end_work = scratch + SCRATCH_SIZE; u8 *priv, *pub; u16 priv_len, pub_len; + int ret; priv_len = get_unaligned_be16(src) + 2; priv = src; @@ -79,8 +80,11 @@ static int tpm2_key_encode(struct trusted_key_payload *payload, work1 = payload->blob; work1 = asn1_encode_sequence(work1, work1 + sizeof(payload->blob), scratch, work - scratch); - if (WARN(IS_ERR(work1), "BUG: ASN.1 encoder failed")) - return PTR_ERR(work1); + if (IS_ERR(work1)) { + ret = PTR_ERR(work1); + pr_err("ASN.1 encode error %d\n", ret); + return ret; + } return work1 - payload->blob; } -- 2.45.0

1 year

1
0
0 0

[PATCH] md: fix kmemleak of rdev->serial

by Jeremy Bongio

From: Li Nan <linan122(a)huawei.com> commit 6cf350658736681b9d6b0b6e58c5c76b235bb4c4 upstream. If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be alloc not be freed, and kmemleak occurs. unreferenced object 0xffff88815a350000 (size 49152): comm "mdadm", pid 789, jiffies 4294716910 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc f773277a): [<0000000058b0a453>] kmemleak_alloc+0x61/0xe0 [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270 [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f [<00000000f206d60a>] kvmalloc_node+0x74/0x150 [<0000000034bf3363>] rdev_init_serial+0x67/0x170 [<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220 [<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630 [<0000000073c28560>] md_add_new_disk+0x400/0x9f0 [<00000000770e30ff>] md_ioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0 [<0000000085086a11>] vfs_ioctl+0x22/0x60 [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0 [<00000000e54e675e>] do_syscall_64+0x71/0x150 [<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 backport change: mddev_destroy_serial_pool third parameter was removed in mainline, where there is no need to suspend within this function anymore. Fixes: 963c555e75b0 ("md: introduce mddev_create/destroy_wb_pool for the change of member device") Signed-off-by: Li Nan <linan122(a)huawei.com> Signed-off-by: Song Liu <song(a)kernel.org> Link: https://lore.kernel.org/r/20240208085556.2412922-1-linan666@huaweicloud.com Change-Id: Icc4960dcaffedc663797e2d8b18a24c23e201932 Signed-off-by: Jeremy Bongio <jbongio(a)google.com> --- drivers/md/md.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/md/md.c b/drivers/md/md.c index 09c7f52156f3f..67ceab4573be4 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -2532,6 +2532,7 @@ static int bind_rdev_to_array(struct md_rdev *rdev, struct mddev *mddev) fail: pr_warn("md: failed to register dev-%s for %s\n", b, mdname(mddev)); + mddev_destroy_serial_pool(mddev, rdev, false); return err; } -- 2.45.0.118.g7fe29c98d7-goog

1 year

2
2
0 0

[PATCH] md: fix kmemleak of rdev->serial

by Jeremy Bongio

From: Li Nan <linan122(a)huawei.com> If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be alloc not be freed, and kmemleak occurs. unreferenced object 0xffff88815a350000 (size 49152): comm "mdadm", pid 789, jiffies 4294716910 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc f773277a): [<0000000058b0a453>] kmemleak_alloc+0x61/0xe0 [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270 [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f [<00000000f206d60a>] kvmalloc_node+0x74/0x150 [<0000000034bf3363>] rdev_init_serial+0x67/0x170 [<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220 [<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630 [<0000000073c28560>] md_add_new_disk+0x400/0x9f0 [<00000000770e30ff>] md_ioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0 [<0000000085086a11>] vfs_ioctl+0x22/0x60 [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0 [<00000000e54e675e>] do_syscall_64+0x71/0x150 [<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 Fixes: 963c555e75b0 ("md: introduce mddev_create/destroy_wb_pool for the change of member device") Signed-off-by: Li Nan <linan122(a)huawei.com> Signed-off-by: Song Liu <song(a)kernel.org> Link: https://lore.kernel.org/r/20240208085556.2412922-1-linan666@huaweicloud.com Change-Id: Icc4960dcaffedc663797e2d8b18a24c23e201932 --- drivers/md/md.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/md/md.c b/drivers/md/md.c index 09c7f52156f3f..67ceab4573be4 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -2532,6 +2532,7 @@ static int bind_rdev_to_array(struct md_rdev *rdev, struct mddev *mddev) fail: pr_warn("md: failed to register dev-%s for %s\n", b, mdname(mddev)); + mddev_destroy_serial_pool(mddev, rdev, false); return err; } -- 2.45.0.118.g7fe29c98d7-goog

1 year

3
3
0 0

Re: [PATCH 5.4.y] ext4: fix bug_on in __es_tree_search

by Guilherme G. Piccoli

CCing the right stable ML address... Apologies! On 11/05/2024 18:10, Guilherme G. Piccoli wrote: > From: Baokun Li <libaokun1(a)huawei.com> > > commit d36f6ed761b53933b0b4126486c10d3da7751e7f upstream. > > Hulk Robot reported a BUG_ON: > ================================================================== > kernel BUG at fs/ext4/extents_status.c:199! > [...] > RIP: 0010:ext4_es_end fs/ext4/extents_status.c:199 [inline] > RIP: 0010:__es_tree_search+0x1e0/0x260 fs/ext4/extents_status.c:217 > [...] > Call Trace: > ext4_es_cache_extent+0x109/0x340 fs/ext4/extents_status.c:766 > ext4_cache_extents+0x239/0x2e0 fs/ext4/extents.c:561 > ext4_find_extent+0x6b7/0xa20 fs/ext4/extents.c:964 > ext4_ext_map_blocks+0x16b/0x4b70 fs/ext4/extents.c:4384 > ext4_map_blocks+0xe26/0x19f0 fs/ext4/inode.c:567 > ext4_getblk+0x320/0x4c0 fs/ext4/inode.c:980 > ext4_bread+0x2d/0x170 fs/ext4/inode.c:1031 > ext4_quota_read+0x248/0x320 fs/ext4/super.c:6257 > v2_read_header+0x78/0x110 fs/quota/quota_v2.c:63 > v2_check_quota_file+0x76/0x230 fs/quota/quota_v2.c:82 > vfs_load_quota_inode+0x5d1/0x1530 fs/quota/dquot.c:2368 > dquot_enable+0x28a/0x330 fs/quota/dquot.c:2490 > ext4_quota_enable fs/ext4/super.c:6137 [inline] > ext4_enable_quotas+0x5d7/0x960 fs/ext4/super.c:6163 > ext4_fill_super+0xa7c9/0xdc00 fs/ext4/super.c:4754 > mount_bdev+0x2e9/0x3b0 fs/super.c:1158 > mount_fs+0x4b/0x1e4 fs/super.c:1261 > [...] > ================================================================== > > Above issue may happen as follows: > ------------------------------------- > ext4_fill_super > ext4_enable_quotas > ext4_quota_enable > ext4_iget > __ext4_iget > ext4_ext_check_inode > ext4_ext_check > __ext4_ext_check > ext4_valid_extent_entries > Check for overlapping extents does't take effect > dquot_enable > vfs_load_quota_inode > v2_check_quota_file > v2_read_header > ext4_quota_read > ext4_bread > ext4_getblk > ext4_map_blocks > ext4_ext_map_blocks > ext4_find_extent > ext4_cache_extents > ext4_es_cache_extent > ext4_es_cache_extent > __es_tree_search > ext4_es_end > BUG_ON(es->es_lblk + es->es_len < es->es_lblk) > > The error ext4 extents is as follows: > 0af3 0300 0400 0000 00000000 extent_header > 00000000 0100 0000 12000000 extent1 > 00000000 0100 0000 18000000 extent2 > 02000000 0400 0000 14000000 extent3 > > In the ext4_valid_extent_entries function, > if prev is 0, no error is returned even if lblock<=prev. > This was intended to skip the check on the first extent, but > in the error image above, prev=0+1-1=0 when checking the second extent, > so even though lblock<=prev, the function does not return an error. > As a result, bug_ON occurs in __es_tree_search and the system panics. > > To solve this problem, we only need to check that: > 1. The lblock of the first extent is not less than 0. > 2. The lblock of the next extent is not less than > the next block of the previous extent. > The same applies to extent_idx. > > Cc: stable(a)kernel.org > Fixes: 5946d089379a ("ext4: check for overlapping extents in ext4_valid_extent_entries()") > Reported-by: Hulk Robot <hulkci(a)huawei.com> > Signed-off-by: Baokun Li <libaokun1(a)huawei.com> > Reviewed-by: Jan Kara <jack(a)suse.cz> > Link: https://lore.kernel.org/r/20220518120816.1541863-1-libaokun1@huawei.com > Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> > Reported-by: syzbot+2a58d88f0fb315c85363(a)syzkaller.appspotmail.com > [gpiccoli: Manual backport due to unrelated missing patches.] > Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)igalia.com> > --- > > > Hey folks, this one should have been backported but due to merge > issues [0], it ended-up not being on 5.4.y . So here is a working version! > Cheers, > > Guilherme > > [0] https://lore.kernel.org/stable/165451751147179@kroah.com/ > > > fs/ext4/extents.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c > index 98e1b1ddb4ec..90b12c7c0f20 100644 > --- a/fs/ext4/extents.c > +++ b/fs/ext4/extents.c > @@ -409,7 +409,7 @@ static int ext4_valid_extent_entries(struct inode *inode, > { > unsigned short entries; > ext4_lblk_t lblock = 0; > - ext4_lblk_t prev = 0; > + ext4_lblk_t cur = 0; > > if (eh->eh_entries == 0) > return 1; > @@ -435,12 +435,12 @@ static int ext4_valid_extent_entries(struct inode *inode, > > /* Check for overlapping extents */ > lblock = le32_to_cpu(ext->ee_block); > - if ((lblock <= prev) && prev) { > + if (lblock < cur) { > pblock = ext4_ext_pblock(ext); > es->s_last_error_block = cpu_to_le64(pblock); > return 0; > } > - prev = lblock + ext4_ext_get_actual_len(ext) - 1; > + cur = lblock + ext4_ext_get_actual_len(ext); > ext++; > entries--; > } > @@ -460,13 +460,13 @@ static int ext4_valid_extent_entries(struct inode *inode, > > /* Check for overlapping index extents */ > lblock = le32_to_cpu(ext_idx->ei_block); > - if ((lblock <= prev) && prev) { > + if (lblock < cur) { > *pblk = ext4_idx_pblock(ext_idx); > return 0; > } > ext_idx++; > entries--; > - prev = lblock; > + cur = lblock + 1; > } > } > return 1;

1 year

2
2
0 0

[PATCH] md: fix kmemleak of rdev->serial

by Jeremy Bongio

From: Li Nan <linan122(a)huawei.com> If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be alloc not be freed, and kmemleak occurs. unreferenced object 0xffff88815a350000 (size 49152): comm "mdadm", pid 789, jiffies 4294716910 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc f773277a): [<0000000058b0a453>] kmemleak_alloc+0x61/0xe0 [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270 [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f [<00000000f206d60a>] kvmalloc_node+0x74/0x150 [<0000000034bf3363>] rdev_init_serial+0x67/0x170 [<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220 [<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630 [<0000000073c28560>] md_add_new_disk+0x400/0x9f0 [<00000000770e30ff>] md_ioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0 [<0000000085086a11>] vfs_ioctl+0x22/0x60 [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0 [<00000000e54e675e>] do_syscall_64+0x71/0x150 [<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 Fixes: 963c555e75b0 ("md: introduce mddev_create/destroy_wb_pool for the change of member device") Signed-off-by: Li Nan <linan122(a)huawei.com> Signed-off-by: Song Liu <song(a)kernel.org> Link: https://lore.kernel.org/r/20240208085556.2412922-1-linan666@huaweicloud.com Change-Id: Icc4960dcaffedc663797e2d8b18a24c23e201932 --- drivers/md/md.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/md/md.c b/drivers/md/md.c index 09c7f52156f3f..67ceab4573be4 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -2532,6 +2532,7 @@ static int bind_rdev_to_array(struct md_rdev *rdev, struct mddev *mddev) fail: pr_warn("md: failed to register dev-%s for %s\n", b, mdname(mddev)); + mddev_destroy_serial_pool(mddev, rdev, false); return err; } -- 2.45.0.118.g7fe29c98d7-goog

1 year

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2024