January 2025 - Linux-stable-mirror

[PATCH 5.10] xfs: add bounds checking to xlog_recover_process_data

by Denis Arefev

From: lei lu <llfamsec(a)gmail.com> commit fb63435b7c7dc112b1ae1baea5486e0a6e27b196 upstream. There is a lack of verification of the space occupied by fixed members of xlog_op_header in the xlog_recover_process_data. We can create a crafted image to trigger an out of bounds read by following these steps: 1) Mount an image of xfs, and do some file operations to leave records 2) Before umounting, copy the image for subsequent steps to simulate abnormal exit. Because umount will ensure that tail_blk and head_blk are the same, which will result in the inability to enter xlog_recover_process_data 3) Write a tool to parse and modify the copied image in step 2 4) Make the end of the xlog_op_header entries only 1 byte away from xlog_rec_header->h_size 5) xlog_rec_header->h_num_logops++ 6) Modify xlog_rec_header->h_crc Fix: Add a check to make sure there is sufficient space to access fixed members of xlog_op_header. Signed-off-by: lei lu <llfamsec(a)gmail.com> Reviewed-by: Dave Chinner <dchinner(a)redhat.com> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> Signed-off-by: Chandan Babu R <chandanbabu(a)kernel.org> Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2024-41014 Link: https://nvd.nist.gov/vuln/detail/cve-2024-41014 --- fs/xfs/xfs_log_recover.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c index e61f28ce3e44..eafe76f304ef 100644 --- a/fs/xfs/xfs_log_recover.c +++ b/fs/xfs/xfs_log_recover.c @@ -2419,7 +2419,10 @@ xlog_recover_process_data( ohead = (struct xlog_op_header *)dp; dp += sizeof(*ohead); - ASSERT(dp <= end); + if (dp > end) { + xfs_warn(log->l_mp, "%s: op header overrun", __func__); + return -EFSCORRUPTED; + } /* errors will abort recovery */ error = xlog_recover_process_ophdr(log, rhash, rhead, ohead, -- 2.43.0

3 weeks, 3 days

1
0
0 0

[PATCH 5.10] drm/radeon: check bo_va->bo is non-NULL before using it

by Denis Arefev

From: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> commit 6fb15dcbcf4f212930350eaee174bb60ed40a536 upstream. The call to radeon_vm_clear_freed might clear bo_va->bo, so we have to check it before dereferencing it. Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> Acked-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix CVE-2024-41060 Link: https://nvd.nist.gov/vuln/detail/CVE-2024-41060 --- drivers/gpu/drm/radeon/radeon_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index 75053917d213..51b6f38b5c47 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -582,7 +582,7 @@ static void radeon_gem_va_update_vm(struct radeon_device *rdev, if (r) goto error_unlock; - if (bo_va->it.start) + if (bo_va->it.start && bo_va->bo) r = radeon_vm_bo_update(rdev, bo_va, &bo_va->bo->tbo.mem); error_unlock: -- 2.43.0

3 weeks, 3 days

1
0
0 0

[PATCH 1/2] PCI/MSI: Add MSIX option to write to ENTRY_DATA before any reads

by dullfire＠yahoo.com

From: Jonathan Currier <dullfire(a)yahoo.com> Commit 7d5ec3d36123 ("PCI/MSI: Mask all unused MSI-X entries") introduces a readl() from ENTRY_VECTOR_CTRL before the writel() to ENTRY_DATA. This is correct, however some hardware, like the Sun Neptune chips, the niu module, will cause an error and/or fatal trap if any MSIX table entry is read before the corresponding ENTRY_DATA field is written to. This patch adds an optional early writel() in msix_prepare_msi_desc(). Cc: stable(a)vger.kernel.org Signed-off-by: Jonathan Currier <dullfire(a)yahoo.com> --- drivers/pci/msi/msi.c | 2 ++ include/linux/pci.h | 2 ++ 2 files changed, 4 insertions(+) diff --git a/drivers/pci/msi/msi.c b/drivers/pci/msi/msi.c index 3a45879d85db..50d87fb5e37f 100644 --- a/drivers/pci/msi/msi.c +++ b/drivers/pci/msi/msi.c @@ -611,6 +611,8 @@ void msix_prepare_msi_desc(struct pci_dev *dev, struct msi_desc *desc) if (desc->pci.msi_attrib.can_mask) { void __iomem *addr = pci_msix_desc_addr(desc); + if (dev->dev_flags & PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST) + writel(0, addr + PCI_MSIX_ENTRY_DATA); desc->pci.msix_ctrl = readl(addr + PCI_MSIX_ENTRY_VECTOR_CTRL); } } diff --git a/include/linux/pci.h b/include/linux/pci.h index 37d97bef060f..b8b95b58d522 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -245,6 +245,8 @@ enum pci_dev_flags { PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 11), /* Device does honor MSI masking despite saying otherwise */ PCI_DEV_FLAGS_HAS_MSI_MASKING = (__force pci_dev_flags_t) (1 << 12), + /* Device requires write to PCI_MSIX_ENTRY_DATA before any MSIX reads */ + PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST = (__force pci_dev_flags_t) (1 << 13), }; enum pci_irq_reroute_variant { -- 2.45.2

3 weeks, 3 days

3
4
0 0

[PATCH] ibmvnic: Add tx check to prevent skb leak

by Denis Arefev

From: Nick Child <nnac123(a)linux.ibm.com> From: Nick Child <nnac123(a)linux.ibm.com> commit 0983d288caf984de0202c66641577b739caad561 upstream. Below is a summary of how the driver stores a reference to an skb during transmit: tx_buff[free_map[consumer_index]]->skb = new_skb; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index ++; Where variable data looks like this: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] consumer_index^ tx_buff == [skb=null, skb=<ptr>, skb=<ptr>, skb=null, skb=null] The driver has checks to ensure that free_map[consumer_index] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our free_map and tx_buff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT. Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems. Signed-off-by: Nick Child <nnac123(a)linux.ibm.com> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2024-41066 Link: https://nvd.nist.gov/vuln/detail/CVE-2024-41066 --- drivers/net/ethernet/ibm/ibmvnic.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c index 84da6ccaf339..439796975cbf 100644 --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -1625,6 +1625,18 @@ static netdev_tx_t ibmvnic_xmit(struct sk_buff *skb, struct net_device *netdev) (tx_pool->consumer_index + 1) % tx_pool->num_buffers; tx_buff = &tx_pool->tx_buff[index]; + + /* Sanity checks on our free map to make sure it points to an index + * that is not being occupied by another skb. If skb memory is + * not freed then we see congestion control kick in and halt tx. + */ + if (unlikely(tx_buff->skb)) { + dev_warn_ratelimited(dev, "TX free map points to untracked skb (%s %d idx=%d)\n", + skb_is_gso(skb) ? "tso_pool" : "tx_pool", + queue_num, bufidx); + dev_kfree_skb_any(tx_buff->skb); + } + tx_buff->skb = skb; tx_buff->data_dma[0] = data_dma_addr; tx_buff->data_len[0] = skb->len; -- 2.43.0

3 weeks, 3 days

1
0
0 0

[PATCH 5.10] fou: remove warn in gue_gro_receive on unsupported protocol

by Denis Arefev

From: Willem de Bruijn <willemb(a)google.com> commit dd89a81d850fa9a65f67b4527c0e420d15bf836c upstream. Drop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is not known or does not have a GRO handler. Such a packet is easily constructed. Syzbot generates them and sets off this warning. Remove the warning as it is expected and not actionable. The warning was previously reduced from WARN_ON to WARN_ON_ONCE in commit 270136613bf7 ("fou: Do WARN_ON_ONCE in gue_gro_receive for bad proto callbacks"). Signed-off-by: Willem de Bruijn <willemb(a)google.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Link: https://lore.kernel.org/r/20240614122552.1649044-1-willemdebruijn.kernel@gm… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2024-44940 Link: https://www.cve.org/CVERecord/?id=CVE-2024-44940 --- net/ipv4/fou.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c index 1d67df4d8ed6..b1a8e4eec3f6 100644 --- a/net/ipv4/fou.c +++ b/net/ipv4/fou.c @@ -453,7 +453,7 @@ static struct sk_buff *gue_gro_receive(struct sock *sk, offloads = NAPI_GRO_CB(skb)->is_ipv6 ? inet6_offloads : inet_offloads; ops = rcu_dereference(offloads[proto]); - if (WARN_ON_ONCE(!ops || !ops->callbacks.gro_receive)) + if (!ops || !ops->callbacks.gro_receive) goto out; pp = call_gro_receive(ops->callbacks.gro_receive, head, skb); -- 2.43.0

3 weeks, 3 days

1
0
0 0

[PATCH 1/1] iommu/vt-d: Make intel_iommu_drain_pasid_prq() cover faults for RID

by Lu Baolu

This driver supports page faults on PCI RID since commit <9f831c16c69e> ("iommu/vt-d: Remove the pasid present check in prq_event_thread") by allowing the reporting of page faults with the pasid_present field cleared to the upper layer for further handling. The fundamental assumption here is that the detach or replace operations act as a fence for page faults. This implies that all pending page faults associated with a specific RID or PASID are flushed when a domain is detached or replaced from a device RID or PASID. However, the intel_iommu_drain_pasid_prq() helper does not correctly handle faults for RID. This leads to faults potentially remaining pending in the iommu hardware queue even after the domain is detached, thereby violating the aforementioned assumption. Fix this issue by extending intel_iommu_drain_pasid_prq() to cover faults for RID. Fixes: 9f831c16c69e ("iommu/vt-d: Remove the pasid present check in prq_event_thread") Cc: stable(a)vger.kernel.org Suggested-by: Kevin Tian <kevin.tian(a)intel.com> Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com> --- drivers/iommu/intel/prq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel/prq.c b/drivers/iommu/intel/prq.c index c2d792db52c3..043f02d7b460 100644 --- a/drivers/iommu/intel/prq.c +++ b/drivers/iommu/intel/prq.c @@ -87,7 +87,8 @@ void intel_iommu_drain_pasid_prq(struct device *dev, u32 pasid) struct page_req_dsc *req; req = &iommu->prq[head / sizeof(*req)]; - if (!req->pasid_present || req->pasid != pasid) { + if (req->rid != sid || + (req->pasid_present && req->pasid != pasid)) { head = (head + sizeof(*req)) & PRQ_RING_MASK; continue; } -- 2.43.0

3 weeks, 3 days

3
3
0 0

Integrated Systems Europe 2025 Exhibitors List!

by Grace Green

Hi, Are you interested in the latest attendee and exhibitor lists for Integrated Systems Europe 2025? This comprehensive database now includes last-minute registrants, providing you with up-to-date and actionable insights. Event Details: Dates: 04 - 07 Feb 2025 Location: Fira Barcelona Gran Via, Barcelona, Spain Exhibitors: 1,460 Attendees: 73,891 Data fields: Induvial Email address, Cell Phone Number, Contact Name, Job Title, Company Name, Company website, Physical Address and more), Would you like details on the attendees list, exhibitors list, or both? Let me know, and I’ll be happy to share pricing details and answer any questions. Looking forward to hearing from you! Best regards, Grace Green Sr. Demand Generation P.S. If you’d prefer not to receive updates, simply reply with “NO.”

3 weeks, 3 days

1
0
0 0

[PATCH 1/3] perf/x86: Fix low freq setting issue

by kan.liang＠linux.intel.com

From: Kan Liang <kan.liang(a)linux.intel.com> Perf doesn't work with a low freq. perf record -e cpu_core/instructions/ppp -F 120 Error: The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (cpu_core/instructions/ppp). "dmesg | grep -i perf" may provide additional information. The limit_period() check avoids a low sampling period on a counter. It doesn't intend to limit the frequency. The check in the x86_pmu_hw_config() should be limited to non-freq mode. The attr.sample_period and attr.sample_freq are union. The attr.sample_period should not be used to indicate the freq mode. Fixes: c46e665f0377 ("perf/x86: Add INST_RETIRED.ALL workarounds") Closes: https://lore.kernel.org/lkml/20250115154949.3147-1-ravi.bangoria@amd.com/ Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: Ravi Bangoria <ravi.bangoria(a)amd.com> Cc: stable(a)vger.kernel.org --- arch/x86/events/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 7b6430e5a77b..20ad5cca6ad2 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -630,7 +630,7 @@ int x86_pmu_hw_config(struct perf_event *event) if (event->attr.type == event->pmu->type) event->hw.config |= x86_pmu_get_event_config(event); - if (event->attr.sample_period && x86_pmu.limit_period) { + if (!event->attr.freq && x86_pmu.limit_period) { s64 left = event->attr.sample_period; x86_pmu.limit_period(event, &left); if (left > event->attr.sample_period) -- 2.38.1

3 weeks, 3 days

2
3
0 0

[PATCH] cpufreq: s3c64xx: Fix compilation warning

by Viresh Kumar

The driver generates following warning when regulator support isn't enabled in the kernel. Fix it. drivers/cpufreq/s3c64xx-cpufreq.c: In function 's3c64xx_cpufreq_set_target': >> drivers/cpufreq/s3c64xx-cpufreq.c:55:22: warning: variable 'old_freq' set but not used [-Wunused-but-set-variable] 55 | unsigned int old_freq, new_freq; | ^~~~~~~~ >> drivers/cpufreq/s3c64xx-cpufreq.c:54:30: warning: variable 'dvfs' set but not used [-Wunused-but-set-variable] 54 | struct s3c64xx_dvfs *dvfs; | ^~~~ Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501191803.CtfT7b2o-lkp@intel.com/ Cc: <stable(a)vger.kernel.org> # v5.4+ Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- drivers/cpufreq/s3c64xx-cpufreq.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/cpufreq/s3c64xx-cpufreq.c b/drivers/cpufreq/s3c64xx-cpufreq.c index c6bdfc308e99..8fc43a74cefb 100644 --- a/drivers/cpufreq/s3c64xx-cpufreq.c +++ b/drivers/cpufreq/s3c64xx-cpufreq.c @@ -51,15 +51,16 @@ static struct cpufreq_frequency_table s3c64xx_freq_table[] = { static int s3c64xx_cpufreq_set_target(struct cpufreq_policy *policy, unsigned int index) { - struct s3c64xx_dvfs *dvfs; - unsigned int old_freq, new_freq; + unsigned int new_freq = s3c64xx_freq_table[index].frequency; int ret; +#ifdef CONFIG_REGULATOR + struct s3c64xx_dvfs *dvfs; + unsigned int old_freq; + old_freq = clk_get_rate(policy->clk) / 1000; - new_freq = s3c64xx_freq_table[index].frequency; dvfs = &s3c64xx_dvfs_table[s3c64xx_freq_table[index].driver_data]; -#ifdef CONFIG_REGULATOR if (vddarm && new_freq > old_freq) { ret = regulator_set_voltage(vddarm, dvfs->vddarm_min, -- 2.31.1.272.g89b43f80a514

3 weeks, 3 days

1
0
0 0

Kernel bug found in linux6.9-rc7

by ffhgfv

Hello, I found a bug titled “ kernel BUG in ocfs2_refcount_cal_cow_clusters” with modified syzkaller in the Linux6.9-rc7 relegated to oracle cluster file system. If you fix this issue, please add the following tag to the commit: Reported-by:jianzhou zhao <xnxc22xnxc22(a)qq.com> , xingwei lee < xrivendell7(a)gmail.com> ------------[ cut here ]------------ Title: 'kernel BUG in ocfs2_refcount_cal_cow_clusters'  ocfs2: Mounting device (7,0) on (node local, slot 0) with writeback data mode. kernel BUG at fs/ocfs2/refcounttree.c:2684! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 7960 Comm: syz-executor385 Not tainted 6.9.0-rc7 #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:ocfs2_refcount_cal_cow_clusters+0x667/0x960 fs/ocfs2/refcounttree.c:2684 Code: f3 45 86 48 c7 c6 c0 32 5a 85 4d 8b 44 24 18 48 8b 48 40 48 8b 78 28 e8 67 29 05 00 41 89 c4 e9 e5 fd ff ff e8 4a 14 40 ff 90 <0f> 0b e8 42 14 40 ff 48 8b 55 a8 44 89 e8 44 89 fb 44 29 f8 89 02 RSP: 0018:ffff8880462cfba0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880528b04d0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8880462cfc18 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 FS:  0000555576e563c0(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000d000 CR3: 0000000045e3e000 CR4: 0000000000750ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace:  <TASK>  ocfs2_refcount_cow_hunk+0x98/0x550 fs/ocfs2/refcounttree.c:3394  ocfs2_refcount_cow+0x65/0x2e0 fs/ocfs2/refcounttree.c:3476  ocfs2_prepare_inode_for_write.isra.0+0x630/0x970 fs/ocfs2/file.c:2326  ocfs2_file_write_iter+0x23d/0xb10 fs/ocfs2/file.c:2435  call_write_iter include/linux/fs.h:2110 [inline]  new_sync_write fs/read_write.c:497 [inline]  vfs_write+0x5a0/0x6e0 fs/read_write.c:590  ksys_write+0x9b/0x160 fs/read_write.c:643  __do_sys_write fs/read_write.c:655 [inline]  __se_sys_write fs/read_write.c:652 [inline]  __x64_sys_write+0x21/0x40 fs/read_write.c:652  x64_sys_call+0x1889/0x2680 arch/x86/include/generated/asm/syscalls_64.h:2  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xa8/0x1f0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb511ea303d Code: c3 e8 c7 24 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff6b9aefa8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fb511ea303d RDX: 0000000000000001 RSI: 0000000020000280 RDI: 0000000000000009 RBP: 00007fff6b9af040 R08: 0000000000000140 R09: 0000000000000140 R10: 0000000000000140 R11: 0000000000000246 R12: 0000000000000000 R13: 00000000000f4240 R14: 00007fff6b9aefc4 R15: 00007fff6b9aefd0  </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:ocfs2_refcount_cal_cow_clusters+0x667/0x960 fs/ocfs2/refcounttree.c:2684 Code: f3 45 86 48 c7 c6 c0 32 5a 85 4d 8b 44 24 18 48 8b 48 40 48 8b 78 28 e8 67 29 05 00 41 89 c4 e9 e5 fd ff ff e8 4a 14 40 ff 90 <0f> 0b e8 42 14 40 ff 48 8b 55 a8 44 89 e8 44 89 fb 44 29 f8 89 02 RSP: 0018:ffff8880462cfba0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880528b04d0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8880462cfc18 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 FS:  0000555576e563c0(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000d000 CR3: 0000000045e3e000 CR4: 0000000000750ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 ================================================================== The commit of the kernel I used is “dd5a440a31fae6e459c0d6271dddd62825505361”  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dd5a440a31fae6e459c0d6271dddd62825505361 Kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&x=7144… Complier: gcc 11.4.0 The repro is shown in annex repro.c.txt I hope it helps. Best regards Jianzhou Zhao, Xingwei Lee.

3 weeks, 4 days

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2025