- Linux-stable-mirror - lists.linaro.org

[PATCH v2] powerpc: Add reloc_offset() to font bitmap pointer used for bootx_printf()

by Finn Thain

Since Linux v6.7, booting using BootX on an Old World PowerMac produces an early crash. Stan Johnson writes, "the symptoms are that the screen goes blank and the backlight stays on, and the system freezes (Linux doesn't boot)." Further testing revealed that the failure can be avoided by disabling CONFIG_BOOTX_TEXT. Bisection revealed that the regression was caused by a change to the font bitmap pointer that's used when btext_init() begins painting characters on the display, early in the boot process. Christophe Leroy explains, "before kernel text is relocated to its final location ... data is addressed with an offset which is added to the Global Offset Table (GOT) entries at the start of bootx_init() by function reloc_got2(). But the pointers that are located inside a structure are not referenced in the GOT and are therefore not updated by reloc_got2(). It is therefore needed to apply the offset manually by using PTRRELOC() macro." Cc: Cedar Maxwell <cedarmaxwell(a)mac.com> Cc: Stan Johnson <userm57(a)yahoo.com> Cc: "Dr. David Alan Gilbert" <linux(a)treblig.org> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> Cc: stable(a)vger.kernel.org Link: https://lists.debian.org/debian-powerpc/2025/10/msg00111.html Link: https://lore.kernel.org/linuxppc-dev/d81ddca8-c5ee-d583-d579-02b19ed95301@y… Reported-by: Cedar Maxwell <cedarmaxwell(a)mac.com> Closes: https://lists.debian.org/debian-powerpc/2025/09/msg00031.html Bisected-by: Stan Johnson <userm57(a)yahoo.com> Tested-by: Stan Johnson <userm57(a)yahoo.com> Fixes: 0ebc7feae79a ("powerpc: Use shared font data") Suggested-by: Christophe Leroy <christophe.leroy(a)csgroup.eu> Signed-off-by: Finn Thain <fthain(a)linux-m68k.org> --- Changed since v1: - Improved commit log entry to better explain the need for PTRRELOC(). --- arch/powerpc/kernel/btext.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/btext.c b/arch/powerpc/kernel/btext.c index 7f63f1cdc6c3..ca00c4824e31 100644 --- a/arch/powerpc/kernel/btext.c +++ b/arch/powerpc/kernel/btext.c @@ -20,6 +20,7 @@ #include <asm/io.h> #include <asm/processor.h> #include <asm/udbg.h> +#include <asm/setup.h> #define NO_SCROLL @@ -463,7 +464,7 @@ static noinline void draw_byte(unsigned char c, long locX, long locY) { unsigned char *base = calc_base(locX << 3, locY << 4); unsigned int font_index = c * 16; - const unsigned char *font = font_sun_8x16.data + font_index; + const unsigned char *font = PTRRELOC(font_sun_8x16.data) + font_index; int rb = dispDeviceRowBytes; rmci_maybe_on(); -- 2.49.1

1 day, 15 hours

3
3
0 0

[PATCH AUTOSEL 6.18-6.17] functionfs: fix the open/removal races

by Sasha Levin

From: Al Viro <viro(a)zeniv.linux.org.uk> [ Upstream commit e5bf5ee266633cb18fff6f98f0b7d59a62819eee ] ffs_epfile_open() can race with removal, ending up with file->private_data pointing to freed object. There is a total count of opened files on functionfs (both ep0 and dynamic ones) and when it hits zero, dynamic files get removed. Unfortunately, that removal can happen while another thread is in ffs_epfile_open(), but has not incremented the count yet. In that case open will succeed, leaving us with UAF on any subsequent read() or write(). The root cause is that ffs->opened is misused; atomic_dec_and_test() vs. atomic_add_return() is not a good idea, when object remains visible all along. To untangle that * serialize openers on ffs->mutex (both for ep0 and for dynamic files) * have dynamic ones use atomic_inc_not_zero() and fail if we had zero ->opened; in that case the file we are opening is doomed. * have the inodes of dynamic files marked on removal (from the callback of simple_recursive_removal()) - clear ->i_private there. * have open of dynamic ones verify they hadn't been already removed, along with checking that state is FFS_ACTIVE. Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Summary ### What the Commit Fixes This commit fixes a **Use-After-Free (UAF)** vulnerability in USB gadget functionfs. The race condition occurs between `ffs_epfile_open()` and file removal: 1. Thread A is in `ffs_epfile_open()` but hasn't incremented `ffs->opened` yet 2. Thread B closes the last file handle, triggering removal (since `opened` is 0) 3. Thread A's open succeeds with `file->private_data` pointing to freed memory 4. Subsequent `read()`/`write()` operations cause UAF ### Fix Mechanism The fix implements proper synchronization: - Serializes openers using `ffs->mutex` - Uses `atomic_inc_not_zero()` to fail if counter already zero - Uses `smp_load_acquire()`/`smp_store_release()` for memory ordering - Clears `i_private` during removal via `simple_recursive_removal()` callback - Uses `file->private_data` instead of `inode->i_private` in release path ### Stable Kernel Criteria Assessment | Criterion | Assessment | |-----------|------------| | Obviously correct | ✅ Uses standard kernel primitives, proper locking patterns | | Fixes real bug | ✅ UAF vulnerability, security-relevant | | Important issue | ✅ Security bug, potential for crashes/exploitation | | Small and contained | ✅ Single file, +43/-10 lines, localized changes | | No new features | ✅ Pure bug fix, no new APIs | ### Risk vs Benefit **Benefits:** - Fixes serious UAF vulnerability - USB gadget functionfs used in Android, embedded systems - Reviewed by Greg Kroah-Hartman (USB maintainer, stable maintainer) - Written by Al Viro (highly respected kernel developer) **Risks:** - Moderate complexity (changes locking behavior) - Recent commit (November 2025), limited mainline soak time - No explicit `Cc: stable(a)vger.kernel.org` tag ### Dependencies - `ffs_mutex_lock()` - exists in functionfs since early versions - `simple_recursive_removal()` with callback - available since ~5.x kernels - Standard kernel APIs (`atomic_inc_not_zero`, memory barriers) - universally available ### Concerns 1. **No Fixes: tag** - Makes it harder to determine which stable trees need this fix 2. **No Cc: stable tag** - May indicate maintainers wanted soak time, or an oversight given Greg KH reviewed it 3. **Backport effort** - May need adjustment for older stable trees depending on functionfs evolution ### Conclusion This is a legitimate UAF security fix that affects real-world users (Android, embedded USB gadgets). Despite moderate complexity, the fix: - Addresses a serious vulnerability class (UAF) - Uses correct synchronization patterns - Has been reviewed by the appropriate maintainer who also maintains stable trees - Is self-contained with no feature additions The lack of explicit stable tags appears to be an oversight given the security nature of the bug and Greg KH's review. UAF vulnerabilities typically warrant expedited backporting. **YES** drivers/usb/gadget/function/f_fs.c | 53 ++++++++++++++++++++++++------ 1 file changed, 43 insertions(+), 10 deletions(-) diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c index 47cfbe41fdff8..69f6e3c0f7e00 100644 --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -640,13 +640,22 @@ static ssize_t ffs_ep0_read(struct file *file, char __user *buf, static int ffs_ep0_open(struct inode *inode, struct file *file) { - struct ffs_data *ffs = inode->i_private; + struct ffs_data *ffs = inode->i_sb->s_fs_info; + int ret; - if (ffs->state == FFS_CLOSING) - return -EBUSY; + /* Acquire mutex */ + ret = ffs_mutex_lock(&ffs->mutex, file->f_flags & O_NONBLOCK); + if (ret < 0) + return ret; - file->private_data = ffs; ffs_data_opened(ffs); + if (ffs->state == FFS_CLOSING) { + ffs_data_closed(ffs); + mutex_unlock(&ffs->mutex); + return -EBUSY; + } + mutex_unlock(&ffs->mutex); + file->private_data = ffs; return stream_open(inode, file); } @@ -1193,14 +1202,33 @@ static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data *io_data) static int ffs_epfile_open(struct inode *inode, struct file *file) { - struct ffs_epfile *epfile = inode->i_private; + struct ffs_data *ffs = inode->i_sb->s_fs_info; + struct ffs_epfile *epfile; + int ret; - if (WARN_ON(epfile->ffs->state != FFS_ACTIVE)) + /* Acquire mutex */ + ret = ffs_mutex_lock(&ffs->mutex, file->f_flags & O_NONBLOCK); + if (ret < 0) + return ret; + + if (!atomic_inc_not_zero(&ffs->opened)) { + mutex_unlock(&ffs->mutex); + return -ENODEV; + } + /* + * we want the state to be FFS_ACTIVE; FFS_ACTIVE alone is + * not enough, though - we might have been through FFS_CLOSING + * and back to FFS_ACTIVE, with our file already removed. + */ + epfile = smp_load_acquire(&inode->i_private); + if (unlikely(ffs->state != FFS_ACTIVE || !epfile)) { + mutex_unlock(&ffs->mutex); + ffs_data_closed(ffs); return -ENODEV; + } + mutex_unlock(&ffs->mutex); file->private_data = epfile; - ffs_data_opened(epfile->ffs); - return stream_open(inode, file); } @@ -1332,7 +1360,7 @@ static void ffs_dmabuf_put(struct dma_buf_attachment *attach) static int ffs_epfile_release(struct inode *inode, struct file *file) { - struct ffs_epfile *epfile = inode->i_private; + struct ffs_epfile *epfile = file->private_data; struct ffs_dmabuf_priv *priv, *tmp; struct ffs_data *ffs = epfile->ffs; @@ -2352,6 +2380,11 @@ static int ffs_epfiles_create(struct ffs_data *ffs) return 0; } +static void clear_one(struct dentry *dentry) +{ + smp_store_release(&dentry->d_inode->i_private, NULL); +} + static void ffs_epfiles_destroy(struct ffs_epfile *epfiles, unsigned count) { struct ffs_epfile *epfile = epfiles; @@ -2359,7 +2392,7 @@ static void ffs_epfiles_destroy(struct ffs_epfile *epfiles, unsigned count) for (; count; --count, ++epfile) { BUG_ON(mutex_is_locked(&epfile->mutex)); if (epfile->dentry) { - simple_recursive_removal(epfile->dentry, NULL); + simple_recursive_removal(epfile->dentry, clear_one); epfile->dentry = NULL; } } -- 2.51.0

1 day, 16 hours

1
19
0 0

回复:6.12.50 regression: netem: cannot mix duplicating netems with other netems in tree.

by zyc zyc

Hello, Resend my last email without HTML. ---- zyc zyc <zyc199902(a)zohomail.cn> 在 Sat, 2025-11-29 18:57:01 写到：--- > Hello, maintainer > > I would like to report what appears to be a regression in 6.12.50 kernel release related to netem. > It rejects our configuration with the message: > Error: netem: cannot mix duplicating netems with other netems in tree. > > This breaks setups that previously worked correctly for many years. > > > Our team uses multiple netem qdiscs in the same HTB branch, arranged in a parallel fashion using a prio fan-out. Each branch of the prio qdisc has its own distinct netem instance with different duplication characteristics. > > This is used to emulate our production conditions where a single logical path fans out into two downstream segments, for example: > > two ECMP next hops with different misbehaviour characteristics, or > > > an HA firewall cluster where only one node is replaying frames, or > > > two LAG / ToR paths where one path intermittently duplicates packets. > > > In our environments, only a subset of flows are affected, and different downstream devices may cause different styles of duplication. > This regression breaks existing automated tests, training environments, and network simulation pipelines. > > I would be happy to provide our reproducer if needed. > > Thank you for your time and for maintaining Linux kernel. > > > > Best regards, > zyc > > >

1 day, 16 hours

3
6
0 0

[PATCH v2] pmdomain: imx: Fix reference count leak in imx_gpc_probe()

by Wentao Liang

of_get_child_by_name() returns a node pointer with refcount incremented, we should use the __free() attribute to manage the pgc_node reference. This ensures automatic of_node_put() cleanup when pgc_node goes out of scope, eliminating the need for explicit error handling paths and avoiding reference count leaks. Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC driver") Cc: stable(a)vger.kernel.org Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- Change in V2: - Use __free() attribute instead of explicit of_node_put() calls --- drivers/pmdomain/imx/gpc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pmdomain/imx/gpc.c b/drivers/pmdomain/imx/gpc.c index f18c7e6e75dd..89d5d68c055d 100644 --- a/drivers/pmdomain/imx/gpc.c +++ b/drivers/pmdomain/imx/gpc.c @@ -403,7 +403,7 @@ static int imx_gpc_old_dt_init(struct device *dev, struct regmap *regmap, static int imx_gpc_probe(struct platform_device *pdev) { const struct imx_gpc_dt_data *of_id_data = device_get_match_data(&pdev->dev); - struct device_node *pgc_node; + struct device_node *pgc_node __free(pgc_node); struct regmap *regmap; void __iomem *base; int ret; -- 2.34.1

1 day, 16 hours

3
2
0 0

[PATCH] media: cx23885: Add missing unmap in snd_cx23885_hw_params()

by Haoxiang Li

In error path, add cx23885_alsa_dma_unmap() to release the resource acquired by cx23885_alsa_dma_map(). Fixes: 9529a4b0cf49 ("[media] cx23885: drop videobuf abuse in cx23885-alsa") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/media/pci/cx23885/cx23885-alsa.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/pci/cx23885/cx23885-alsa.c b/drivers/media/pci/cx23885/cx23885-alsa.c index 25dc8d4dc5b7..717fc6c9ef21 100644 --- a/drivers/media/pci/cx23885/cx23885-alsa.c +++ b/drivers/media/pci/cx23885/cx23885-alsa.c @@ -392,8 +392,10 @@ static int snd_cx23885_hw_params(struct snd_pcm_substream *substream, ret = cx23885_risc_databuffer(chip->pci, &buf->risc, buf->sglist, chip->period_size, chip->num_periods, 1); - if (ret < 0) + if (ret < 0) { + cx23885_alsa_dma_unmap(chip); goto error; + } /* Loop back to start of program */ buf->risc.jmp[0] = cpu_to_le32(RISC_JUMP|RISC_IRQ1|RISC_CNT_INC); -- 2.25.1

1 day, 16 hours

1
0
0 0

[PATCH] media: cx88: Add missing unmap in snd_cx88_hw_params()

by Haoxiang Li

In error path, add cx88_alsa_dma_unmap() to release resource acquired by cx88_alsa_dma_map(). Fixes: b2c75abde0de ("[media] cx88: drop videobuf abuse in cx88-alsa") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/media/pci/cx88/cx88-alsa.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/pci/cx88/cx88-alsa.c b/drivers/media/pci/cx88/cx88-alsa.c index 29fb1311e443..4e574d8390b4 100644 --- a/drivers/media/pci/cx88/cx88-alsa.c +++ b/drivers/media/pci/cx88/cx88-alsa.c @@ -483,8 +483,10 @@ static int snd_cx88_hw_params(struct snd_pcm_substream *substream, ret = cx88_risc_databuffer(chip->pci, &buf->risc, buf->sglist, chip->period_size, chip->num_periods, 1); - if (ret < 0) + if (ret < 0) { + cx88_alsa_dma_unmap(chip); goto error; + } /* Loop back to start of program */ buf->risc.jmp[0] = cpu_to_le32(RISC_JUMP | RISC_IRQ1 | RISC_CNT_INC); -- 2.25.1

1 day, 17 hours

1
0
0 0

[PATCH] media: cx25821: Add missing unmap in snd_cx25821_hw_params()

by Haoxiang Li

In error path, add cx25821_alsa_dma_unmap() to release the resource acquired by cx25821_alsa_dma_map() Fixes: b2c75abde0de ("[media] cx88: drop videobuf abuse in cx88-alsa") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/media/pci/cx25821/cx25821-alsa.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/pci/cx25821/cx25821-alsa.c b/drivers/media/pci/cx25821/cx25821-alsa.c index a42f0c03a7ca..f463365163b7 100644 --- a/drivers/media/pci/cx25821/cx25821-alsa.c +++ b/drivers/media/pci/cx25821/cx25821-alsa.c @@ -535,6 +535,7 @@ static int snd_cx25821_hw_params(struct snd_pcm_substream *substream, chip->period_size, chip->num_periods, 1); if (ret < 0) { pr_info("DEBUG: ERROR after cx25821_risc_databuffer_audio()\n"); + cx25821_alsa_dma_unmap(chip); goto error; } -- 2.25.1

1 day, 17 hours

1
0
0 0

[PATCH 1/2] scsi: sd: fix write_same(16/10) to enable sector size > PAGE_SIZE

by sw.prabhu6＠gmail.com

From: Swarna Prabhu <sw.prabhu6(a)gmail.com> The WRITE SAME(16) and WRITE SAME(10) scsi commands uses a page from a dedicated mempool('sd_page_pool') for its payload. This pool was initialized to allocate single pages, which was sufficient as long as the device sector size did not exceed the PAGE_SIZE. Given that block layer now supports block size upto 64K ie beyond PAGE_SIZE, adapt sd_set_special_bvec() to accommodate that. With the above fix, enable sector sizes > PAGE_SIZE in scsi sd driver. Cc: stable(a)vger.kernel.org Signed-off-by: Swarna Prabhu <s.prabhu(a)samsung.com> Co-developed-by: Pankaj Raghav <p.raghav(a)samsung.com> Signed-off-by: Pankaj Raghav <p.raghav(a)samsung.com> --- Note: We are allocating pages of order aligned to BLK_MAX_BLOCK_SIZE for the mempool page allocator 'sd_page_pool' all the time. This is because we only know that a bigger sector size device is attached at sd_probe and it might be too late to reallocate mempool with order >0. drivers/scsi/sd.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 0252d3f6bed1..17b5c1589eb2 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -892,14 +892,24 @@ static void sd_config_discard(struct scsi_disk *sdkp, struct queue_limits *lim, (logical_block_size >> SECTOR_SHIFT); } -static void *sd_set_special_bvec(struct request *rq, unsigned int data_len) +static void *sd_set_special_bvec(struct scsi_cmnd *cmd, unsigned int data_len) { struct page *page; + struct request *rq = scsi_cmd_to_rq(cmd); + struct scsi_device *sdp = cmd->device; + unsigned sector_size = sdp->sector_size; + unsigned int nr_pages = DIV_ROUND_UP(sector_size, PAGE_SIZE); + int n = 0; page = mempool_alloc(sd_page_pool, GFP_ATOMIC); if (!page) return NULL; - clear_highpage(page); + + do { + clear_highpage(page + n); + n++; + } while (n < nr_pages); + bvec_set_page(&rq->special_vec, page, data_len, 0); rq->rq_flags |= RQF_SPECIAL_PAYLOAD; return bvec_virt(&rq->special_vec); @@ -915,7 +925,7 @@ static blk_status_t sd_setup_unmap_cmnd(struct scsi_cmnd *cmd) unsigned int data_len = 24; char *buf; - buf = sd_set_special_bvec(rq, data_len); + buf = sd_set_special_bvec(cmd, data_len); if (!buf) return BLK_STS_RESOURCE; @@ -1004,7 +1014,7 @@ static blk_status_t sd_setup_write_same16_cmnd(struct scsi_cmnd *cmd, u32 nr_blocks = sectors_to_logical(sdp, blk_rq_sectors(rq)); u32 data_len = sdp->sector_size; - if (!sd_set_special_bvec(rq, data_len)) + if (!sd_set_special_bvec(cmd, data_len)) return BLK_STS_RESOURCE; cmd->cmd_len = 16; @@ -1031,7 +1041,7 @@ static blk_status_t sd_setup_write_same10_cmnd(struct scsi_cmnd *cmd, u32 nr_blocks = sectors_to_logical(sdp, blk_rq_sectors(rq)); u32 data_len = sdp->sector_size; - if (!sd_set_special_bvec(rq, data_len)) + if (!sd_set_special_bvec(cmd, data_len)) return BLK_STS_RESOURCE; cmd->cmd_len = 10; @@ -2880,10 +2890,7 @@ sd_read_capacity(struct scsi_disk *sdkp, struct queue_limits *lim, "assuming 512.\n"); } - if (sector_size != 512 && - sector_size != 1024 && - sector_size != 2048 && - sector_size != 4096) { + if (blk_validate_block_size(sector_size)) { sd_printk(KERN_NOTICE, sdkp, "Unsupported sector size %d.\n", sector_size); /* @@ -4368,7 +4375,7 @@ static int __init init_sd(void) if (err) goto err_out; - sd_page_pool = mempool_create_page_pool(SD_MEMPOOL_SIZE, 0); + sd_page_pool = mempool_create_page_pool(SD_MEMPOOL_SIZE, get_order(BLK_MAX_BLOCK_SIZE)); if (!sd_page_pool) { printk(KERN_ERR "sd: can't init discard page pool\n"); err = -ENOMEM; -- 2.51.0

1 day, 18 hours

2
1
0 0

[PATCH v2] x86/elf: Fix core dump truncation on CPUs with no extended xfeatures

by yongxin.liu＠windriver.com

From: Yongxin Liu <yongxin.liu(a)windriver.com> Zero can be a valid value of num_records. For example, on Intel Atom x6425RE, only x87 and SSE are supported (features 0, 1), and fpu_user_cfg.max_features is 3. The for_each_extended_xfeature() loop only iterates feature 2, which is not enabled, so num_records = 0. This is valid and should not cause core dump failure. The issue is that dump_xsave_layout_desc() returns 0 for both genuine errors (dump_emit() failure) and valid cases (no extended features). Use negative return values for errors and only abort on genuine failures. Cc: stable(a)vger.kernel.org Fixes: ba386777a30b ("x86/elf: Add a new FPU buffer layout info to x86 core files") Signed-off-by: Yongxin Liu <yongxin.liu(a)windriver.com> --- V2: Keep error checking but use negative value for genuine error V1: Remove error checking entirely --- arch/x86/kernel/fpu/xstate.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c index 48113c5193aa..76153dfb58c9 100644 --- a/arch/x86/kernel/fpu/xstate.c +++ b/arch/x86/kernel/fpu/xstate.c @@ -1946,7 +1946,7 @@ static int dump_xsave_layout_desc(struct coredump_params *cprm) }; if (!dump_emit(cprm, &xc, sizeof(xc))) - return 0; + return -1; num_records++; } @@ -1984,7 +1984,7 @@ int elf_coredump_extra_notes_write(struct coredump_params *cprm) return 1; num_records = dump_xsave_layout_desc(cprm); - if (!num_records) + if (num_records < 0) return 1; /* Total size should be equal to the number of records */ -- 2.46.2

1 day, 19 hours

1
0
0 0

[PATCH] x86/elf: Fix core dump truncation on CPUs with no extended xfeatures

by yongxin.liu＠windriver.com

From: Yongxin Liu <yongxin.liu(a)windriver.com> Zero can be a valid value of num_records. For example, on Intel Atom x6425RE, only x87 and SSE are supported (features 0, 1), and fpu_user_cfg.max_features is 3. The for_each_extended_xfeature() loop only iterates feature 2, which is not enabled, so num_records = 0. This is valid and should not cause core dump failure. The size check already validates consistency: if num_records = 0, then en.n_descsz = 0, so the check passes. Cc: stable(a)vger.kernel.org Fixes: ba386777a30b ("x86/elf: Add a new FPU buffer layout info to x86 core files") Signed-off-by: Yongxin Liu <yongxin.liu(a)windriver.com> --- arch/x86/kernel/fpu/xstate.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c index 48113c5193aa..b1dd30eb21a8 100644 --- a/arch/x86/kernel/fpu/xstate.c +++ b/arch/x86/kernel/fpu/xstate.c @@ -1984,8 +1984,6 @@ int elf_coredump_extra_notes_write(struct coredump_params *cprm) return 1; num_records = dump_xsave_layout_desc(cprm); - if (!num_records) - return 1; /* Total size should be equal to the number of records */ if ((sizeof(struct x86_xfeat_component) * num_records) != en.n_descsz) -- 2.46.2

1 day, 20 hours

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror