May 2025 - Linux-stable-mirror

[PATCH net,v3] hv_netvsc: fix potential deadlock in netvsc_vf_setxdp()

by Saurabh Sengar

The MANA driver's probe registers netdevice via the following call chain: mana_probe() register_netdev() register_netdevice() register_netdevice() calls notifier callback for netvsc driver, holding the netdev mutex via netdev_lock_ops(). Further this netvsc notifier callback end up attempting to acquire the same lock again in dev_xdp_propagate() leading to deadlock. netvsc_netdev_event() netvsc_vf_setxdp() dev_xdp_propagate() This deadlock was not observed so far because net_shaper_ops was never set, and thus the lock was effectively a no-op in this case. Fix this by using netif_xdp_propagate() instead of dev_xdp_propagate() to avoid recursive locking in this path. And, since no deadlock is observed on the other path which is via netvsc_probe, add the lock exclusivly for that path. Also, clean up the unregistration path by removing the unnecessary call to netvsc_vf_setxdp(), since unregister_netdevice_many_notify() already performs this cleanup via dev_xdp_uninstall(). Fixes: 97246d6d21c2 ("net: hold netdev instance lock during ndo_bpf") Cc: stable(a)vger.kernel.org Signed-off-by: Saurabh Sengar <ssengar(a)linux.microsoft.com> Tested-by: Erni Sri Satya Vennela <ernis(a)linux.microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz(a)microsoft.com> Reviewed-by: Subbaraya Sundeep <sbhatta(a)marvell.com> --- [V3] - Add the lock for netvsc probe path [V2] - Modified commit message drivers/net/hyperv/netvsc_bpf.c | 2 +- drivers/net/hyperv/netvsc_drv.c | 4 ++-- net/core/dev.c | 1 + 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/net/hyperv/netvsc_bpf.c b/drivers/net/hyperv/netvsc_bpf.c index e01c5997a551..1dd3755d9e6d 100644 --- a/drivers/net/hyperv/netvsc_bpf.c +++ b/drivers/net/hyperv/netvsc_bpf.c @@ -183,7 +183,7 @@ int netvsc_vf_setxdp(struct net_device *vf_netdev, struct bpf_prog *prog) xdp.command = XDP_SETUP_PROG; xdp.prog = prog; - ret = dev_xdp_propagate(vf_netdev, &xdp); + ret = netif_xdp_propagate(vf_netdev, &xdp); if (ret && prog) bpf_prog_put(prog); diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index 14a0d04e21ae..c41a025c66f0 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -2462,8 +2462,6 @@ static int netvsc_unregister_vf(struct net_device *vf_netdev) netdev_info(ndev, "VF unregistering: %s\n", vf_netdev->name); - netvsc_vf_setxdp(vf_netdev, NULL); - reinit_completion(&net_device_ctx->vf_add); netdev_rx_handler_unregister(vf_netdev); netdev_upper_dev_unlink(vf_netdev, ndev); @@ -2631,7 +2629,9 @@ static int netvsc_probe(struct hv_device *dev, continue; netvsc_prepare_bonding(vf_netdev); + netdev_lock_ops(vf_netdev); netvsc_register_vf(vf_netdev, VF_REG_IN_PROBE); + netdev_unlock_ops(vf_netdev); __netvsc_vf_setup(net, vf_netdev); break; } diff --git a/net/core/dev.c b/net/core/dev.c index 2b514d95c528..a388f459a366 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -9968,6 +9968,7 @@ int netif_xdp_propagate(struct net_device *dev, struct netdev_bpf *bpf) return dev->netdev_ops->ndo_bpf(dev, bpf); } +EXPORT_SYMBOL_GPL(netif_xdp_propagate); u32 dev_xdp_prog_id(struct net_device *dev, enum bpf_xdp_mode mode) { -- 2.43.0

5 months, 1 week

2
1
0 0

[PATCH] iio: adc: adi-axi-adc: fix ad7606_bus_reg_read()

by David Lechner

Mask the value read before returning it. The value read over the parallel bus via the AXI ADC IP block contains both the address and the data, but callers expect val to only contain the data. Cc: stable(a)vger.kernel.org Fixes: 79c47485e438 ("iio: adc: adi-axi-adc: add support for AD7606 register writing") Signed-off-by: David Lechner <dlechner(a)baylibre.com> --- drivers/iio/adc/adi-axi-adc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iio/adc/adi-axi-adc.c b/drivers/iio/adc/adi-axi-adc.c index cf942c043457ccea49207c3900153ee371b3774f..d4759a98b4062bc25ea088e3868806e82db03e8d 100644 --- a/drivers/iio/adc/adi-axi-adc.c +++ b/drivers/iio/adc/adi-axi-adc.c @@ -457,6 +457,9 @@ static int ad7606_bus_reg_read(struct iio_backend *back, u32 reg, u32 *val) axi_adc_raw_write(back, addr); axi_adc_raw_read(back, val); + /* Register value is 8 bits. Remove address bits. */ + *val &= 0xFF; + /* Write 0x0 on the bus to get back to ADC mode */ axi_adc_raw_write(back, 0); --- base-commit: 7cdfbc0113d087348b8e65dd79276d0f57b89a10 change-id: 20250530-iio-adc-adi-axi-adc-fix-ad7606_bus_reg_read-f2bbb503db8b Best regards, -- David Lechner <dlechner(a)baylibre.com>

5 months, 1 week

1
2
0 0

[PATCH resend 2/2] jffs2: initialize inocache earlier

by Fedor Pchelkin

Inside jffs2_new_inode() there is a small gap when jffs2_init_acl_pre() or jffs2_do_new_inode() may fail e.g. due to a memory allocation error while uninit inocache field is touched upon subsequent inode eviction. general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] CPU: 0 PID: 10592 Comm: syz-executor.1 Not tainted 5.10.209-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2_xattr_delete_inode+0x35/0x130 fs/jffs2/xattr.c:602 Call Trace: jffs2_do_clear_inode+0x4c/0x570 fs/jffs2/readinode.c:1418 evict+0x281/0x6b0 fs/inode.c:577 iput_final fs/inode.c:1697 [inline] iput.part.0+0x4df/0x6d0 fs/inode.c:1723 iput+0x58/0x80 fs/inode.c:1713 jffs2_new_inode+0xb12/0xdb0 fs/jffs2/fs.c:469 jffs2_create+0x90/0x400 fs/jffs2/dir.c:177 lookup_open.isra.0+0xead/0x1260 fs/namei.c:3169 open_last_lookups fs/namei.c:3239 [inline] path_openat+0x96c/0x2670 fs/namei.c:3428 do_filp_open+0x1a4/0x3f0 fs/namei.c:3458 do_sys_openat2+0x171/0x420 fs/open.c:1186 do_sys_open fs/open.c:1202 [inline] __do_sys_openat fs/open.c:1218 [inline] __se_sys_openat fs/open.c:1213 [inline] __x64_sys_openat+0x13c/0x1f0 fs/open.c:1213 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 Initialize the inocache pointer to a NULL value while preparing an inode in jffs2_init_inode_info(). jffs2_xattr_delete_inode() will handle it later just fine. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> Reviewed-by: Zhihao Cheng <chengzhihao1(a)huawei.com> --- fs/jffs2/os-linux.h | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/jffs2/os-linux.h b/fs/jffs2/os-linux.h index 86ab014a349c..39b6565f10c9 100644 --- a/fs/jffs2/os-linux.h +++ b/fs/jffs2/os-linux.h @@ -55,6 +55,7 @@ static inline void jffs2_init_inode_info(struct jffs2_inode_info *f) f->metadata = NULL; f->dents = NULL; f->target = NULL; + f->inocache = NULL; f->flags = 0; f->usercompr = 0; } -- 2.49.0

5 months, 1 week

1
0
0 0

[PATCH resend 1/2] jffs2: initialize filesystem-private inode info in ->alloc_inode callback

by Fedor Pchelkin

The symlink body (->target) should be freed at the same time as the inode itself per commit 4fdcfab5b553 ("jffs2: fix use-after-free on symlink traversal"). It is a filesystem-specific field but there exist several error paths during generic inode allocation when ->free_inode(), namely jffs2_free_inode(), is called with still uninitialized private info. The calltrace looks like: alloc_inode inode_init_always // fails i_callback free_inode jffs2_free_inode // touches uninit ->target field Commit af9a8730ddb6 ("jffs2: Fix potential illegal address access in jffs2_free_inode") approached the observed problem but fixed it only partially. Our local Syzkaller instance is still hitting these kinds of failures. The thing is that jffs2_i_init_once(), where the initialization of f->target has been moved, is called once per slab allocation so it won't be called for the object structure possibly retrieved later from the slab cache for reuse. The practice followed by many other filesystems is to initialize filesystem-private inode contents in the corresponding ->alloc_inode() callbacks. This also allows to drop initialization from jffs2_iget() and jffs2_new_inode() as ->alloc_inode() is called in those places. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 4fdcfab5b553 ("jffs2: fix use-after-free on symlink traversal") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> Reviewed-by: Zhihao Cheng <chengzhihao1(a)huawei.com> --- fs/jffs2/fs.c | 2 -- fs/jffs2/super.c | 3 ++- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c index d175cccb7c55..85c4b273918f 100644 --- a/fs/jffs2/fs.c +++ b/fs/jffs2/fs.c @@ -271,7 +271,6 @@ struct inode *jffs2_iget(struct super_block *sb, unsigned long ino) f = JFFS2_INODE_INFO(inode); c = JFFS2_SB_INFO(inode->i_sb); - jffs2_init_inode_info(f); mutex_lock(&f->sem); ret = jffs2_do_read_inode(c, f, inode->i_ino, &latest_node); @@ -439,7 +438,6 @@ struct inode *jffs2_new_inode (struct inode *dir_i, umode_t mode, struct jffs2_r return ERR_PTR(-ENOMEM); f = JFFS2_INODE_INFO(inode); - jffs2_init_inode_info(f); mutex_lock(&f->sem); memset(ri, 0, sizeof(*ri)); diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c index 4545f885c41e..b56ff63357f3 100644 --- a/fs/jffs2/super.c +++ b/fs/jffs2/super.c @@ -42,6 +42,8 @@ static struct inode *jffs2_alloc_inode(struct super_block *sb) f = alloc_inode_sb(sb, jffs2_inode_cachep, GFP_KERNEL); if (!f) return NULL; + + jffs2_init_inode_info(f); return &f->vfs_inode; } @@ -58,7 +60,6 @@ static void jffs2_i_init_once(void *foo) struct jffs2_inode_info *f = foo; mutex_init(&f->sem); - f->target = NULL; inode_init_once(&f->vfs_inode); } -- 2.49.0

5 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] x86/mm/init: Handle the special case of device private pages" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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-5.15.y git checkout FETCH_HEAD git cherry-pick -x 7170130e4c72ce0caa0cb42a1627c635cc262821 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025052750-fondness-revocable-a23b@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7170130e4c72ce0caa0cb42a1627c635cc262821 Mon Sep 17 00:00:00 2001 From: Balbir Singh <balbirs(a)nvidia.com> Date: Tue, 1 Apr 2025 11:07:52 +1100 Subject: [PATCH] x86/mm/init: Handle the special case of device private pages in add_pages(), to not increase max_pfn and trigger dma_addressing_limited() bounce buffers MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As Bert Karwatzki reported, the following recent commit causes a performance regression on AMD iGPU and dGPU systems: 7ffb791423c7 ("x86/kaslr: Reduce KASLR entropy on most x86 systems") It exposed a bug with nokaslr and zone device interaction. The root cause of the bug is that, the GPU driver registers a zone device private memory region. When KASLR is disabled or the above commit is applied, the direct_map_physmem_end is set to much higher than 10 TiB typically to the 64TiB address. When zone device private memory is added to the system via add_pages(), it bumps up the max_pfn to the same value. This causes dma_addressing_limited() to return true, since the device cannot address memory all the way up to max_pfn. This caused a regression for games played on the iGPU, as it resulted in the DMA32 zone being used for GPU allocations. Fix this by not bumping up max_pfn on x86 systems, when pgmap is passed into add_pages(). The presence of pgmap is used to determine if device private memory is being added via add_pages(). More details: devm_request_mem_region() and request_free_mem_region() request for device private memory. iomem_resource is passed as the base resource with start and end parameters. iomem_resource's end depends on several factors, including the platform and virtualization. On x86 for example on bare metal, this value is set to boot_cpu_data.x86_phys_bits. boot_cpu_data.x86_phys_bits can change depending on support for MKTME. By default it is set to the same as log2(direct_map_physmem_end) which is 46 to 52 bits depending on the number of levels in the page table. The allocation routines used iomem_resource's end and direct_map_physmem_end to figure out where to allocate the region. [ arch/powerpc is also impacted by this problem, but this patch does not fix the issue for PowerPC. ] Testing: 1. Tested on a virtual machine with test_hmm for zone device inseration 2. A previous version of this patch was tested by Bert, please see: https://lore.kernel.org/lkml/d87680bab997fdc9fb4e638983132af235d9a03a.camel… [ mingo: Clarified the comments and the changelog. ] Reported-by: Bert Karwatzki <spasswolf(a)web.de> Tested-by: Bert Karwatzki <spasswolf(a)web.de> Fixes: 7ffb791423c7 ("x86/kaslr: Reduce KASLR entropy on most x86 systems") Signed-off-by: Balbir Singh <balbirs(a)nvidia.com> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Juergen Gross <jgross(a)suse.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: David Airlie <airlied(a)gmail.com> Cc: Simona Vetter <simona(a)ffwll.ch> Link: https://lore.kernel.org/r/20250401000752.249348-1-balbirs@nvidia.com diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c index 519aa53114fa..821a0b53b21c 100644 --- a/arch/x86/mm/init_64.c +++ b/arch/x86/mm/init_64.c @@ -959,9 +959,18 @@ int add_pages(int nid, unsigned long start_pfn, unsigned long nr_pages, ret = __add_pages(nid, start_pfn, nr_pages, params); WARN_ON_ONCE(ret); - /* update max_pfn, max_low_pfn and high_memory */ - update_end_of_memory_vars(start_pfn << PAGE_SHIFT, - nr_pages << PAGE_SHIFT); + /* + * Special case: add_pages() is called by memremap_pages() for adding device + * private pages. Do not bump up max_pfn in the device private path, + * because max_pfn changes affect dma_addressing_limited(). + * + * dma_addressing_limited() returning true when max_pfn is the device's + * addressable memory can force device drivers to use bounce buffers + * and impact their performance negatively: + */ + if (!params->pgmap) + /* update max_pfn, max_low_pfn and high_memory */ + update_end_of_memory_vars(start_pfn << PAGE_SHIFT, nr_pages << PAGE_SHIFT); return ret; }

5 months, 1 week

4
5
0 0

[PATCH 3/3] ASoC: amd: acp3x-pdm-dma: free pdm device data on closing

by Fedor Pchelkin

Dynamic memory referenced by runtime->private_data pointer is allocated in acp_pdm_dma_open() and needs to be freed in the corresponding ->close() callback. Found by Linux Verification Center (linuxtesting.org). Fixes: 4a767b1d039a ("ASoC: amd: add acp3x pdm driver dma ops") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> --- sound/soc/amd/renoir/acp3x-pdm-dma.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/amd/renoir/acp3x-pdm-dma.c b/sound/soc/amd/renoir/acp3x-pdm-dma.c index 95ac8c680037..6b294040e164 100644 --- a/sound/soc/amd/renoir/acp3x-pdm-dma.c +++ b/sound/soc/amd/renoir/acp3x-pdm-dma.c @@ -301,9 +301,11 @@ static int acp_pdm_dma_close(struct snd_soc_component *component, struct snd_pcm_substream *substream) { struct pdm_dev_data *adata = dev_get_drvdata(component->dev); + struct snd_pcm_runtime *runtime = substream->runtime; disable_pdm_interrupts(adata->acp_base); adata->capture_stream = NULL; + kfree(runtime->private_data); return 0; } -- 2.49.0

5 months, 1 week

1
0
0 0

[PATCH 2/3] ASoC: amd: acp3x-pcm-dma: free runtime private data on closing

by Fedor Pchelkin

Dynamic memory referenced by runtime->private_data pointer is allocated in acp3x_dma_open() and needs to be freed in the corresponding ->close() callback. Found by Linux Verification Center (linuxtesting.org). Fixes: c9fe7db6e884 ("ASoC: amd: Refactoring of DAI from DMA driver") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> --- sound/soc/amd/raven/acp3x-pcm-dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/amd/raven/acp3x-pcm-dma.c b/sound/soc/amd/raven/acp3x-pcm-dma.c index bb9ed52d744d..90559c8304bc 100644 --- a/sound/soc/amd/raven/acp3x-pcm-dma.c +++ b/sound/soc/amd/raven/acp3x-pcm-dma.c @@ -353,7 +353,7 @@ static int acp3x_dma_close(struct snd_soc_component *component, adata->i2ssp_capture_stream = NULL; } } - + kfree(ins); return 0; } -- 2.49.0

5 months, 1 week

1
0
0 0

[PATCH 1/3] ASoC: amd: acp6x-pdm-dma: free pdm device data on closing

by Fedor Pchelkin

Dynamic memory referenced by runtime->private_data pointer is allocated in acp6x_pdm_dma_open() and needs to be freed in the corresponding ->close() callback. unreferenced object 0xffff88813525a940 (size 32): comm "pipewire", pid 1238, jiffies 4294728195 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 3c 03 00 c9 ff ff ..........<..... backtrace (crc 14400236): __kmalloc_cache_noprof+0x3a3/0x490 acp6x_pdm_dma_open+0x10d/0x680 [snd_acp6x_pdm_dma] snd_soc_component_open+0x71/0x150 [snd_soc_core] __soc_pcm_open+0x221/0xb40 [snd_soc_core] soc_pcm_open+0x99/0x110 [snd_soc_core] snd_pcm_open_substream+0x18b/0x4e0 [snd_pcm] snd_pcm_open+0x244/0x670 [snd_pcm] snd_pcm_capture_open+0x72/0xd0 [snd_pcm] chrdev_open+0x1eb/0x5e0 do_dentry_open+0x494/0x1820 vfs_open+0x7a/0x440 do_open+0x3d0/0xd30 path_openat+0x1d3/0x580 do_filp_open+0x1c5/0x450 do_sys_openat2+0xef/0x180 __x64_sys_openat+0x10e/0x210 Found by Linux Verification Center (linuxtesting.org). Fixes: ceb4fcc13ae5 ("ASoC: amd: add acp6x pdm driver dma ops") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> --- sound/soc/amd/yc/acp6x-pdm-dma.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/amd/yc/acp6x-pdm-dma.c b/sound/soc/amd/yc/acp6x-pdm-dma.c index ac758b90f441..167cd792d33d 100644 --- a/sound/soc/amd/yc/acp6x-pdm-dma.c +++ b/sound/soc/amd/yc/acp6x-pdm-dma.c @@ -275,9 +275,11 @@ static int acp6x_pdm_dma_close(struct snd_soc_component *component, struct snd_pcm_substream *substream) { struct pdm_dev_data *adata = dev_get_drvdata(component->dev); + struct snd_pcm_runtime *runtime = substream->runtime; acp6x_disable_pdm_interrupts(adata->acp6x_base); adata->capture_stream = NULL; + kfree(runtime->private_data); return 0; } -- 2.49.0

5 months, 1 week

1
0
0 0

[PATCH AUTOSEL 5.4 1/6] ACPICA: fix acpi operand cache leak in dswstate.c

by Sasha Levin

From: Seunghun Han <kkamagui(a)gmail.com> [ Upstream commit 156fd20a41e776bbf334bd5e45c4f78dfc90ce1c ] ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Link: https://github.com/acpica/acpica/commit/987a3b5c Signed-off-by: Seunghun Han <kkamagui(a)gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Link: https://patch.msgid.link/4999480.31r3eYUQgx@rjwysocki.net Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees based on the following analysis: ## Analysis of the Commit **1. Bug Fix Nature**: This commit fixes a clear memory leak bug in the ACPICA subsystem. The issue occurs when `acpi_ds_create_operands()` encounters an error during operand creation and needs to clean up allocated operands. **2. Root Cause**: The core issue is a mismatch between how operands are pushed and popped from the stack: - `acpi_ds_obj_stack_push()` uses `walk_state->operand_index` to track the current position - `acpi_ds_obj_stack_pop_and_delete()` incorrectly assumes operands start at index 0 - This causes incomplete cleanup when errors occur, leading to memory leaks **3. Code Analysis**: The fix correctly addresses the issue by: - Tracking the original operand count (`prev_num_operands`) - Calculating the correct number of operands to clean up (`new_num_operands`) - Setting `walk_state->num_operands = i` before cleanup to ensure proper indexing - Restoring the original operand count after cleanup **4. Security Implications**: The commit message explicitly mentions this is a security issue - the memory leak can expose kernel function addresses in older kernels (≤4.9), potentially defeating ASLR. This elevates the importance beyond a simple memory leak. **5. Pattern Consistency**: This follows the exact same pattern as other ACPICA operand cache leak fixes that were successfully backported (commits `97f3c0a4b057`, `2915f16bdce2`, etc.), all authored by the same developer addressing similar issues. **6. Stability Characteristics**: - **Small and contained**: Only 8 lines of actual logic changes - **Clear error path**: Only affects cleanup during error conditions - **No behavioral changes**: No impact on normal operation - **Low regression risk**: Only modifies error handling paths **7. Backport Suitability Criteria**: - ✅ Fixes important bug affecting users (memory leak) - ✅ Small, contained fix with minimal risk - ✅ No architectural changes - ✅ Addresses security concern (ASLR bypass potential) - ✅ Follows established patterns for ACPICA fixes - ✅ Critical kernel subsystem (ACPI) **8. Historical Precedent**: The similar commits in the reference examples (Similar Commits #1, #2, #3) all have "Backport Status: YES" and address nearly identical ACPICA operand cache leak issues with similar fixes and commit message patterns. This commit meets all criteria for stable tree backporting: it's an important bugfix, has minimal regression risk, affects a critical subsystem, and follows established patterns for similar fixes that were previously backported. drivers/acpi/acpica/dsutils.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/dsutils.c b/drivers/acpi/acpica/dsutils.c index fb9ed5e1da89d..2bdae8a25e084 100644 --- a/drivers/acpi/acpica/dsutils.c +++ b/drivers/acpi/acpica/dsutils.c @@ -668,6 +668,8 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, union acpi_parse_object *arguments[ACPI_OBJ_NUM_OPERANDS]; u32 arg_count = 0; u32 index = walk_state->num_operands; + u32 prev_num_operands = walk_state->num_operands; + u32 new_num_operands; u32 i; ACPI_FUNCTION_TRACE_PTR(ds_create_operands, first_arg); @@ -696,6 +698,7 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, /* Create the interpreter arguments, in reverse order */ + new_num_operands = index; index--; for (i = 0; i < arg_count; i++) { arg = arguments[index]; @@ -720,7 +723,11 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, * pop everything off of the operand stack and delete those * objects */ - acpi_ds_obj_stack_pop_and_delete(arg_count, walk_state); + walk_state->num_operands = i; + acpi_ds_obj_stack_pop_and_delete(new_num_operands, walk_state); + + /* Restore operand count */ + walk_state->num_operands = prev_num_operands; ACPI_EXCEPTION((AE_INFO, status, "While creating Arg %u", index)); return_ACPI_STATUS(status); -- 2.39.5

5 months, 1 week

1
5
0 0

[PATCH AUTOSEL 5.10 01/10] ACPICA: fix acpi operand cache leak in dswstate.c

by Sasha Levin

From: Seunghun Han <kkamagui(a)gmail.com> [ Upstream commit 156fd20a41e776bbf334bd5e45c4f78dfc90ce1c ] ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Link: https://github.com/acpica/acpica/commit/987a3b5c Signed-off-by: Seunghun Han <kkamagui(a)gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Link: https://patch.msgid.link/4999480.31r3eYUQgx@rjwysocki.net Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees based on the following analysis: ## Analysis of the Commit **1. Bug Fix Nature**: This commit fixes a clear memory leak bug in the ACPICA subsystem. The issue occurs when `acpi_ds_create_operands()` encounters an error during operand creation and needs to clean up allocated operands. **2. Root Cause**: The core issue is a mismatch between how operands are pushed and popped from the stack: - `acpi_ds_obj_stack_push()` uses `walk_state->operand_index` to track the current position - `acpi_ds_obj_stack_pop_and_delete()` incorrectly assumes operands start at index 0 - This causes incomplete cleanup when errors occur, leading to memory leaks **3. Code Analysis**: The fix correctly addresses the issue by: - Tracking the original operand count (`prev_num_operands`) - Calculating the correct number of operands to clean up (`new_num_operands`) - Setting `walk_state->num_operands = i` before cleanup to ensure proper indexing - Restoring the original operand count after cleanup **4. Security Implications**: The commit message explicitly mentions this is a security issue - the memory leak can expose kernel function addresses in older kernels (≤4.9), potentially defeating ASLR. This elevates the importance beyond a simple memory leak. **5. Pattern Consistency**: This follows the exact same pattern as other ACPICA operand cache leak fixes that were successfully backported (commits `97f3c0a4b057`, `2915f16bdce2`, etc.), all authored by the same developer addressing similar issues. **6. Stability Characteristics**: - **Small and contained**: Only 8 lines of actual logic changes - **Clear error path**: Only affects cleanup during error conditions - **No behavioral changes**: No impact on normal operation - **Low regression risk**: Only modifies error handling paths **7. Backport Suitability Criteria**: - ✅ Fixes important bug affecting users (memory leak) - ✅ Small, contained fix with minimal risk - ✅ No architectural changes - ✅ Addresses security concern (ASLR bypass potential) - ✅ Follows established patterns for ACPICA fixes - ✅ Critical kernel subsystem (ACPI) **8. Historical Precedent**: The similar commits in the reference examples (Similar Commits #1, #2, #3) all have "Backport Status: YES" and address nearly identical ACPICA operand cache leak issues with similar fixes and commit message patterns. This commit meets all criteria for stable tree backporting: it's an important bugfix, has minimal regression risk, affects a critical subsystem, and follows established patterns for similar fixes that were previously backported. drivers/acpi/acpica/dsutils.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/dsutils.c b/drivers/acpi/acpica/dsutils.c index fb9ed5e1da89d..2bdae8a25e084 100644 --- a/drivers/acpi/acpica/dsutils.c +++ b/drivers/acpi/acpica/dsutils.c @@ -668,6 +668,8 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, union acpi_parse_object *arguments[ACPI_OBJ_NUM_OPERANDS]; u32 arg_count = 0; u32 index = walk_state->num_operands; + u32 prev_num_operands = walk_state->num_operands; + u32 new_num_operands; u32 i; ACPI_FUNCTION_TRACE_PTR(ds_create_operands, first_arg); @@ -696,6 +698,7 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, /* Create the interpreter arguments, in reverse order */ + new_num_operands = index; index--; for (i = 0; i < arg_count; i++) { arg = arguments[index]; @@ -720,7 +723,11 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, * pop everything off of the operand stack and delete those * objects */ - acpi_ds_obj_stack_pop_and_delete(arg_count, walk_state); + walk_state->num_operands = i; + acpi_ds_obj_stack_pop_and_delete(new_num_operands, walk_state); + + /* Restore operand count */ + walk_state->num_operands = prev_num_operands; ACPI_EXCEPTION((AE_INFO, status, "While creating Arg %u", index)); return_ACPI_STATUS(status); -- 2.39.5

5 months, 1 week

1
9
0 0

[PATCH AUTOSEL 5.15 01/11] ACPICA: fix acpi operand cache leak in dswstate.c

by Sasha Levin

From: Seunghun Han <kkamagui(a)gmail.com> [ Upstream commit 156fd20a41e776bbf334bd5e45c4f78dfc90ce1c ] ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Link: https://github.com/acpica/acpica/commit/987a3b5c Signed-off-by: Seunghun Han <kkamagui(a)gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Link: https://patch.msgid.link/4999480.31r3eYUQgx@rjwysocki.net Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees based on the following analysis: ## Analysis of the Commit **1. Bug Fix Nature**: This commit fixes a clear memory leak bug in the ACPICA subsystem. The issue occurs when `acpi_ds_create_operands()` encounters an error during operand creation and needs to clean up allocated operands. **2. Root Cause**: The core issue is a mismatch between how operands are pushed and popped from the stack: - `acpi_ds_obj_stack_push()` uses `walk_state->operand_index` to track the current position - `acpi_ds_obj_stack_pop_and_delete()` incorrectly assumes operands start at index 0 - This causes incomplete cleanup when errors occur, leading to memory leaks **3. Code Analysis**: The fix correctly addresses the issue by: - Tracking the original operand count (`prev_num_operands`) - Calculating the correct number of operands to clean up (`new_num_operands`) - Setting `walk_state->num_operands = i` before cleanup to ensure proper indexing - Restoring the original operand count after cleanup **4. Security Implications**: The commit message explicitly mentions this is a security issue - the memory leak can expose kernel function addresses in older kernels (≤4.9), potentially defeating ASLR. This elevates the importance beyond a simple memory leak. **5. Pattern Consistency**: This follows the exact same pattern as other ACPICA operand cache leak fixes that were successfully backported (commits `97f3c0a4b057`, `2915f16bdce2`, etc.), all authored by the same developer addressing similar issues. **6. Stability Characteristics**: - **Small and contained**: Only 8 lines of actual logic changes - **Clear error path**: Only affects cleanup during error conditions - **No behavioral changes**: No impact on normal operation - **Low regression risk**: Only modifies error handling paths **7. Backport Suitability Criteria**: - ✅ Fixes important bug affecting users (memory leak) - ✅ Small, contained fix with minimal risk - ✅ No architectural changes - ✅ Addresses security concern (ASLR bypass potential) - ✅ Follows established patterns for ACPICA fixes - ✅ Critical kernel subsystem (ACPI) **8. Historical Precedent**: The similar commits in the reference examples (Similar Commits #1, #2, #3) all have "Backport Status: YES" and address nearly identical ACPICA operand cache leak issues with similar fixes and commit message patterns. This commit meets all criteria for stable tree backporting: it's an important bugfix, has minimal regression risk, affects a critical subsystem, and follows established patterns for similar fixes that were previously backported. drivers/acpi/acpica/dsutils.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/dsutils.c b/drivers/acpi/acpica/dsutils.c index fb9ed5e1da89d..2bdae8a25e084 100644 --- a/drivers/acpi/acpica/dsutils.c +++ b/drivers/acpi/acpica/dsutils.c @@ -668,6 +668,8 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, union acpi_parse_object *arguments[ACPI_OBJ_NUM_OPERANDS]; u32 arg_count = 0; u32 index = walk_state->num_operands; + u32 prev_num_operands = walk_state->num_operands; + u32 new_num_operands; u32 i; ACPI_FUNCTION_TRACE_PTR(ds_create_operands, first_arg); @@ -696,6 +698,7 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, /* Create the interpreter arguments, in reverse order */ + new_num_operands = index; index--; for (i = 0; i < arg_count; i++) { arg = arguments[index]; @@ -720,7 +723,11 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, * pop everything off of the operand stack and delete those * objects */ - acpi_ds_obj_stack_pop_and_delete(arg_count, walk_state); + walk_state->num_operands = i; + acpi_ds_obj_stack_pop_and_delete(new_num_operands, walk_state); + + /* Restore operand count */ + walk_state->num_operands = prev_num_operands; ACPI_EXCEPTION((AE_INFO, status, "While creating Arg %u", index)); return_ACPI_STATUS(status); -- 2.39.5

5 months, 1 week

1
10
0 0

[PATCH AUTOSEL 6.1 01/13] ACPICA: fix acpi operand cache leak in dswstate.c

by Sasha Levin

From: Seunghun Han <kkamagui(a)gmail.com> [ Upstream commit 156fd20a41e776bbf334bd5e45c4f78dfc90ce1c ] ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Link: https://github.com/acpica/acpica/commit/987a3b5c Signed-off-by: Seunghun Han <kkamagui(a)gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Link: https://patch.msgid.link/4999480.31r3eYUQgx@rjwysocki.net Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees based on the following analysis: ## Analysis of the Commit **1. Bug Fix Nature**: This commit fixes a clear memory leak bug in the ACPICA subsystem. The issue occurs when `acpi_ds_create_operands()` encounters an error during operand creation and needs to clean up allocated operands. **2. Root Cause**: The core issue is a mismatch between how operands are pushed and popped from the stack: - `acpi_ds_obj_stack_push()` uses `walk_state->operand_index` to track the current position - `acpi_ds_obj_stack_pop_and_delete()` incorrectly assumes operands start at index 0 - This causes incomplete cleanup when errors occur, leading to memory leaks **3. Code Analysis**: The fix correctly addresses the issue by: - Tracking the original operand count (`prev_num_operands`) - Calculating the correct number of operands to clean up (`new_num_operands`) - Setting `walk_state->num_operands = i` before cleanup to ensure proper indexing - Restoring the original operand count after cleanup **4. Security Implications**: The commit message explicitly mentions this is a security issue - the memory leak can expose kernel function addresses in older kernels (≤4.9), potentially defeating ASLR. This elevates the importance beyond a simple memory leak. **5. Pattern Consistency**: This follows the exact same pattern as other ACPICA operand cache leak fixes that were successfully backported (commits `97f3c0a4b057`, `2915f16bdce2`, etc.), all authored by the same developer addressing similar issues. **6. Stability Characteristics**: - **Small and contained**: Only 8 lines of actual logic changes - **Clear error path**: Only affects cleanup during error conditions - **No behavioral changes**: No impact on normal operation - **Low regression risk**: Only modifies error handling paths **7. Backport Suitability Criteria**: - ✅ Fixes important bug affecting users (memory leak) - ✅ Small, contained fix with minimal risk - ✅ No architectural changes - ✅ Addresses security concern (ASLR bypass potential) - ✅ Follows established patterns for ACPICA fixes - ✅ Critical kernel subsystem (ACPI) **8. Historical Precedent**: The similar commits in the reference examples (Similar Commits #1, #2, #3) all have "Backport Status: YES" and address nearly identical ACPICA operand cache leak issues with similar fixes and commit message patterns. This commit meets all criteria for stable tree backporting: it's an important bugfix, has minimal regression risk, affects a critical subsystem, and follows established patterns for similar fixes that were previously backported. drivers/acpi/acpica/dsutils.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/dsutils.c b/drivers/acpi/acpica/dsutils.c index fb9ed5e1da89d..2bdae8a25e084 100644 --- a/drivers/acpi/acpica/dsutils.c +++ b/drivers/acpi/acpica/dsutils.c @@ -668,6 +668,8 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, union acpi_parse_object *arguments[ACPI_OBJ_NUM_OPERANDS]; u32 arg_count = 0; u32 index = walk_state->num_operands; + u32 prev_num_operands = walk_state->num_operands; + u32 new_num_operands; u32 i; ACPI_FUNCTION_TRACE_PTR(ds_create_operands, first_arg); @@ -696,6 +698,7 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, /* Create the interpreter arguments, in reverse order */ + new_num_operands = index; index--; for (i = 0; i < arg_count; i++) { arg = arguments[index]; @@ -720,7 +723,11 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, * pop everything off of the operand stack and delete those * objects */ - acpi_ds_obj_stack_pop_and_delete(arg_count, walk_state); + walk_state->num_operands = i; + acpi_ds_obj_stack_pop_and_delete(new_num_operands, walk_state); + + /* Restore operand count */ + walk_state->num_operands = prev_num_operands; ACPI_EXCEPTION((AE_INFO, status, "While creating Arg %u", index)); return_ACPI_STATUS(status); -- 2.39.5

5 months, 1 week

1
12
0 0

[PATCH AUTOSEL 6.6 01/18] ACPICA: fix acpi operand cache leak in dswstate.c

by Sasha Levin

From: Seunghun Han <kkamagui(a)gmail.com> [ Upstream commit 156fd20a41e776bbf334bd5e45c4f78dfc90ce1c ] ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Link: https://github.com/acpica/acpica/commit/987a3b5c Signed-off-by: Seunghun Han <kkamagui(a)gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Link: https://patch.msgid.link/4999480.31r3eYUQgx@rjwysocki.net Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees based on the following analysis: ## Analysis of the Commit **1. Bug Fix Nature**: This commit fixes a clear memory leak bug in the ACPICA subsystem. The issue occurs when `acpi_ds_create_operands()` encounters an error during operand creation and needs to clean up allocated operands. **2. Root Cause**: The core issue is a mismatch between how operands are pushed and popped from the stack: - `acpi_ds_obj_stack_push()` uses `walk_state->operand_index` to track the current position - `acpi_ds_obj_stack_pop_and_delete()` incorrectly assumes operands start at index 0 - This causes incomplete cleanup when errors occur, leading to memory leaks **3. Code Analysis**: The fix correctly addresses the issue by: - Tracking the original operand count (`prev_num_operands`) - Calculating the correct number of operands to clean up (`new_num_operands`) - Setting `walk_state->num_operands = i` before cleanup to ensure proper indexing - Restoring the original operand count after cleanup **4. Security Implications**: The commit message explicitly mentions this is a security issue - the memory leak can expose kernel function addresses in older kernels (≤4.9), potentially defeating ASLR. This elevates the importance beyond a simple memory leak. **5. Pattern Consistency**: This follows the exact same pattern as other ACPICA operand cache leak fixes that were successfully backported (commits `97f3c0a4b057`, `2915f16bdce2`, etc.), all authored by the same developer addressing similar issues. **6. Stability Characteristics**: - **Small and contained**: Only 8 lines of actual logic changes - **Clear error path**: Only affects cleanup during error conditions - **No behavioral changes**: No impact on normal operation - **Low regression risk**: Only modifies error handling paths **7. Backport Suitability Criteria**: - ✅ Fixes important bug affecting users (memory leak) - ✅ Small, contained fix with minimal risk - ✅ No architectural changes - ✅ Addresses security concern (ASLR bypass potential) - ✅ Follows established patterns for ACPICA fixes - ✅ Critical kernel subsystem (ACPI) **8. Historical Precedent**: The similar commits in the reference examples (Similar Commits #1, #2, #3) all have "Backport Status: YES" and address nearly identical ACPICA operand cache leak issues with similar fixes and commit message patterns. This commit meets all criteria for stable tree backporting: it's an important bugfix, has minimal regression risk, affects a critical subsystem, and follows established patterns for similar fixes that were previously backported. drivers/acpi/acpica/dsutils.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/dsutils.c b/drivers/acpi/acpica/dsutils.c index fb9ed5e1da89d..2bdae8a25e084 100644 --- a/drivers/acpi/acpica/dsutils.c +++ b/drivers/acpi/acpica/dsutils.c @@ -668,6 +668,8 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, union acpi_parse_object *arguments[ACPI_OBJ_NUM_OPERANDS]; u32 arg_count = 0; u32 index = walk_state->num_operands; + u32 prev_num_operands = walk_state->num_operands; + u32 new_num_operands; u32 i; ACPI_FUNCTION_TRACE_PTR(ds_create_operands, first_arg); @@ -696,6 +698,7 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, /* Create the interpreter arguments, in reverse order */ + new_num_operands = index; index--; for (i = 0; i < arg_count; i++) { arg = arguments[index]; @@ -720,7 +723,11 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, * pop everything off of the operand stack and delete those * objects */ - acpi_ds_obj_stack_pop_and_delete(arg_count, walk_state); + walk_state->num_operands = i; + acpi_ds_obj_stack_pop_and_delete(new_num_operands, walk_state); + + /* Restore operand count */ + walk_state->num_operands = prev_num_operands; ACPI_EXCEPTION((AE_INFO, status, "While creating Arg %u", index)); return_ACPI_STATUS(status); -- 2.39.5

5 months, 1 week

1
17
0 0

[PATCH AUTOSEL 6.12 01/26] ACPICA: fix acpi operand cache leak in dswstate.c

by Sasha Levin

From: Seunghun Han <kkamagui(a)gmail.com> [ Upstream commit 156fd20a41e776bbf334bd5e45c4f78dfc90ce1c ] ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Link: https://github.com/acpica/acpica/commit/987a3b5c Signed-off-by: Seunghun Han <kkamagui(a)gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Link: https://patch.msgid.link/4999480.31r3eYUQgx@rjwysocki.net Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees based on the following analysis: ## Analysis of the Commit **1. Bug Fix Nature**: This commit fixes a clear memory leak bug in the ACPICA subsystem. The issue occurs when `acpi_ds_create_operands()` encounters an error during operand creation and needs to clean up allocated operands. **2. Root Cause**: The core issue is a mismatch between how operands are pushed and popped from the stack: - `acpi_ds_obj_stack_push()` uses `walk_state->operand_index` to track the current position - `acpi_ds_obj_stack_pop_and_delete()` incorrectly assumes operands start at index 0 - This causes incomplete cleanup when errors occur, leading to memory leaks **3. Code Analysis**: The fix correctly addresses the issue by: - Tracking the original operand count (`prev_num_operands`) - Calculating the correct number of operands to clean up (`new_num_operands`) - Setting `walk_state->num_operands = i` before cleanup to ensure proper indexing - Restoring the original operand count after cleanup **4. Security Implications**: The commit message explicitly mentions this is a security issue - the memory leak can expose kernel function addresses in older kernels (≤4.9), potentially defeating ASLR. This elevates the importance beyond a simple memory leak. **5. Pattern Consistency**: This follows the exact same pattern as other ACPICA operand cache leak fixes that were successfully backported (commits `97f3c0a4b057`, `2915f16bdce2`, etc.), all authored by the same developer addressing similar issues. **6. Stability Characteristics**: - **Small and contained**: Only 8 lines of actual logic changes - **Clear error path**: Only affects cleanup during error conditions - **No behavioral changes**: No impact on normal operation - **Low regression risk**: Only modifies error handling paths **7. Backport Suitability Criteria**: - ✅ Fixes important bug affecting users (memory leak) - ✅ Small, contained fix with minimal risk - ✅ No architectural changes - ✅ Addresses security concern (ASLR bypass potential) - ✅ Follows established patterns for ACPICA fixes - ✅ Critical kernel subsystem (ACPI) **8. Historical Precedent**: The similar commits in the reference examples (Similar Commits #1, #2, #3) all have "Backport Status: YES" and address nearly identical ACPICA operand cache leak issues with similar fixes and commit message patterns. This commit meets all criteria for stable tree backporting: it's an important bugfix, has minimal regression risk, affects a critical subsystem, and follows established patterns for similar fixes that were previously backported. drivers/acpi/acpica/dsutils.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/dsutils.c b/drivers/acpi/acpica/dsutils.c index fb9ed5e1da89d..2bdae8a25e084 100644 --- a/drivers/acpi/acpica/dsutils.c +++ b/drivers/acpi/acpica/dsutils.c @@ -668,6 +668,8 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, union acpi_parse_object *arguments[ACPI_OBJ_NUM_OPERANDS]; u32 arg_count = 0; u32 index = walk_state->num_operands; + u32 prev_num_operands = walk_state->num_operands; + u32 new_num_operands; u32 i; ACPI_FUNCTION_TRACE_PTR(ds_create_operands, first_arg); @@ -696,6 +698,7 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, /* Create the interpreter arguments, in reverse order */ + new_num_operands = index; index--; for (i = 0; i < arg_count; i++) { arg = arguments[index]; @@ -720,7 +723,11 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, * pop everything off of the operand stack and delete those * objects */ - acpi_ds_obj_stack_pop_and_delete(arg_count, walk_state); + walk_state->num_operands = i; + acpi_ds_obj_stack_pop_and_delete(new_num_operands, walk_state); + + /* Restore operand count */ + walk_state->num_operands = prev_num_operands; ACPI_EXCEPTION((AE_INFO, status, "While creating Arg %u", index)); return_ACPI_STATUS(status); -- 2.39.5

5 months, 1 week

1
25
0 0

[PATCH AUTOSEL 6.14 01/28] ACPICA: fix acpi operand cache leak in dswstate.c

by Sasha Levin

From: Seunghun Han <kkamagui(a)gmail.com> [ Upstream commit 156fd20a41e776bbf334bd5e45c4f78dfc90ce1c ] ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Link: https://github.com/acpica/acpica/commit/987a3b5c Signed-off-by: Seunghun Han <kkamagui(a)gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Link: https://patch.msgid.link/4999480.31r3eYUQgx@rjwysocki.net Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees based on the following analysis: ## Analysis of the Commit **1. Bug Fix Nature**: This commit fixes a clear memory leak bug in the ACPICA subsystem. The issue occurs when `acpi_ds_create_operands()` encounters an error during operand creation and needs to clean up allocated operands. **2. Root Cause**: The core issue is a mismatch between how operands are pushed and popped from the stack: - `acpi_ds_obj_stack_push()` uses `walk_state->operand_index` to track the current position - `acpi_ds_obj_stack_pop_and_delete()` incorrectly assumes operands start at index 0 - This causes incomplete cleanup when errors occur, leading to memory leaks **3. Code Analysis**: The fix correctly addresses the issue by: - Tracking the original operand count (`prev_num_operands`) - Calculating the correct number of operands to clean up (`new_num_operands`) - Setting `walk_state->num_operands = i` before cleanup to ensure proper indexing - Restoring the original operand count after cleanup **4. Security Implications**: The commit message explicitly mentions this is a security issue - the memory leak can expose kernel function addresses in older kernels (≤4.9), potentially defeating ASLR. This elevates the importance beyond a simple memory leak. **5. Pattern Consistency**: This follows the exact same pattern as other ACPICA operand cache leak fixes that were successfully backported (commits `97f3c0a4b057`, `2915f16bdce2`, etc.), all authored by the same developer addressing similar issues. **6. Stability Characteristics**: - **Small and contained**: Only 8 lines of actual logic changes - **Clear error path**: Only affects cleanup during error conditions - **No behavioral changes**: No impact on normal operation - **Low regression risk**: Only modifies error handling paths **7. Backport Suitability Criteria**: - ✅ Fixes important bug affecting users (memory leak) - ✅ Small, contained fix with minimal risk - ✅ No architectural changes - ✅ Addresses security concern (ASLR bypass potential) - ✅ Follows established patterns for ACPICA fixes - ✅ Critical kernel subsystem (ACPI) **8. Historical Precedent**: The similar commits in the reference examples (Similar Commits #1, #2, #3) all have "Backport Status: YES" and address nearly identical ACPICA operand cache leak issues with similar fixes and commit message patterns. This commit meets all criteria for stable tree backporting: it's an important bugfix, has minimal regression risk, affects a critical subsystem, and follows established patterns for similar fixes that were previously backported. drivers/acpi/acpica/dsutils.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/dsutils.c b/drivers/acpi/acpica/dsutils.c index fb9ed5e1da89d..2bdae8a25e084 100644 --- a/drivers/acpi/acpica/dsutils.c +++ b/drivers/acpi/acpica/dsutils.c @@ -668,6 +668,8 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, union acpi_parse_object *arguments[ACPI_OBJ_NUM_OPERANDS]; u32 arg_count = 0; u32 index = walk_state->num_operands; + u32 prev_num_operands = walk_state->num_operands; + u32 new_num_operands; u32 i; ACPI_FUNCTION_TRACE_PTR(ds_create_operands, first_arg); @@ -696,6 +698,7 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, /* Create the interpreter arguments, in reverse order */ + new_num_operands = index; index--; for (i = 0; i < arg_count; i++) { arg = arguments[index]; @@ -720,7 +723,11 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, * pop everything off of the operand stack and delete those * objects */ - acpi_ds_obj_stack_pop_and_delete(arg_count, walk_state); + walk_state->num_operands = i; + acpi_ds_obj_stack_pop_and_delete(new_num_operands, walk_state); + + /* Restore operand count */ + walk_state->num_operands = prev_num_operands; ACPI_EXCEPTION((AE_INFO, status, "While creating Arg %u", index)); return_ACPI_STATUS(status); -- 2.39.5

5 months, 1 week

1
27
0 0

[PATCH AUTOSEL 6.15 01/30] ACPICA: fix acpi operand cache leak in dswstate.c

by Sasha Levin

From: Seunghun Han <kkamagui(a)gmail.com> [ Upstream commit 156fd20a41e776bbf334bd5e45c4f78dfc90ce1c ] ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Link: https://github.com/acpica/acpica/commit/987a3b5c Signed-off-by: Seunghun Han <kkamagui(a)gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Link: https://patch.msgid.link/4999480.31r3eYUQgx@rjwysocki.net Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees based on the following analysis: ## Analysis of the Commit **1. Bug Fix Nature**: This commit fixes a clear memory leak bug in the ACPICA subsystem. The issue occurs when `acpi_ds_create_operands()` encounters an error during operand creation and needs to clean up allocated operands. **2. Root Cause**: The core issue is a mismatch between how operands are pushed and popped from the stack: - `acpi_ds_obj_stack_push()` uses `walk_state->operand_index` to track the current position - `acpi_ds_obj_stack_pop_and_delete()` incorrectly assumes operands start at index 0 - This causes incomplete cleanup when errors occur, leading to memory leaks **3. Code Analysis**: The fix correctly addresses the issue by: - Tracking the original operand count (`prev_num_operands`) - Calculating the correct number of operands to clean up (`new_num_operands`) - Setting `walk_state->num_operands = i` before cleanup to ensure proper indexing - Restoring the original operand count after cleanup **4. Security Implications**: The commit message explicitly mentions this is a security issue - the memory leak can expose kernel function addresses in older kernels (≤4.9), potentially defeating ASLR. This elevates the importance beyond a simple memory leak. **5. Pattern Consistency**: This follows the exact same pattern as other ACPICA operand cache leak fixes that were successfully backported (commits `97f3c0a4b057`, `2915f16bdce2`, etc.), all authored by the same developer addressing similar issues. **6. Stability Characteristics**: - **Small and contained**: Only 8 lines of actual logic changes - **Clear error path**: Only affects cleanup during error conditions - **No behavioral changes**: No impact on normal operation - **Low regression risk**: Only modifies error handling paths **7. Backport Suitability Criteria**: - ✅ Fixes important bug affecting users (memory leak) - ✅ Small, contained fix with minimal risk - ✅ No architectural changes - ✅ Addresses security concern (ASLR bypass potential) - ✅ Follows established patterns for ACPICA fixes - ✅ Critical kernel subsystem (ACPI) **8. Historical Precedent**: The similar commits in the reference examples (Similar Commits #1, #2, #3) all have "Backport Status: YES" and address nearly identical ACPICA operand cache leak issues with similar fixes and commit message patterns. This commit meets all criteria for stable tree backporting: it's an important bugfix, has minimal regression risk, affects a critical subsystem, and follows established patterns for similar fixes that were previously backported. drivers/acpi/acpica/dsutils.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/dsutils.c b/drivers/acpi/acpica/dsutils.c index fb9ed5e1da89d..2bdae8a25e084 100644 --- a/drivers/acpi/acpica/dsutils.c +++ b/drivers/acpi/acpica/dsutils.c @@ -668,6 +668,8 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, union acpi_parse_object *arguments[ACPI_OBJ_NUM_OPERANDS]; u32 arg_count = 0; u32 index = walk_state->num_operands; + u32 prev_num_operands = walk_state->num_operands; + u32 new_num_operands; u32 i; ACPI_FUNCTION_TRACE_PTR(ds_create_operands, first_arg); @@ -696,6 +698,7 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, /* Create the interpreter arguments, in reverse order */ + new_num_operands = index; index--; for (i = 0; i < arg_count; i++) { arg = arguments[index]; @@ -720,7 +723,11 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, * pop everything off of the operand stack and delete those * objects */ - acpi_ds_obj_stack_pop_and_delete(arg_count, walk_state); + walk_state->num_operands = i; + acpi_ds_obj_stack_pop_and_delete(new_num_operands, walk_state); + + /* Restore operand count */ + walk_state->num_operands = prev_num_operands; ACPI_EXCEPTION((AE_INFO, status, "While creating Arg %u", index)); return_ACPI_STATUS(status); -- 2.39.5

5 months, 1 week

1
29
0 0

[PATCH v2] mmc: sdhci-omap: Add error handling for sdhci_runtime_suspend_host()

by Wentao Liang

The sdhci_omap_runtime_suspend() calls sdhci_runtime_suspend_host() but does not handle the return value. A proper implementation can be found in sdhci_am654_runtime_suspend(). Add error handling for sdhci_runtime_suspend_host(). Return the error code if the suspend fails. Fixes: 51189eb9ddc8 ("mmc: sdhci-omap: Fix a lockdep warning for PM runtime init") Cc: stable(a)vger.kernel.org # 5.19 Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- v2: Fix code error. drivers/mmc/host/sdhci-omap.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c index 54d795205fb4..f09f78cf244d 100644 --- a/drivers/mmc/host/sdhci-omap.c +++ b/drivers/mmc/host/sdhci-omap.c @@ -1438,12 +1438,16 @@ static int __maybe_unused sdhci_omap_runtime_suspend(struct device *dev) struct sdhci_host *host = dev_get_drvdata(dev); struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host); + int ret; if (host->tuning_mode != SDHCI_TUNING_MODE_3) mmc_retune_needed(host->mmc); - if (omap_host->con != -EINVAL) - sdhci_runtime_suspend_host(host); + if (omap_host->con != -EINVAL) { + ret = sdhci_runtime_suspend_host(host); + if (ret) + return ret; + } sdhci_omap_context_save(omap_host); -- 2.42.0.windows.2

5 months, 1 week

2
1
0 0

[PATCH] mmc: sdhci-sprd: Add error handling for sdhci_runtime_suspend_host()

by Wentao Liang

The dhci_sprd_runtime_suspend() calls sdhci_runtime_suspend_host() but does not handle the return value. A proper implementation can be found in sdhci_am654_runtime_suspend(). Add error handling for sdhci_runtime_suspend_host(). Return the error code if the suspend fails. Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller") Cc: stable(a)vger.kernel.org # v4.20 Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- drivers/mmc/host/sdhci-sprd.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/sdhci-sprd.c b/drivers/mmc/host/sdhci-sprd.c index db5e253b0f79..dd41427e973a 100644 --- a/drivers/mmc/host/sdhci-sprd.c +++ b/drivers/mmc/host/sdhci-sprd.c @@ -922,9 +922,12 @@ static int sdhci_sprd_runtime_suspend(struct device *dev) { struct sdhci_host *host = dev_get_drvdata(dev); struct sdhci_sprd_host *sprd_host = TO_SPRD_HOST(host); + int ret; mmc_hsq_suspend(host->mmc); - sdhci_runtime_suspend_host(host); + ret = sdhci_runtime_suspend_host(host); + if (ret) + return ret; clk_disable_unprepare(sprd_host->clk_sdio); clk_disable_unprepare(sprd_host->clk_enable); -- 2.42.0.windows.2

5 months, 1 week

3
2
0 0

Unlock CWIEME Berlin 2025 Attendee List!

by Garnet Conwell

Hi, We’re thrilled to give you exclusive access to the CWIEME Berlin 2025 Visitor Contact List! This database includes 8,678 verified visitor contacts and 550 exhibitor contacts, each with detailed Each contact contains: Contact name, Job Title, Business Name, Physical Address, Phone Numbers, Official Email address and many more. Limited-Time Offer: Get 20% OFF – Valid only until May 31st. Interested? Simply reply with “Send me pricing” to receive more details. Kind regards, Garnet Conwell Sr. Marketing Manager P.S. Don’t want to receive these updates? Just reply with “Unfollow.”

5 months, 1 week

1
0
0 0

[PATCH 5.15 00/59] 5.15.184-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.15.184 release. There are 59 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu, 22 May 2025 12:57:37 +0000. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.184-r… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 5.15.184-rc1 Alexander Lobakin <alexandr.lobakin(a)intel.com> ice: arfs: fix use-after-free when freeing @rx_cpu_rmap Florian Westphal <fw(a)strlen.de> netfilter: nf_tables: do not defer rule destruction via call_rcu Pablo Neira Ayuso <pablo(a)netfilter.org> netfilter: nf_tables: wait for rcu grace period on net_device removal Florian Westphal <fw(a)strlen.de> netfilter: nf_tables: pass nft_chain to destroy function, not nft_ctx Josef Bacik <josef(a)toxicpanda.com> btrfs: do not clean up repair bio if submit fails Filipe Manana <fdmanana(a)suse.com> btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info() Eric Dumazet <edumazet(a)google.com> sctp: add mutual exclusion in proc_sctp_do_udp_port() Feng Tang <feng.tang(a)linux.alibaba.com> selftests/mm: compaction_test: support platform with huge mount of memory GONG Ruiqi <gongruiqi1(a)huawei.com> usb: typec: fix pm usage counter imbalance in ucsi_ccg_sync_control() Dan Carpenter <dan.carpenter(a)linaro.org> usb: typec: fix potential array underflow in ucsi_ccg_sync_control() RD Babiera <rdbabiera(a)google.com> usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group Andrei Kuchynski <akuchynski(a)chromium.org> usb: typec: ucsi: displayport: Fix deadlock Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> clocksource/i8253: Use raw_spinlock_irqsave() in clockevent_i8253_disable() Fengnan Chang <changfengnan(a)bytedance.com> block: fix direct io NOWAIT flag not work Shuai Xue <xueshuai(a)linux.alibaba.com> dmaengine: idxd: fix memory leak in error handling path of idxd_setup_groups Shuai Xue <xueshuai(a)linux.alibaba.com> dmaengine: idxd: fix memory leak in error handling path of idxd_setup_engines Yemike Abhilash Chandra <y-abhilashchandra(a)ti.com> dmaengine: ti: k3-udma: Use cap_mask directly from dma_device structure instead of a local copy Ronald Wahl <ronald.wahl(a)legrand.com> dmaengine: ti: k3-udma: Add missing locking Fedor Pchelkin <pchelkin(a)ispras.ru> wifi: mt76: disable napi on driver removal Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> phy: renesas: rcar-gen3-usb2: Set timing registers only once Ma Ke <make24(a)iscas.ac.cn> phy: Fix error handling in tegra_xusb_port_init Steven Rostedt <rostedt(a)goodmis.org> tracing: samples: Initialize trace_array_printk() with the correct function pengdonglin <pengdonglin(a)xiaomi.com> ftrace: Fix preemption accounting for stacktrace filter command pengdonglin <pengdonglin(a)xiaomi.com> ftrace: Fix preemption accounting for stacktrace trigger command Nicolas Chauvet <kwizart(a)gmail.com> ALSA: usb-audio: Add sample rate quirk for Microdia JP001 USB Camera Christian Heusel <christian(a)heusel.eu> ALSA: usb-audio: Add sample rate quirk for Audioengine D1 Wentao Liang <vulab(a)iscas.ac.cn> ALSA: es1968: Add error handling for snd_pcm_hw_constraint_pow2() Jeremy Linton <jeremy.linton(a)arm.com> ACPI: PPTT: Fix processor subtable walk Filipe Manana <fdmanana(a)suse.com> btrfs: fix discard worker infinite loop after disabling discard Nathan Lynch <nathan.lynch(a)amd.com> dmaengine: Revert "dmaengine: dmatest: Fix dmatest waiting less when interrupted" Peter Zijlstra <peterz(a)infradead.org> x86/its: FineIBT-paranoid vs ITS Eric Biggers <ebiggers(a)google.com> x86/its: Fix build errors when CONFIG_MODULES=n Peter Zijlstra <peterz(a)infradead.org> x86/its: Use dynamic thunks for indirect branches Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/its: Align RETs in BHB clear sequence to avoid thunking Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/its: Add "vmexit" option to skip mitigation on some CPUs Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/its: Enable Indirect Target Selection mitigation Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/its: Add support for ITS-safe return thunk Josh Poimboeuf <jpoimboe(a)kernel.org> x86/alternatives: Remove faulty optimization Borislav Petkov (AMD) <bp(a)alien8.de> x86/alternative: Optimize returns patching Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/its: Add support for ITS-safe indirect thunk Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/its: Enumerate Indirect Target Selection (ITS) bug Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> Documentation: x86/bugs/its: Add ITS documentation Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/speculation: Remove the extra #ifdef around CALL_NOSPEC Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/speculation: Add a conditional CS prefix to CALL_NOSPEC Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com> x86/speculation: Simplify and make CALL_NOSPEC consistent Peter Zijlstra <peterz(a)infradead.org> x86,nospec: Simplify {JMP,CALL}_NOSPEC Trond Myklebust <trond.myklebust(a)hammerspace.com> NFSv4/pnfs: Reset the layout state after a layoutreturn Abdun Nihaal <abdun.nihaal(a)gmail.com> qlcnic: fix memory leak in qlcnic_sriov_channel_cfg_cmd() Geert Uytterhoeven <geert+renesas(a)glider.be> ALSA: sh: SND_AICA should depend on SH_DMA_API Vladimir Oltean <vladimir.oltean(a)nxp.com> net: dsa: sja1105: discard incoming frames in BR_STATE_LISTENING Mathieu Othacehe <othacehe(a)gnu.org> net: cadence: macb: Fix a possible deadlock in macb_halt_tx. Cong Wang <xiyou.wangcong(a)gmail.com> net_sched: Flush gso_skb list too during ->change() Geert Uytterhoeven <geert+renesas(a)glider.be> spi: loopback-test: Do not split 1024-byte hexdumps Li Lingfeng <lilingfeng3(a)huawei.com> nfs: handle failure of nfs_get_lock_context in unlock path Zhu Yanjun <yanjun.zhu(a)linux.dev> RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug David Lechner <dlechner(a)baylibre.com> iio: chemical: sps30: use aligned_s64 for timestamp Jonathan Cameron <Jonathan.Cameron(a)huawei.com> iio: adc: ad7768-1: Fix insufficient alignment of timestamp. Masami Hiramatsu (Google) <mhiramat(a)kernel.org> tracing: probes: Fix a possible race in trace_probe_log APIs Hans de Goede <hdegoede(a)redhat.com> platform/x86: asus-wmi: Fix wlan_ctrl_by_user detection ------------- Diffstat: Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + Documentation/admin-guide/hw-vuln/index.rst | 1 + .../hw-vuln/indirect-target-selection.rst | 156 +++++++++++++ Documentation/admin-guide/kernel-parameters.txt | 15 ++ Makefile | 4 +- arch/x86/Kconfig | 11 + arch/x86/entry/entry_64.S | 20 +- arch/x86/include/asm/alternative.h | 32 +++ arch/x86/include/asm/cpufeatures.h | 3 + arch/x86/include/asm/msr-index.h | 8 + arch/x86/include/asm/nospec-branch.h | 57 +++-- arch/x86/kernel/alternative.c | 243 ++++++++++++++++++++- arch/x86/kernel/cpu/bugs.c | 139 +++++++++++- arch/x86/kernel/cpu/common.c | 63 +++++- arch/x86/kernel/ftrace.c | 2 +- arch/x86/kernel/module.c | 7 + arch/x86/kernel/static_call.c | 2 +- arch/x86/kernel/vmlinux.lds.S | 10 + arch/x86/kvm/x86.c | 4 +- arch/x86/lib/retpoline.S | 39 ++++ arch/x86/net/bpf_jit_comp.c | 8 +- block/fops.c | 5 +- drivers/acpi/pptt.c | 11 +- drivers/base/cpu.c | 8 + drivers/clocksource/i8253.c | 6 +- drivers/dma/dmatest.c | 6 +- drivers/dma/idxd/init.c | 8 + drivers/dma/ti/k3-udma.c | 10 +- drivers/iio/adc/ad7768-1.c | 2 +- drivers/iio/chemical/sps30.c | 2 +- drivers/infiniband/sw/rxe/rxe_cq.c | 5 +- drivers/net/dsa/sja1105/sja1105_main.c | 6 +- drivers/net/ethernet/cadence/macb_main.c | 19 +- drivers/net/ethernet/intel/ice/ice_arfs.c | 9 +- drivers/net/ethernet/intel/ice/ice_lib.c | 5 +- drivers/net/ethernet/intel/ice/ice_main.c | 20 +- .../ethernet/qlogic/qlcnic/qlcnic_sriov_common.c | 7 +- drivers/net/wireless/mediatek/mt76/dma.c | 1 + drivers/phy/renesas/phy-rcar-gen3-usb2.c | 7 +- drivers/phy/tegra/xusb.c | 8 +- drivers/platform/x86/asus-wmi.c | 3 +- drivers/spi/spi-loopback-test.c | 2 +- drivers/usb/typec/altmodes/displayport.c | 18 +- drivers/usb/typec/ucsi/displayport.c | 19 +- drivers/usb/typec/ucsi/ucsi.c | 34 +++ drivers/usb/typec/ucsi/ucsi.h | 3 + drivers/usb/typec/ucsi/ucsi_ccg.c | 5 + fs/btrfs/discard.c | 17 +- fs/btrfs/extent-tree.c | 25 ++- fs/btrfs/extent_io.c | 15 +- fs/nfs/nfs4proc.c | 9 +- fs/nfs/pnfs.c | 9 + include/linux/cpu.h | 2 + include/linux/module.h | 5 + include/net/netfilter/nf_tables.h | 2 +- include/net/sch_generic.h | 15 ++ kernel/trace/trace_dynevent.c | 16 +- kernel/trace/trace_dynevent.h | 1 + kernel/trace/trace_events_trigger.c | 2 +- kernel/trace/trace_functions.c | 6 +- kernel/trace/trace_kprobe.c | 2 +- kernel/trace/trace_probe.c | 9 + kernel/trace/trace_uprobe.c | 2 +- net/netfilter/nf_tables_api.c | 54 +++-- net/netfilter/nft_immediate.c | 2 +- net/sched/sch_codel.c | 2 +- net/sched/sch_fq.c | 2 +- net/sched/sch_fq_codel.c | 2 +- net/sched/sch_fq_pie.c | 2 +- net/sched/sch_hhf.c | 2 +- net/sched/sch_pie.c | 2 +- net/sctp/sysctl.c | 4 + samples/ftrace/sample-trace-array.c | 2 +- sound/pci/es1968.c | 6 +- sound/sh/Kconfig | 2 +- sound/usb/quirks.c | 4 + tools/testing/selftests/vm/compaction_test.c | 19 +- 77 files changed, 1112 insertions(+), 184 deletions(-)

5 months, 1 week

13
77
0 0

Are there any internal kernel ABI/API guarantees in -stable releases?

by Chris Friesen

Hi everyone, Looking at https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html there are a number of criteria for patches to -stable releases. However, there is no mention of preserving the stability of internal kernel ABIs and/or APIs. Do successive patch releases of -stable kernels provide any guarantees that they will not change ABIs and/or APIs, remove functionality, change behaviour, etc.? For example, would a -stable commit be allowed to make a change that would break an out-of-tree (but open-source) device driver if that's the only way to fix a bug? I know that during the development of new major/minor versions developers are free to break ABIs and APIs at will as long as they fix up all the in-tree code. Does that still hold true for -stable commits or do things get more restrictive? Thanks, Chris

5 months, 1 week

2
1
0 0

+ mm-fix-the-inaccurate-memory-statistics-issue-for-users.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: fix the inaccurate memory statistics issue for users has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-fix-the-inaccurate-memory-statistics-issue-for-users.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Baolin Wang <baolin.wang(a)linux.alibaba.com> Subject: mm: fix the inaccurate memory statistics issue for users Date: Sat, 24 May 2025 09:59:53 +0800 On some large machines with a high number of CPUs running a 64K pagesize kernel, we found that the 'RES' field is always 0 displayed by the top command for some processes, which will cause a lot of confusion for users. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 875525 root 20 0 12480 0 0 R 0.3 0.0 0:00.08 top 1 root 20 0 172800 0 0 S 0.0 0.0 0:04.52 systemd The main reason is that the batch size of the percpu counter is quite large on these machines, caching a significant percpu value, since converting mm's rss stats into percpu_counter by commit f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter"). Intuitively, the batch number should be optimized, but on some paths, performance may take precedence over statistical accuracy. Therefore, introducing a new interface to add the percpu statistical count and display it to users, which can remove the confusion. In addition, this change is not expected to be on a performance-critical path, so the modification should be acceptable. Link: https://lkml.kernel.org/r/4f0fd51eb4f48c1a34226456b7a8b4ebff11bf72.17480518… Fixes: f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter") Signed-off-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Tested-by Donet Tom <donettom(a)linux.ibm.com> Reviewed-by: Aboorva Devarajan <aboorvad(a)linux.ibm.com> Tested-by: Aboorva Devarajan <aboorvad(a)linux.ibm.com> Acked-by: Shakeel Butt <shakeel.butt(a)linux.dev> Acked-by: SeongJae Park <sj(a)kernel.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/task_mmu.c | 14 +++++++------- include/linux/mm.h | 5 +++++ 2 files changed, 12 insertions(+), 7 deletions(-) --- a/fs/proc/task_mmu.c~mm-fix-the-inaccurate-memory-statistics-issue-for-users +++ a/fs/proc/task_mmu.c @@ -36,9 +36,9 @@ void task_mem(struct seq_file *m, struct unsigned long text, lib, swap, anon, file, shmem; unsigned long hiwater_vm, total_vm, hiwater_rss, total_rss; - anon = get_mm_counter(mm, MM_ANONPAGES); - file = get_mm_counter(mm, MM_FILEPAGES); - shmem = get_mm_counter(mm, MM_SHMEMPAGES); + anon = get_mm_counter_sum(mm, MM_ANONPAGES); + file = get_mm_counter_sum(mm, MM_FILEPAGES); + shmem = get_mm_counter_sum(mm, MM_SHMEMPAGES); /* * Note: to minimize their overhead, mm maintains hiwater_vm and @@ -59,7 +59,7 @@ void task_mem(struct seq_file *m, struct text = min(text, mm->exec_vm << PAGE_SHIFT); lib = (mm->exec_vm << PAGE_SHIFT) - text; - swap = get_mm_counter(mm, MM_SWAPENTS); + swap = get_mm_counter_sum(mm, MM_SWAPENTS); SEQ_PUT_DEC("VmPeak:\t", hiwater_vm); SEQ_PUT_DEC(" kB\nVmSize:\t", total_vm); SEQ_PUT_DEC(" kB\nVmLck:\t", mm->locked_vm); @@ -92,12 +92,12 @@ unsigned long task_statm(struct mm_struc unsigned long *shared, unsigned long *text, unsigned long *data, unsigned long *resident) { - *shared = get_mm_counter(mm, MM_FILEPAGES) + - get_mm_counter(mm, MM_SHMEMPAGES); + *shared = get_mm_counter_sum(mm, MM_FILEPAGES) + + get_mm_counter_sum(mm, MM_SHMEMPAGES); *text = (PAGE_ALIGN(mm->end_code) - (mm->start_code & PAGE_MASK)) >> PAGE_SHIFT; *data = mm->data_vm + mm->stack_vm; - *resident = *shared + get_mm_counter(mm, MM_ANONPAGES); + *resident = *shared + get_mm_counter_sum(mm, MM_ANONPAGES); return mm->total_vm; } --- a/include/linux/mm.h~mm-fix-the-inaccurate-memory-statistics-issue-for-users +++ a/include/linux/mm.h @@ -2708,6 +2708,11 @@ static inline unsigned long get_mm_count return percpu_counter_read_positive(&mm->rss_stat[member]); } +static inline unsigned long get_mm_counter_sum(struct mm_struct *mm, int member) +{ + return percpu_counter_sum_positive(&mm->rss_stat[member]); +} + void mm_trace_rss_stat(struct mm_struct *mm, int member); static inline void add_mm_counter(struct mm_struct *mm, int member, long value) _ Patches currently in -mm which might be from baolin.wang(a)linux.alibaba.com are mm-fix-the-inaccurate-memory-statistics-issue-for-users.patch

5 months, 1 week

1
0
0 0

Re: [PATCH v2 1/1] netfilter: load nf_log_syslog on enabling nf_conntrack_log_invalid

by Lance Yang

Cc: stable On 2025/5/28 19:42, Lance Yang wrote: > > Thanks for taking the time to review! > > On 2025/5/28 19:05, Florian Westphal wrote: >> Lance Yang <ioworker0(a)gmail.com> wrote: >>> From: Lance Yang <lance.yang(a)linux.dev> >>> >>> When no logger is registered, nf_conntrack_log_invalid fails to log >>> invalid >>> packets, leaving users unaware of actual invalid traffic. Improve >>> this by >>> loading nf_log_syslog, similar to how 'iptables -I FORWARD 1 -m >>> conntrack >>> --ctstate INVALID -j LOG' triggers it. >> >> Acked-by: Florian Westphal <fw(a)strlen.de> > > Hmm... should this patch be backported to stable kernels? Without it, > nf_conntrack_log_invalid won't log invalid packets when no logger is > registered, causing unnecessary debugging effort ;) > > Back then, I actually thought my machine wasn't seeing any invalid > packets... turns out they just weren't logged in dmesg :( > > Thanks, > Lance

5 months, 1 week

1
0
0 0

KASAN: slab-out-of-bounds Read in steelseries_remove in linux6.12-6.15

by Jianzhou Zhao

Hello, I found a potential bug titled " KASAN: slab-out-of-bounds Read in steelseries_remove " with modified syzkaller in the Linux6.12 - 6.15. This bug was verified to exist in 6.12.24,6.12.28 and 6.15. During the execution of poc, for the same hdev device, in the function steelseries_probe, the sd of hdev is first set to the steelseries_device type. If sd->quriks=0x1, Then execute steelseries_srws1_probe to reset the sd of hdev to the type steelseries_srws1_data. However, when the device is removed and the steelseries_remove command is executed, the sd obtained through hdev will first be forcibly converted to the steelseries_device type, but the value of sd->quirks may not be 0x1, but rather become some pointer. For example, sd->quirks=0xffff888022167000, then steelseries_srws1_remove (hdev) cannot be executed. This will lead to type errors in subsequent access to sd (wrongly treating sd of type steelseries_srws1_data as of type steelseries_device), and an out-of-bounds access error occurs when accessing sd->lock. However, I still don't understand why the sd-> quirks of the same hdev in the detection phase and the deletion phase are completely inconsistent (even Pointers appear). static int steelseries_probe(struct hid_device *hdev, const struct hid_device_id *id) { struct steelseries_device *sd; int ret; sd = devm_kzalloc(&hdev->dev, sizeof(*sd), GFP_KERNEL); ....... hid_set_drvdata(hdev, sd); [1] Set hdev->dev->driver_data to the type of steelseries_device ( hdev->dev->driver_data = sd ) sd->hdev = hdev; sd->quirks = id->driver_data; //Here, sd->quirks is assigned a value of 0x1 if (sd->quirks & STEELSERIES_SRWS1) { //Passed the inspection successfully #if IS_BUILTIN(CONFIG_LEDS_CLASS) || \ (IS_MODULE(CONFIG_LEDS_CLASS) && IS_MODULE(CONFIG_HID_STEELSERIES)) return steelseries_srws1_probe(hdev, id); [2] Set hdev->dev->driver_data to the type of steelseries_srws1_data #else return -ENODEV; #endif } ...... } static int steelseries_srws1_probe(struct hid_device *hdev, const struct hid_device_id *id) { int ret, i; struct led_classdev *led; size_t name_sz; char *name; struct steelseries_srws1_data *drv_data = kzalloc(sizeof(*drv_data), GFP_KERNEL); if (drv_data == NULL) { hid_err(hdev, "can't alloc SRW-S1 memory\n"); return -ENOMEM; } hid_set_drvdata(hdev, drv_data); [3] Set hdev->dev->driver_data to the type of steelseries_srws1_data } static void steelseries_remove(struct hid_device *hdev) { struct steelseries_device *sd = hid_get_drvdata(hdev); [4] The default sd is of the steelseries_device type unsigned long flags; if (sd->quirks & STEELSERIES_SRWS1) { [5]sd->quriks is not 0x1 but equal to the value of a pointer, such as 0xffff888022167000. Therefore, the inspection cannot be passed and steelseries_srws1_remove cannot be executed #if IS_BUILTIN(CONFIG_LEDS_CLASS) || \ (IS_MODULE(CONFIG_LEDS_CLASS) && IS_MODULE(CONFIG_HID_STEELSERIES)) steelseries_srws1_remove(hdev); #endif return; } spin_lock_irqsave(&sd->lock, flags); [6] The correct type of sd is steelseries_srws1_data. However, here, sd is treated as the type of steelseries_srws1_data to access sd->quirks, resulting in out-of-bounds access ...... } The commit of the kernel is : ef4999852d307d38cfdecd91ed6892cc03beb9b8 kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&x=55f8591b98dd132 compiler: gcc version 11.4.0 If you fix this issue, please add the following tag to the commit: Reported-by: Jianzhou Zhao <luckd0g(a)163.com> Reported-by: Penglei Jiang <superman.xpt(a)gmail.com> I put the reproduction program of this bug at the end of the email. ------------[ cut here ]----------------------------------------- TITLE: KASAN: slab-out-of-bounds Read in steelseries_remove ------------[ cut here ]------------ ================================================================== BUG: KASAN: slab-out-of-bounds in __lock_acquire+0x31b5/0x3f40 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880285a64d0 by task kworker/0:11/12464 CPU: 0 UID: 0 PID: 12464 Comm: kworker/0:11 Not tainted 6.12.28 #29 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc6/0x620 mm/kasan/report.c:488 kasan_report+0xd8/0x110 mm/kasan/report.c:601 __lock_acquire+0x31b5/0x3f40 kernel/locking/lockdep.c:5065 lock_acquire.part.0+0x11f/0x380 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x3a/0x60 kernel/locking/spinlock.c:162 steelseries_remove+0x8c/0x1f0 drivers/hid/hid-steelseries.c:564 hid_device_remove+0xce/0x260 drivers/hid/hid-core.c:2758 device_remove+0xc8/0x170 drivers/base/dd.c:567 __device_release_driver drivers/base/dd.c:1272 [inline] device_release_driver_internal+0x44b/0x620 drivers/base/dd.c:1295 bus_remove_device+0x22f/0x420 drivers/base/bus.c:576 device_del+0x377/0x9c0 drivers/base/core.c:3881 hid_remove_device drivers/hid/hid-core.c:2942 [inline] hid_destroy_device+0xe5/0x150 drivers/hid/hid-core.c:2962 usbhid_disconnect+0xa0/0xe0 drivers/hid/usbhid/hid-core.c:1459 usb_unbind_interface+0x1e8/0x960 drivers/usb/core/driver.c:461 device_remove drivers/base/dd.c:569 [inline] device_remove+0x122/0x170 drivers/base/dd.c:561 __device_release_driver drivers/base/dd.c:1272 [inline] device_release_driver_internal+0x44b/0x620 drivers/base/dd.c:1295 bus_remove_device+0x22f/0x420 drivers/base/bus.c:576 device_del+0x377/0x9c0 drivers/base/core.c:3881 usb_disable_device+0x35f/0x7c0 drivers/usb/core/message.c:1418 usb_disconnect+0x2e0/0x920 drivers/usb/core/hub.c:2315 hub_port_connect drivers/usb/core/hub.c:5373 [inline] hub_port_connect_change drivers/usb/core/hub.c:5673 [inline] port_event drivers/usb/core/hub.c:5833 [inline] hub_event+0x1da4/0x4e20 drivers/usb/core/hub.c:5915 process_one_work+0x9c3/0x1b70 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x61e/0xe40 kernel/workqueue.c:3391 kthread+0x2ab/0x390 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:152 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 2285: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] steelseries_srws1_probe drivers/hid/hid-steelseries.c:253 [inline] steelseries_probe+0x69d/0xf60 drivers/hid/hid-steelseries.c:528 __hid_device_probe drivers/hid/hid-core.c:2702 [inline] hid_device_probe+0x2f5/0x4f0 drivers/hid/hid-core.c:2739 call_driver_probe drivers/base/dd.c:579 [inline] really_probe+0x23a/0xa80 drivers/base/dd.c:657 __driver_probe_device+0x1de/0x440 drivers/base/dd.c:799 driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:829 __device_attach_driver+0x1df/0x310 drivers/base/dd.c:957 bus_for_each_drv+0x157/0x1e0 drivers/base/bus.c:459 __device_attach+0x1e5/0x4b0 drivers/base/dd.c:1029 bus_probe_device+0x17f/0x1c0 drivers/base/bus.c:534 device_add+0x1143/0x1a80 drivers/base/core.c:3692 hid_add_device+0x377/0xa60 drivers/hid/hid-core.c:2885 usbhid_probe+0xd41/0x1400 drivers/hid/usbhid/hid-core.c:1432 usb_probe_interface+0x309/0x9d0 drivers/usb/core/driver.c:399 call_driver_probe drivers/base/dd.c:579 [inline] really_probe+0x23a/0xa80 drivers/base/dd.c:657 __driver_probe_device+0x1de/0x440 drivers/base/dd.c:799 driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:829 __device_attach_driver+0x1df/0x310 drivers/base/dd.c:957 bus_for_each_drv+0x157/0x1e0 drivers/base/bus.c:459 __device_attach+0x1e5/0x4b0 drivers/base/dd.c:1029 bus_probe_device+0x17f/0x1c0 drivers/base/bus.c:534 device_add+0x1143/0x1a80 drivers/base/core.c:3692 usb_set_configuration+0x120e/0x1e10 drivers/usb/core/message.c:2210 usb_generic_driver_probe+0xb1/0x110 drivers/usb/core/generic.c:254 usb_probe_device+0xec/0x3e0 drivers/usb/core/driver.c:294 call_driver_probe drivers/base/dd.c:579 [inline] really_probe+0x23a/0xa80 drivers/base/dd.c:657 __driver_probe_device+0x1de/0x440 drivers/base/dd.c:799 driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:829 __device_attach_driver+0x1df/0x310 drivers/base/dd.c:957 bus_for_each_drv+0x157/0x1e0 drivers/base/bus.c:459 __device_attach+0x1e5/0x4b0 drivers/base/dd.c:1029 bus_probe_device+0x17f/0x1c0 drivers/base/bus.c:534 device_add+0x1143/0x1a80 drivers/base/core.c:3692 usb_new_device+0xd04/0x19d0 drivers/usb/core/hub.c:2662 hub_port_connect drivers/usb/core/hub.c:5533 [inline] hub_port_connect_change drivers/usb/core/hub.c:5673 [inline] port_event drivers/usb/core/hub.c:5833 [inline] hub_event+0x2d92/0x4e20 drivers/usb/core/hub.c:5915 process_one_work+0x9c3/0x1b70 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x61e/0xe40 kernel/workqueue.c:3391 kthread+0x2ab/0x390 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:152 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The buggy address belongs to the object at ffff8880285a6400 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 72 bytes to the right of allocated 136-byte region [ffff8880285a6400, ffff8880285a6488) The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x285a6 ksm flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) page_type: f5(slab) raw: 00fff00000000000 ffff88801b0413c0 ffffea0000875540 dead000000000003 raw: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x52cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 9743, tgid 9743 (syz-executor), ts 61586032132, free_ts 61073188909 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x2f0/0x350 mm/page_alloc.c:1558 prep_new_page mm/page_alloc.c:1566 [inline] get_page_from_freelist+0x7d6/0x3660 mm/page_alloc.c:3476 __alloc_pages_noprof+0x229/0x2670 mm/page_alloc.c:4754 alloc_pages_mpol_noprof+0x2c9/0x610 mm/mempolicy.c:2269 alloc_slab_page mm/slub.c:2425 [inline] allocate_slab mm/slub.c:2595 [inline] new_slab+0x2df/0x410 mm/slub.c:2649 ___slab_alloc+0xe2f/0x19a0 mm/slub.c:3837 __slab_alloc.isra.0+0x56/0xb0 mm/slub.c:3927 __slab_alloc_node mm/slub.c:3980 [inline] slab_alloc_node mm/slub.c:4141 [inline] __kmalloc_cache_noprof+0x2b4/0x300 mm/slub.c:4309 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] call_usermodehelper_setup+0xaf/0x360 kernel/umh.c:363 kobject_uevent_env+0x15fe/0x1860 lib/kobject_uevent.c:628 rx_queue_add_kobject net/core/net-sysfs.c:1124 [inline] net_rx_queue_update_kobjects+0x17c/0x5f0 net/core/net-sysfs.c:1164 register_queue_kobjects net/core/net-sysfs.c:1898 [inline] netdev_register_kobject+0x269/0x3a0 net/core/net-sysfs.c:2143 register_netdevice+0x1312/0x1db0 net/core/dev.c:10557 veth_newlink+0x354/0x9e0 drivers/net/veth.c:1830 rtnl_newlink_create net/core/rtnetlink.c:3542 [inline] __rtnl_newlink+0x1187/0x1910 net/core/rtnetlink.c:3762 rtnl_newlink+0x67/0xa0 net/core/rtnetlink.c:3775 page last free pid 9715 tgid 9715 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1127 [inline] free_unref_page+0x6d7/0x1080 mm/page_alloc.c:2659 qlink_free mm/kasan/quarantine.c:163 [inline] qlist_free_all+0x54/0x120 mm/kasan/quarantine.c:179 kasan_quarantine_reduce+0x192/0x1e0 mm/kasan/quarantine.c:286 __kasan_slab_alloc+0x69/0x90 mm/kasan/common.c:329 kasan_slab_alloc include/linux/kasan.h:250 [inline] slab_post_alloc_hook mm/slub.c:4104 [inline] slab_alloc_node mm/slub.c:4153 [inline] __kmalloc_cache_noprof+0x11e/0x300 mm/slub.c:4309 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] kobject_uevent_env+0x265/0x1860 lib/kobject_uevent.c:540 __kobject_del+0x168/0x1f0 lib/kobject.c:601 kobject_cleanup lib/kobject.c:680 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x327/0x5a0 lib/kobject.c:737 net_rx_queue_update_kobjects+0x476/0x5f0 net/core/net-sysfs.c:1178 netif_set_real_num_rx_queues+0x169/0x210 net/core/dev.c:3055 veth_init_queues+0x151/0x190 drivers/net/veth.c:1761 veth_newlink+0x530/0x9e0 drivers/net/veth.c:1873 rtnl_newlink_create net/core/rtnetlink.c:3542 [inline] __rtnl_newlink+0x1187/0x1910 net/core/rtnetlink.c:3762 rtnl_newlink+0x67/0xa0 net/core/rtnetlink.c:3775 rtnetlink_rcv_msg+0x3c7/0xea0 net/core/rtnetlink.c:6678 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2537 Memory state around the buggy address: ffff8880285a6380: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ffff8880285a6400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8880285a6480: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff8880285a6500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8880285a6580: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ================================================================== // autogenerated by syzkaller (https://github.com/google/syzkaller) #define _GNU_SOURCE #include <dirent.h> #include <endian.h> #include <errno.h> #include <fcntl.h> #include <signal.h> #include <stdarg.h> #include <stdbool.h> #include <stddef.h> #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/mount.h> #include <sys/prctl.h> #include <sys/stat.h> #include <sys/syscall.h> #include <sys/types.h> #include <sys/wait.h> #include <time.h> #include <unistd.h> #include <linux/usb/ch9.h> static unsigned long long procid; static void sleep_ms(uint64_t ms) { usleep(ms * 1000); } static uint64_t current_time_ms(void) { struct timespec ts; if (clock_gettime(CLOCK_MONOTONIC, &ts)) exit(1); return (uint64_t)ts.tv_sec * 1000 + (uint64_t)ts.tv_nsec / 1000000; } static bool write_file(const char* file, const char* what, ...) { char buf[1024]; va_list args; va_start(args, what); vsnprintf(buf, sizeof(buf), what, args); va_end(args); buf[sizeof(buf) - 1] = 0; int len = strlen(buf); int fd = open(file, O_WRONLY | O_CLOEXEC); if (fd == -1) return false; if (write(fd, buf, len) != len) { int err = errno; close(fd); errno = err; return false; } close(fd); return true; } #define MAX_FDS 30 #define USB_MAX_IFACE_NUM 4 #define USB_MAX_EP_NUM 32 #define USB_MAX_FDS 6 struct usb_endpoint_index { struct usb_endpoint_descriptor desc; int handle; }; struct usb_iface_index { struct usb_interface_descriptor* iface; uint8_t bInterfaceNumber; uint8_t bAlternateSetting; uint8_t bInterfaceClass; struct usb_endpoint_index eps[USB_MAX_EP_NUM]; int eps_num; }; struct usb_device_index { struct usb_device_descriptor* dev; struct usb_config_descriptor* config; uint8_t bDeviceClass; uint8_t bMaxPower; int config_length; struct usb_iface_index ifaces[USB_MAX_IFACE_NUM]; int ifaces_num; int iface_cur; }; struct usb_info { int fd; struct usb_device_index index; }; static struct usb_info usb_devices[USB_MAX_FDS]; static struct usb_device_index* lookup_usb_index(int fd) { for (int i = 0; i < USB_MAX_FDS; i++) { if (__atomic_load_n(&usb_devices[i].fd, __ATOMIC_ACQUIRE) == fd) return &usb_devices[i].index; } return NULL; } static int usb_devices_num; static bool parse_usb_descriptor(const char* buffer, size_t length, struct usb_device_index* index) { if (length < sizeof(*index->dev) + sizeof(*index->config)) return false; memset(index, 0, sizeof(*index)); index->dev = (struct usb_device_descriptor*)buffer; index->config = (struct usb_config_descriptor*)(buffer + sizeof(*index->dev)); index->bDeviceClass = index->dev->bDeviceClass; index->bMaxPower = index->config->bMaxPower; index->config_length = length - sizeof(*index->dev); index->iface_cur = -1; size_t offset = 0; while (true) { if (offset + 1 >= length) break; uint8_t desc_length = buffer[offset]; uint8_t desc_type = buffer[offset + 1]; if (desc_length <= 2) break; if (offset + desc_length > length) break; if (desc_type == USB_DT_INTERFACE && index->ifaces_num < USB_MAX_IFACE_NUM) { struct usb_interface_descriptor* iface = (struct usb_interface_descriptor*)(buffer + offset); index->ifaces[index->ifaces_num].iface = iface; index->ifaces[index->ifaces_num].bInterfaceNumber = iface->bInterfaceNumber; index->ifaces[index->ifaces_num].bAlternateSetting = iface->bAlternateSetting; index->ifaces[index->ifaces_num].bInterfaceClass = iface->bInterfaceClass; index->ifaces_num++; } if (desc_type == USB_DT_ENDPOINT && index->ifaces_num > 0) { struct usb_iface_index* iface = &index->ifaces[index->ifaces_num - 1]; if (iface->eps_num < USB_MAX_EP_NUM) { memcpy(&iface->eps[iface->eps_num].desc, buffer + offset, sizeof(iface->eps[iface->eps_num].desc)); iface->eps_num++; } } offset += desc_length; } return true; } static struct usb_device_index* add_usb_index(int fd, const char* dev, size_t dev_len) { int i = __atomic_fetch_add(&usb_devices_num, 1, __ATOMIC_RELAXED); if (i >= USB_MAX_FDS) return NULL; if (!parse_usb_descriptor(dev, dev_len, &usb_devices[i].index)) return NULL; __atomic_store_n(&usb_devices[i].fd, fd, __ATOMIC_RELEASE); return &usb_devices[i].index; } struct vusb_connect_string_descriptor { uint32_t len; char* str; } __attribute__((packed)); struct vusb_connect_descriptors { uint32_t qual_len; char* qual; uint32_t bos_len; char* bos; uint32_t strs_len; struct vusb_connect_string_descriptor strs[0]; } __attribute__((packed)); static const char default_string[] = { 8, USB_DT_STRING, 's', 0, 'y', 0, 'z', 0 }; static const char default_lang_id[] = { 4, USB_DT_STRING, 0x09, 0x04 }; static bool lookup_connect_response_in(int fd, const struct vusb_connect_descriptors* descs, const struct usb_ctrlrequest* ctrl, struct usb_qualifier_descriptor* qual, char** response_data, uint32_t* response_length) { struct usb_device_index* index = lookup_usb_index(fd); uint8_t str_idx; if (!index) return false; switch (ctrl->bRequestType & USB_TYPE_MASK) { case USB_TYPE_STANDARD: switch (ctrl->bRequest) { case USB_REQ_GET_DESCRIPTOR: switch (ctrl->wValue >> 8) { case USB_DT_DEVICE: *response_data = (char*)index->dev; *response_length = sizeof(*index->dev); return true; case USB_DT_CONFIG: *response_data = (char*)index->config; *response_length = index->config_length; return true; case USB_DT_STRING: str_idx = (uint8_t)ctrl->wValue; if (descs && str_idx < descs->strs_len) { *response_data = descs->strs[str_idx].str; *response_length = descs->strs[str_idx].len; return true; } if (str_idx == 0) { *response_data = (char*)&default_lang_id[0]; *response_length = default_lang_id[0]; return true; } *response_data = (char*)&default_string[0]; *response_length = default_string[0]; return true; case USB_DT_BOS: *response_data = descs->bos; *response_length = descs->bos_len; return true; case USB_DT_DEVICE_QUALIFIER: if (!descs->qual) { qual->bLength = sizeof(*qual); qual->bDescriptorType = USB_DT_DEVICE_QUALIFIER; qual->bcdUSB = index->dev->bcdUSB; qual->bDeviceClass = index->dev->bDeviceClass; qual->bDeviceSubClass = index->dev->bDeviceSubClass; qual->bDeviceProtocol = index->dev->bDeviceProtocol; qual->bMaxPacketSize0 = index->dev->bMaxPacketSize0; qual->bNumConfigurations = index->dev->bNumConfigurations; qual->bRESERVED = 0; *response_data = (char*)qual; *response_length = sizeof(*qual); return true; } *response_data = descs->qual; *response_length = descs->qual_len; return true; default: break; } break; default: break; } break; default: break; } return false; } typedef bool (*lookup_connect_out_response_t)(int fd, const struct vusb_connect_descriptors* descs, const struct usb_ctrlrequest* ctrl, bool* done); static bool lookup_connect_response_out_generic(int fd, const struct vusb_connect_descriptors* descs, const struct usb_ctrlrequest* ctrl, bool* done) { switch (ctrl->bRequestType & USB_TYPE_MASK) { case USB_TYPE_STANDARD: switch (ctrl->bRequest) { case USB_REQ_SET_CONFIGURATION: *done = true; return true; default: break; } break; } return false; } struct vusb_descriptor { uint8_t req_type; uint8_t desc_type; uint32_t len; char data[0]; } __attribute__((packed)); struct vusb_descriptors { uint32_t len; struct vusb_descriptor* generic; struct vusb_descriptor* descs[0]; } __attribute__((packed)); struct vusb_response { uint8_t type; uint8_t req; uint32_t len; char data[0]; } __attribute__((packed)); struct vusb_responses { uint32_t len; struct vusb_response* generic; struct vusb_response* resps[0]; } __attribute__((packed)); static bool lookup_control_response(const struct vusb_descriptors* descs, const struct vusb_responses* resps, struct usb_ctrlrequest* ctrl, char** response_data, uint32_t* response_length) { int descs_num = 0; int resps_num = 0; if (descs) descs_num = (descs->len - offsetof(struct vusb_descriptors, descs)) / sizeof(descs->descs[0]); if (resps) resps_num = (resps->len - offsetof(struct vusb_responses, resps)) / sizeof(resps->resps[0]); uint8_t req = ctrl->bRequest; uint8_t req_type = ctrl->bRequestType & USB_TYPE_MASK; uint8_t desc_type = ctrl->wValue >> 8; if (req == USB_REQ_GET_DESCRIPTOR) { int i; for (i = 0; i < descs_num; i++) { struct vusb_descriptor* desc = descs->descs[i]; if (!desc) continue; if (desc->req_type == req_type && desc->desc_type == desc_type) { *response_length = desc->len; if (*response_length != 0) *response_data = &desc->data[0]; else *response_data = NULL; return true; } } if (descs && descs->generic) { *response_data = &descs->generic->data[0]; *response_length = descs->generic->len; return true; } } else { int i; for (i = 0; i < resps_num; i++) { struct vusb_response* resp = resps->resps[i]; if (!resp) continue; if (resp->type == req_type && resp->req == req) { *response_length = resp->len; if (*response_length != 0) *response_data = &resp->data[0]; else *response_data = NULL; return true; } } if (resps && resps->generic) { *response_data = &resps->generic->data[0]; *response_length = resps->generic->len; return true; } } return false; } #define UDC_NAME_LENGTH_MAX 128 struct usb_raw_init { __u8 driver_name[UDC_NAME_LENGTH_MAX]; __u8 device_name[UDC_NAME_LENGTH_MAX]; __u8 speed; }; enum usb_raw_event_type { USB_RAW_EVENT_INVALID = 0, USB_RAW_EVENT_CONNECT = 1, USB_RAW_EVENT_CONTROL = 2, }; struct usb_raw_event { __u32 type; __u32 length; __u8 data[0]; }; struct usb_raw_ep_io { __u16 ep; __u16 flags; __u32 length; __u8 data[0]; }; #define USB_RAW_EPS_NUM_MAX 30 #define USB_RAW_EP_NAME_MAX 16 #define USB_RAW_EP_ADDR_ANY 0xff struct usb_raw_ep_caps { __u32 type_control : 1; __u32 type_iso : 1; __u32 type_bulk : 1; __u32 type_int : 1; __u32 dir_in : 1; __u32 dir_out : 1; }; struct usb_raw_ep_limits { __u16 maxpacket_limit; __u16 max_streams; __u32 reserved; }; struct usb_raw_ep_info { __u8 name[USB_RAW_EP_NAME_MAX]; __u32 addr; struct usb_raw_ep_caps caps; struct usb_raw_ep_limits limits; }; struct usb_raw_eps_info { struct usb_raw_ep_info eps[USB_RAW_EPS_NUM_MAX]; }; #define USB_RAW_IOCTL_INIT _IOW('U', 0, struct usb_raw_init) #define USB_RAW_IOCTL_RUN _IO('U', 1) #define USB_RAW_IOCTL_EVENT_FETCH _IOR('U', 2, struct usb_raw_event) #define USB_RAW_IOCTL_EP0_WRITE _IOW('U', 3, struct usb_raw_ep_io) #define USB_RAW_IOCTL_EP0_READ _IOWR('U', 4, struct usb_raw_ep_io) #define USB_RAW_IOCTL_EP_ENABLE _IOW('U', 5, struct usb_endpoint_descriptor) #define USB_RAW_IOCTL_EP_DISABLE _IOW('U', 6, __u32) #define USB_RAW_IOCTL_EP_WRITE _IOW('U', 7, struct usb_raw_ep_io) #define USB_RAW_IOCTL_EP_READ _IOWR('U', 8, struct usb_raw_ep_io) #define USB_RAW_IOCTL_CONFIGURE _IO('U', 9) #define USB_RAW_IOCTL_VBUS_DRAW _IOW('U', 10, __u32) #define USB_RAW_IOCTL_EPS_INFO _IOR('U', 11, struct usb_raw_eps_info) #define USB_RAW_IOCTL_EP0_STALL _IO('U', 12) #define USB_RAW_IOCTL_EP_SET_HALT _IOW('U', 13, __u32) #define USB_RAW_IOCTL_EP_CLEAR_HALT _IOW('U', 14, __u32) #define USB_RAW_IOCTL_EP_SET_WEDGE _IOW('U', 15, __u32) static int usb_raw_open() { return open("/dev/raw-gadget", O_RDWR); } static int usb_raw_init(int fd, uint32_t speed, const char* driver, const char* device) { struct usb_raw_init arg; strncpy((char*)&arg.driver_name[0], driver, sizeof(arg.driver_name)); strncpy((char*)&arg.device_name[0], device, sizeof(arg.device_name)); arg.speed = speed; return ioctl(fd, USB_RAW_IOCTL_INIT, &arg); } static int usb_raw_run(int fd) { return ioctl(fd, USB_RAW_IOCTL_RUN, 0); } static int usb_raw_configure(int fd) { return ioctl(fd, USB_RAW_IOCTL_CONFIGURE, 0); } static int usb_raw_vbus_draw(int fd, uint32_t power) { return ioctl(fd, USB_RAW_IOCTL_VBUS_DRAW, power); } static int usb_raw_ep0_write(int fd, struct usb_raw_ep_io* io) { return ioctl(fd, USB_RAW_IOCTL_EP0_WRITE, io); } static int usb_raw_ep0_read(int fd, struct usb_raw_ep_io* io) { return ioctl(fd, USB_RAW_IOCTL_EP0_READ, io); } static int usb_raw_event_fetch(int fd, struct usb_raw_event* event) { return ioctl(fd, USB_RAW_IOCTL_EVENT_FETCH, event); } static int usb_raw_ep_enable(int fd, struct usb_endpoint_descriptor* desc) { return ioctl(fd, USB_RAW_IOCTL_EP_ENABLE, desc); } static int usb_raw_ep_disable(int fd, int ep) { return ioctl(fd, USB_RAW_IOCTL_EP_DISABLE, ep); } static int usb_raw_ep0_stall(int fd) { return ioctl(fd, USB_RAW_IOCTL_EP0_STALL, 0); } static int lookup_interface(int fd, uint8_t bInterfaceNumber, uint8_t bAlternateSetting) { struct usb_device_index* index = lookup_usb_index(fd); if (!index) return -1; for (int i = 0; i < index->ifaces_num; i++) { if (index->ifaces[i].bInterfaceNumber == bInterfaceNumber && index->ifaces[i].bAlternateSetting == bAlternateSetting) return i; } return -1; } #define USB_MAX_PACKET_SIZE 4096 struct usb_raw_control_event { struct usb_raw_event inner; struct usb_ctrlrequest ctrl; char data[USB_MAX_PACKET_SIZE]; }; struct usb_raw_ep_io_data { struct usb_raw_ep_io inner; char data[USB_MAX_PACKET_SIZE]; }; static void set_interface(int fd, int n) { struct usb_device_index* index = lookup_usb_index(fd); if (!index) return; if (index->iface_cur >= 0 && index->iface_cur < index->ifaces_num) { for (int ep = 0; ep < index->ifaces[index->iface_cur].eps_num; ep++) { int rv = usb_raw_ep_disable(fd, index->ifaces[index->iface_cur].eps[ep].handle); if (rv < 0) { } else { } } } if (n >= 0 && n < index->ifaces_num) { for (int ep = 0; ep < index->ifaces[n].eps_num; ep++) { int rv = usb_raw_ep_enable(fd, &index->ifaces[n].eps[ep].desc); if (rv < 0) { } else { index->ifaces[n].eps[ep].handle = rv; } } index->iface_cur = n; } } static int configure_device(int fd) { struct usb_device_index* index = lookup_usb_index(fd); if (!index) return -1; int rv = usb_raw_vbus_draw(fd, index->bMaxPower); if (rv < 0) { return rv; } rv = usb_raw_configure(fd); if (rv < 0) { return rv; } set_interface(fd, 0); return 0; } static volatile long syz_usb_connect_impl(uint64_t speed, uint64_t dev_len, const char* dev, const struct vusb_connect_descriptors* descs, lookup_connect_out_response_t lookup_connect_response_out) { if (!dev) { return -1; } int fd = usb_raw_open(); if (fd < 0) { return fd; } if (fd >= MAX_FDS) { close(fd); return -1; } struct usb_device_index* index = add_usb_index(fd, dev, dev_len); if (!index) { return -1; } char device[32]; sprintf(&device[0], "dummy_udc.%llu", procid); int rv = usb_raw_init(fd, speed, "dummy_udc", &device[0]); if (rv < 0) { return rv; } rv = usb_raw_run(fd); if (rv < 0) { return rv; } bool done = false; while (!done) { struct usb_raw_control_event event; event.inner.type = 0; event.inner.length = sizeof(event.ctrl); rv = usb_raw_event_fetch(fd, (struct usb_raw_event*)&event); if (rv < 0) { return rv; } if (event.inner.type != USB_RAW_EVENT_CONTROL) continue; char* response_data = NULL; uint32_t response_length = 0; struct usb_qualifier_descriptor qual; if (event.ctrl.bRequestType & USB_DIR_IN) { if (!lookup_connect_response_in(fd, descs, &event.ctrl, &qual, &response_data, &response_length)) { usb_raw_ep0_stall(fd); continue; } } else { if (!lookup_connect_response_out(fd, descs, &event.ctrl, &done)) { usb_raw_ep0_stall(fd); continue; } response_data = NULL; response_length = event.ctrl.wLength; } if ((event.ctrl.bRequestType & USB_TYPE_MASK) == USB_TYPE_STANDARD && event.ctrl.bRequest == USB_REQ_SET_CONFIGURATION) { rv = configure_device(fd); if (rv < 0) { return rv; } } struct usb_raw_ep_io_data response; response.inner.ep = 0; response.inner.flags = 0; if (response_length > sizeof(response.data)) response_length = 0; if (event.ctrl.wLength < response_length) response_length = event.ctrl.wLength; response.inner.length = response_length; if (response_data) memcpy(&response.data[0], response_data, response_length); else memset(&response.data[0], 0, response_length); if (event.ctrl.bRequestType & USB_DIR_IN) { rv = usb_raw_ep0_write(fd, (struct usb_raw_ep_io*)&response); } else { rv = usb_raw_ep0_read(fd, (struct usb_raw_ep_io*)&response); } if (rv < 0) { return rv; } } sleep_ms(200); return fd; } static volatile long syz_usb_connect(volatile long a0, volatile long a1, volatile long a2, volatile long a3) { uint64_t speed = a0; uint64_t dev_len = a1; const char* dev = (const char*)a2; const struct vusb_connect_descriptors* descs = (const struct vusb_connect_descriptors*)a3; return syz_usb_connect_impl(speed, dev_len, dev, descs, &lookup_connect_response_out_generic); } static volatile long syz_usb_control_io(volatile long a0, volatile long a1, volatile long a2) { int fd = a0; const struct vusb_descriptors* descs = (const struct vusb_descriptors*)a1; const struct vusb_responses* resps = (const struct vusb_responses*)a2; struct usb_raw_control_event event; event.inner.type = 0; event.inner.length = USB_MAX_PACKET_SIZE; int rv = usb_raw_event_fetch(fd, (struct usb_raw_event*)&event); if (rv < 0) { return rv; } if (event.inner.type != USB_RAW_EVENT_CONTROL) { return -1; } char* response_data = NULL; uint32_t response_length = 0; if ((event.ctrl.bRequestType & USB_DIR_IN) && event.ctrl.wLength) { if (!lookup_control_response(descs, resps, &event.ctrl, &response_data, &response_length)) { usb_raw_ep0_stall(fd); return -1; } } else { if ((event.ctrl.bRequestType & USB_TYPE_MASK) == USB_TYPE_STANDARD || event.ctrl.bRequest == USB_REQ_SET_INTERFACE) { int iface_num = event.ctrl.wIndex; int alt_set = event.ctrl.wValue; int iface_index = lookup_interface(fd, iface_num, alt_set); if (iface_index < 0) { } else { set_interface(fd, iface_index); } } response_length = event.ctrl.wLength; } struct usb_raw_ep_io_data response; response.inner.ep = 0; response.inner.flags = 0; if (response_length > sizeof(response.data)) response_length = 0; if (event.ctrl.wLength < response_length) response_length = event.ctrl.wLength; if ((event.ctrl.bRequestType & USB_DIR_IN) && !event.ctrl.wLength) { response_length = USB_MAX_PACKET_SIZE; } response.inner.length = response_length; if (response_data) memcpy(&response.data[0], response_data, response_length); else memset(&response.data[0], 0, response_length); if ((event.ctrl.bRequestType & USB_DIR_IN) && event.ctrl.wLength) { rv = usb_raw_ep0_write(fd, (struct usb_raw_ep_io*)&response); } else { rv = usb_raw_ep0_read(fd, (struct usb_raw_ep_io*)&response); } if (rv < 0) { return rv; } sleep_ms(200); return 0; } static void kill_and_wait(int pid, int* status) { kill(-pid, SIGKILL); kill(pid, SIGKILL); for (int i = 0; i < 100; i++) { if (waitpid(-1, status, WNOHANG | __WALL) == pid) return; usleep(1000); } DIR* dir = opendir("/sys/fs/fuse/connections"); if (dir) { for (;;) { struct dirent* ent = readdir(dir); if (!ent) break; if (strcmp(ent->d_name, ".") == 0 || strcmp(ent->d_name, "..") == 0) continue; char abort[300]; snprintf(abort, sizeof(abort), "/sys/fs/fuse/connections/%s/abort", ent->d_name); int fd = open(abort, O_WRONLY); if (fd == -1) { continue; } if (write(fd, abort, 1) < 0) { } close(fd); } closedir(dir); } else { } while (waitpid(-1, status, __WALL) != pid) { } } static void setup_test() { prctl(PR_SET_PDEATHSIG, SIGKILL, 0, 0, 0); setpgrp(); write_file("/proc/self/oom_score_adj", "1000"); } static void execute_one(void); #define WAIT_FLAGS __WALL static void loop(void) { int iter = 0; for (;; iter++) { int pid = fork(); if (pid < 0) exit(1); if (pid == 0) { setup_test(); execute_one(); exit(0); } int status = 0; uint64_t start = current_time_ms(); for (;;) { sleep_ms(10); if (waitpid(-1, &status, WNOHANG | WAIT_FLAGS) == pid) break; if (current_time_ms() - start < 5000) continue; kill_and_wait(pid, &status); break; } } } uint64_t r[1] = {0xffffffffffffffff}; void execute_one(void) { intptr_t res = 0; if (write(1, "executing program\n", sizeof("executing program\n") - 1)) {} *(uint8_t*)0x200000000040 = 0x12; *(uint8_t*)0x200000000041 = 1; *(uint16_t*)0x200000000042 = 0x200; *(uint8_t*)0x200000000044 = 0; *(uint8_t*)0x200000000045 = 0; *(uint8_t*)0x200000000046 = 0; *(uint8_t*)0x200000000047 = 8; *(uint16_t*)0x200000000048 = 0x1038; *(uint16_t*)0x20000000004a = 0x1410; *(uint16_t*)0x20000000004c = 0; *(uint8_t*)0x20000000004e = 0; *(uint8_t*)0x20000000004f = 0; *(uint8_t*)0x200000000050 = 0; *(uint8_t*)0x200000000051 = 1; *(uint8_t*)0x200000000052 = 9; *(uint8_t*)0x200000000053 = 2; *(uint16_t*)0x200000000054 = 0x24; *(uint8_t*)0x200000000056 = 1; *(uint8_t*)0x200000000057 = 0; *(uint8_t*)0x200000000058 = 0; *(uint8_t*)0x200000000059 = 0; *(uint8_t*)0x20000000005a = 2; *(uint8_t*)0x20000000005b = 9; *(uint8_t*)0x20000000005c = 4; *(uint8_t*)0x20000000005d = 0; *(uint8_t*)0x20000000005e = 0; *(uint8_t*)0x20000000005f = 1; *(uint8_t*)0x200000000060 = 3; *(uint8_t*)0x200000000061 = 0; *(uint8_t*)0x200000000062 = 1; *(uint8_t*)0x200000000063 = 0; *(uint8_t*)0x200000000064 = 9; *(uint8_t*)0x200000000065 = 0x21; *(uint16_t*)0x200000000066 = 8; *(uint8_t*)0x200000000068 = 0xfd; *(uint8_t*)0x200000000069 = 1; *(uint8_t*)0x20000000006a = 0x22; *(uint16_t*)0x20000000006b = 0x29; *(uint8_t*)0x20000000006d = 9; *(uint8_t*)0x20000000006e = 5; *(uint8_t*)0x20000000006f = 0x81; *(uint8_t*)0x200000000070 = 3; *(uint16_t*)0x200000000071 = 0; *(uint8_t*)0x200000000073 = 0; *(uint8_t*)0x200000000074 = 0; *(uint8_t*)0x200000000075 = 0; res = -1; res = syz_usb_connect(/*speed=*/0, /*dev_len=*/0x36, /*dev=*/0x200000000040, /*conn_descs=*/0); if (res != -1) r[0] = res; syz_usb_control_io(/*fd=*/r[0], /*descs=*/0, /*resps=*/0); syscall(__NR_prctl, /*option=*/0x26ul, /*arg=*/1ul, 0, 0, 0); *(uint32_t*)0x200000000000 = 0x2c; *(uint64_t*)0x200000000004 = 0x2000000000c0; memcpy((void*)0x2000000000c0, "\x40\x0c\x2a\x00\x00\x00\x2a\x22\x5f\xab\xe9\x36\x24\xdb\xb2\x2d\x8b\x5a\xc8\x50\x1c\x70\x40\xb2\xad\xcf\x1f\xb3\xab\x7e\xd1\x6b\xbb\xbf\xa2\xa0\x80\x2a\x9e\x3f\x78\x95\xe5\x90\x2e\xdd\xcb\x54", 48); *(uint64_t*)0x20000000000c = 0; *(uint64_t*)0x200000000014 = 0; *(uint64_t*)0x20000000001c = 0; *(uint64_t*)0x200000000024 = 0; syz_usb_control_io(/*fd=*/r[0], /*descs=*/0x200000000000, /*resps=*/0); } int main(void) { syscall(__NR_mmap, /*addr=*/0x1ffffffff000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul); syscall(__NR_mmap, /*addr=*/0x200000000000ul, /*len=*/0x1000000ul, /*prot=PROT_WRITE|PROT_READ|PROT_EXEC*/7ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul); syscall(__NR_mmap, /*addr=*/0x200001000000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul); const char* reason; (void)reason; loop(); return 0; } I hope it helps. Best regards Jianzhou Zhao Penglei Jiang

5 months, 1 week

1
0
0 0

Qualcomm Supply Chain - Sinldo Technology

by Alan Ye

[Sinldo Technology] Company Profile Hong Kong Sinldo Technology Co., Ltd. was established in 2009 and focuses on the supply chain of Qualcomm chips. As a leading supplier in the industry, We have established solid cooperative relationships with many internationally renowned manufacturers and are committed to providing customers with high-quality and reliable chip products. Business Scope： Import and distribution of Qualcomm chips Management and bidding for excess electronic components Provide high-quality customer service and technical support Mission Stable supply Vision Mutual benefit and Triumph Value Reduce Fees and increase efficiency Environment The company is located in the core business district, with convenient transportation, elegant environment and complete surrounding supporting facilities, which facilitates the travel and business exchanges of employees and customers. Milestones 2025 2020 2015 2009 It is expected to complete the upgrade strategic planning, further increase market share, and strive for sustainable development The company implemented a digital management system and began to actively develop online Deals channels The company has added multiple 4G Qualcomm chips and established partnerships with more OEM customers。 The company was formally established in Shenzhen and initially established cooperative relationships with global suppliers Company Environment Coastal Huanqing Building Office Area storehouse [Qualcomm]Company Spot [ WIFI6 - IPQ5018 Kits ] IPQ5018-0-MRQFN232-MT-01-0 QCN6102-0-DRQFN116-TR-01-0 QCA8337-AL3C Snapdragon SDM-450-B Kits SDM-450-B-792NSP-TR-01-0-AA WTR-2965-0-59F0WNSP-TR-07-1 PMI-8952-0-144WLNSP-TR-02-0-00 WCN-3680B-0-79BWLNSP-TR-05-1 PM-8953-0-187F0WNSP-TR-01-1 MDM9x07 Kits MDM-9607-0-328PSP-TR-00-0 MDM-9207-0-328PSP-TR-00-0 WTR-2965-0-59F0WNSP-TR-07-1 PMD-9607-0-94WLNSP-TR-04-2 [Sinldo Technology Co., Ltd.] Email：yesunjian888(a)gmail.com Skype：625285556(a)qq.com Address：Room 2305, Hai'an Huanqing Building, Futian Road, Futian District, Shenzhen Wechat Hit subscribe now to receive regular updates and our product’s latest features! Subscribe If you don't want to receive our emails, you can easily unsubscribe here. Alan Ye Purchasing Manager ：+86 136 0651 6680 QUALCOMM Supply chain : yesunjian888(a)gmail.com

5 months, 1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2025