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

[PATCH v2 0/4] Rust: Fix typedefs for resource_size_t and phys_addr_t

by Alice Ryhl

This changes ResourceSize to use the resource_size_t typedef (currently ResourceSize is defined as phys_addr_t), and moves ResourceSize to kernel::io and defines PhysAddr next to it. Any usage of ResourceSize or bindings::phys_addr_t that references a physical address is updated to use the new PhysAddr typedef. I included some cc stable annotations because I think it is useful to backport this to v6.18. This is to make backporting drivers to the 6.18 LTS easier as we will not have to worry about changing imports when backporting. Signed-off-by: Alice Ryhl <aliceryhl(a)google.com> --- Changes in v2: - Fix build error in last patch. - Add cc stable. - Link to v1: https://lore.kernel.org/r/20251106-resource-phys-typedefs-v1-0-0c0edc7301ce… --- Alice Ryhl (4): rust: io: define ResourceSize as resource_size_t rust: io: move ResourceSize to top-level io module rust: scatterlist: import ResourceSize from kernel::io rust: io: add typedef for phys_addr_t rust/kernel/devres.rs | 18 +++++++++++++++--- rust/kernel/io.rs | 26 +++++++++++++++++++++++--- rust/kernel/io/resource.rs | 13 ++++++------- rust/kernel/scatterlist.rs | 2 +- 4 files changed, 45 insertions(+), 14 deletions(-) --- base-commit: 211ddde0823f1442e4ad052a2f30f050145ccada change-id: 20251106-resource-phys-typedefs-6db37927d159 Best regards, -- Alice Ryhl <aliceryhl(a)google.com>

2 weeks

3
10
0 0

[PATCH v2 1/1] Bluetooth: btqca: Add WCN6855 firmware priority selection feature

by Shuai Zhang

The prefix "wcn" corresponds to the WCN685x chip, while entries without the "wcn" prefix correspond to the QCA2066 chip. There are some feature differences between the two. However, due to historical reasons, WCN685x chip has been using firmware without the "wcn" prefix. The mapping between the chip and its corresponding firmware has now been corrected. Cc: stable(a)vger.kernel.org Fixes: 30209aeff75f ("Bluetooth: qca: Expand firmware-name to load specific rampatch") Signed-off-by: Shuai Zhang <shuai.zhang(a)oss.qualcomm.com> --- drivers/bluetooth/btqca.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c index 7c958d606..8e0004ef7 100644 --- a/drivers/bluetooth/btqca.c +++ b/drivers/bluetooth/btqca.c @@ -847,8 +847,12 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate, "qca/msbtfw%02x.mbn", rom_ver); break; case QCA_WCN6855: + /* Due to historical reasons, WCN685x chip has been using firmware + * without the "wcn" prefix. The mapping between the chip and its + * corresponding firmware has now been corrected. + */ snprintf(config.fwname, sizeof(config.fwname), - "qca/hpbtfw%02x.tlv", rom_ver); + "qca/wcnhpbtfw%02x.tlv", rom_ver); break; case QCA_WCN7850: snprintf(config.fwname, sizeof(config.fwname), @@ -861,6 +865,13 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate, } err = qca_download_firmware(hdev, &config, soc_type, rom_ver); + + if (!rampatch_name && err < 0 && soc_type == QCA_WCN6855) { + snprintf(config.fwname, sizeof(config.fwname), + "qca/hpbtfw%02x.tlv", rom_ver); + err = qca_download_firmware(hdev, &config, soc_type, rom_ver); + } + if (err < 0) { bt_dev_err(hdev, "QCA Failed to download patch (%d)", err); return err; @@ -923,7 +934,7 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate, case QCA_WCN6855: qca_read_fw_board_id(hdev, &boardid); qca_get_nvm_name_by_board(config.fwname, sizeof(config.fwname), - "hpnv", soc_type, ver, rom_ver, boardid); + "wcnhpnv", soc_type, ver, rom_ver, boardid); break; case QCA_WCN7850: qca_get_nvm_name_by_board(config.fwname, sizeof(config.fwname), @@ -936,6 +947,13 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate, } err = qca_download_firmware(hdev, &config, soc_type, rom_ver); + + if (!firmware_name && err < 0 && soc_type == QCA_WCN6855) { + qca_get_nvm_name_by_board(config.fwname, sizeof(config.fwname), + "hpnv", soc_type, ver, rom_ver, boardid); + err = qca_download_firmware(hdev, &config, soc_type, rom_ver); + } + if (err < 0) { bt_dev_err(hdev, "QCA Failed to download NVM (%d)", err); return err; -- 2.34.1

2 weeks

1
0
0 0

[PATCH v2 1/1] Bluetooth: btqca: Add WCN6855 firmware priority selection feature

by Shuai Zhang

The prefix "wcn" corresponds to the WCN685x chip, while entries without the "wcn" prefix correspond to the QCA2066 chip. There are some feature differences between the two. However, due to historical reasons, WCN685x chip has been using firmware without the "wcn" prefix. The mapping between the chip and its corresponding firmware has now been corrected. Cc: stable(a)vger.kernel.org Fixes: 30209aeff75f ("Bluetooth: qca: Expand firmware-name to load specific rampatch") Signed-off-by: Shuai Zhang <shuai.zhang(a)oss.qualcomm.com> --- drivers/bluetooth/btqca.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c index 7c958d606..8e0004ef7 100644 --- a/drivers/bluetooth/btqca.c +++ b/drivers/bluetooth/btqca.c @@ -847,8 +847,12 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate, "qca/msbtfw%02x.mbn", rom_ver); break; case QCA_WCN6855: + /* Due to historical reasons, WCN685x chip has been using firmware + * without the "wcn" prefix. The mapping between the chip and its + * corresponding firmware has now been corrected. + */ snprintf(config.fwname, sizeof(config.fwname), - "qca/hpbtfw%02x.tlv", rom_ver); + "qca/wcnhpbtfw%02x.tlv", rom_ver); break; case QCA_WCN7850: snprintf(config.fwname, sizeof(config.fwname), @@ -861,6 +865,13 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate, } err = qca_download_firmware(hdev, &config, soc_type, rom_ver); + + if (!rampatch_name && err < 0 && soc_type == QCA_WCN6855) { + snprintf(config.fwname, sizeof(config.fwname), + "qca/hpbtfw%02x.tlv", rom_ver); + err = qca_download_firmware(hdev, &config, soc_type, rom_ver); + } + if (err < 0) { bt_dev_err(hdev, "QCA Failed to download patch (%d)", err); return err; @@ -923,7 +934,7 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate, case QCA_WCN6855: qca_read_fw_board_id(hdev, &boardid); qca_get_nvm_name_by_board(config.fwname, sizeof(config.fwname), - "hpnv", soc_type, ver, rom_ver, boardid); + "wcnhpnv", soc_type, ver, rom_ver, boardid); break; case QCA_WCN7850: qca_get_nvm_name_by_board(config.fwname, sizeof(config.fwname), @@ -936,6 +947,13 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate, } err = qca_download_firmware(hdev, &config, soc_type, rom_ver); + + if (!firmware_name && err < 0 && soc_type == QCA_WCN6855) { + qca_get_nvm_name_by_board(config.fwname, sizeof(config.fwname), + "hpnv", soc_type, ver, rom_ver, boardid); + err = qca_download_firmware(hdev, &config, soc_type, rom_ver); + } + if (err < 0) { bt_dev_err(hdev, "QCA Failed to download NVM (%d)", err); return err; -- 2.34.1

2 weeks

1
0
0 0

[PATCH v2 1/1] Bluetooth: btqca: Add WCN6855 firmware priority selection feature

by Shuai Zhang

The prefix "wcn" corresponds to the WCN685x chip, while entries without the "wcn" prefix correspond to the QCA2066 chip. There are some feature differences between the two. However, due to historical reasons, WCN685x chip has been using firmware without the "wcn" prefix. The mapping between the chip and its corresponding firmware has now been corrected. Cc: stable(a)vger.kernel.org Fixes: 30209aeff75f ("Bluetooth: qca: Expand firmware-name to load specific rampatch") Signed-off-by: Shuai Zhang <shuai.zhang(a)oss.qualcomm.com> --- drivers/bluetooth/btqca.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c index 7c958d606..8e0004ef7 100644 --- a/drivers/bluetooth/btqca.c +++ b/drivers/bluetooth/btqca.c @@ -847,8 +847,12 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate, "qca/msbtfw%02x.mbn", rom_ver); break; case QCA_WCN6855: + /* Due to historical reasons, WCN685x chip has been using firmware + * without the "wcn" prefix. The mapping between the chip and its + * corresponding firmware has now been corrected. + */ snprintf(config.fwname, sizeof(config.fwname), - "qca/hpbtfw%02x.tlv", rom_ver); + "qca/wcnhpbtfw%02x.tlv", rom_ver); break; case QCA_WCN7850: snprintf(config.fwname, sizeof(config.fwname), @@ -861,6 +865,13 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate, } err = qca_download_firmware(hdev, &config, soc_type, rom_ver); + + if (!rampatch_name && err < 0 && soc_type == QCA_WCN6855) { + snprintf(config.fwname, sizeof(config.fwname), + "qca/hpbtfw%02x.tlv", rom_ver); + err = qca_download_firmware(hdev, &config, soc_type, rom_ver); + } + if (err < 0) { bt_dev_err(hdev, "QCA Failed to download patch (%d)", err); return err; @@ -923,7 +934,7 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate, case QCA_WCN6855: qca_read_fw_board_id(hdev, &boardid); qca_get_nvm_name_by_board(config.fwname, sizeof(config.fwname), - "hpnv", soc_type, ver, rom_ver, boardid); + "wcnhpnv", soc_type, ver, rom_ver, boardid); break; case QCA_WCN7850: qca_get_nvm_name_by_board(config.fwname, sizeof(config.fwname), @@ -936,6 +947,13 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate, } err = qca_download_firmware(hdev, &config, soc_type, rom_ver); + + if (!firmware_name && err < 0 && soc_type == QCA_WCN6855) { + qca_get_nvm_name_by_board(config.fwname, sizeof(config.fwname), + "hpnv", soc_type, ver, rom_ver, boardid); + err = qca_download_firmware(hdev, &config, soc_type, rom_ver); + } + if (err < 0) { bt_dev_err(hdev, "QCA Failed to download NVM (%d)", err); return err; -- 2.34.1

2 weeks

1
0
0 0

[PATCH 1/3] drm/plane: Fix create_in_format_blob() return value

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases. Cc: stable(a)vger.kernel.org Cc: Arun R Murthy <arun.r.murthy(a)intel.com> Fixes: 0d6dcd741c26 ("drm/plane: modify create_in_formats to acommodate async") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/drm_plane.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 38f82391bfda..a30493ed9715 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -210,7 +210,7 @@ static struct drm_property_blob *create_in_format_blob(struct drm_device *dev, formats_size = sizeof(__u32) * plane->format_count; if (WARN_ON(!formats_size)) { /* 0 formats are never expected */ - return 0; + return ERR_PTR(-EINVAL); } modifiers_size = @@ -226,7 +226,7 @@ static struct drm_property_blob *create_in_format_blob(struct drm_device *dev, blob = drm_property_create_blob(dev, blob_size, NULL); if (IS_ERR(blob)) - return NULL; + return blob; blob_data = blob->data; blob_data->version = FORMAT_BLOB_CURRENT; -- 2.49.1

2 weeks

2
1
0 0

[PATCH] ksmbd: vfs_cache: avoid integer overflow in inode_hash()

by Qianchang Zhao

inode_hash() currently mixes a name-derived hash with the super_block pointer using an unbounded multiplication: tmp = (hashval * (unsigned long)sb) ^ (GOLDEN_RATIO_PRIME + hashval) / L1_CACHE_BYTES; On 64-bit kernels this multiplication can overflow for many inputs. With attacker-chosen filenames (authenticated client), overflowed products collapse into a small set of buckets, saturating a few chains and degrading lookups from O(1) to O(n). This produces second-scale latency spikes and high CPU usage in ksmbd workers (algorithmic DoS). Replace the pointer*hash multiply with hash_long() over a mixed value (hashval ^ (unsigned long)sb) and keep the existing shift/mask. This removes the overflow source and improves bucket distribution under adversarial inputs without changing external behavior. This is an algorithmic-complexity issue (CWE-190/CWE-407), not a memory-safety bug. Reported-by: Qianchang Zhao <pioooooooooip(a)gmail.com> Reported-by: Zhitong Liu <liuzhitong1993(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Qianchang Zhao <pioooooooooip(a)gmail.com> --- fs/smb/server/vfs_cache.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/fs/smb/server/vfs_cache.c b/fs/smb/server/vfs_cache.c index dfed6fce8..ac18edf56 100644 --- a/fs/smb/server/vfs_cache.c +++ b/fs/smb/server/vfs_cache.c @@ -10,6 +10,7 @@ #include <linux/vmalloc.h> #include <linux/kthread.h> #include <linux/freezer.h> +#include <linux/hash.h> #include "glob.h" #include "vfs_cache.h" @@ -65,12 +66,8 @@ static void fd_limit_close(void) static unsigned long inode_hash(struct super_block *sb, unsigned long hashval) { - unsigned long tmp; - - tmp = (hashval * (unsigned long)sb) ^ (GOLDEN_RATIO_PRIME + hashval) / - L1_CACHE_BYTES; - tmp = tmp ^ ((tmp ^ GOLDEN_RATIO_PRIME) >> inode_hash_shift); - return tmp & inode_hash_mask; + return hash_long(hashval ^ (unsigned long)sb, inode_hash_shift) & + inode_hash_mask; } static struct ksmbd_inode *__ksmbd_inode_lookup(struct dentry *de) -- 2.34.1

2 weeks

1
0
0 0

[PATCH] scsi: target: tcm_loop: fix segfault in tcm_loop_tpg_address_show()

by Hamza Mahfooz

If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: <TASK> configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ... Cc: stable(a)vger.kernel.org Fixes: 2628b352c3d4 ("tcm_loop: Show address of tpg in configfs") Signed-off-by: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> --- drivers/target/loopback/tcm_loop.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/target/loopback/tcm_loop.c b/drivers/target/loopback/tcm_loop.c index c7b7da629741..01a8e349dc4d 100644 --- a/drivers/target/loopback/tcm_loop.c +++ b/drivers/target/loopback/tcm_loop.c @@ -894,6 +894,9 @@ static ssize_t tcm_loop_tpg_address_show(struct config_item *item, struct tcm_loop_tpg, tl_se_tpg); struct tcm_loop_hba *tl_hba = tl_tpg->tl_hba; + if (!tl_hba->sh) + return -ENODEV; + return snprintf(page, PAGE_SIZE, "%d:0:%d\n", tl_hba->sh->host_no, tl_tpg->tl_tpgt); } -- 2.49.0

2 weeks

4
3
0 0

, capacitación sin seguimiento no es desarrollo

by Mariann Rivas

Mejora el clima organizacional body { margin: 0; padding: 0; font-family: Arial, Helvetica, sans-serif; font-size: 14px; color: #333; background-color: #ffffff; } table { border-spacing: 0; width: 100%; max-width: 600px; margin: auto; } td { padding: 12px 20px; } a { color: #1a73e8; text-decoration: none; } .footer { font-size: 12px; color: #888888; text-align: center; } Invierte en capacitación que realmente desarrolla a tu equipo con Vorecol Learning. Hola, , Invertir en capacitación no siempre significa que tu equipo esté creciendo. Sin un buen seguimiento, los cursos pueden no tener el efecto esperado. Vorecol Learning es una plataforma que te ayuda a gestionar el aprendizaje de tu equipo de forma sencilla y efectiva. Con Vorecol Learning puedes: Capacitar a tu personal, desde uno hasta cinco mil colaboradores, con cursos hechos a la medida de las necesidades de tu empresa. Ver cómo avanza cada persona y entregar certificados al terminar los cursos, asegurando que aprendieron de verdad. Permitir que tus colaboradores estudien cuando quieran y desde cualquier dispositivo, con evaluaciones que confirman lo aprendido. Esta plataforma está diseñada para que la capacitación sea una herramienta real para el desarrollo de tu equipo, no solo una lista de tareas por cumplir. Aprovecha el Buen Fin del 1 al 22 de noviembre con hasta 15% de descuento y potencia el aprendizaje en tu empresa con Vorecol Learning. Responde a este correo o contáctame; mis datos están abajo. Saludos, -------------- Atte.: Mariann Rivas Ciudad de México: (55) 5018 0565 WhatsApp: +52 33 1607 2089 Si no deseas recibir más correos, haz clic aquí para darte de baja. Para remover su dirección de esta lista haga <a href="https://s1.arrobamail.com/unsuscribe.php?id=yiwtsrewiswqwtseup">click aquí</a>

2 weeks

1
0
0 0

[PATCH] x86/kexec: Add a sanity check on previous kernel's ima kexec buffer

by Harshit Mogalapalli

When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86. Cc: stable(a)vger.kernel.org Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec") Reported-by: Paul Webb <paul.x.webb(a)oracle.com> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> --- Have tested the kexec for x86 kernel with IMA_KEXEC enabled and the above patch works good. Paul initially reported this on 6.12 kernel but I was able to reproduce this on 6.18, so I tried replicating how this was fixed in drivers/of/kexec.c --- arch/x86/kernel/setup.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 1b2edd07a3e1..fcef197d180e 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -439,9 +439,23 @@ int __init ima_free_kexec_buffer(void) int __init ima_get_kexec_buffer(void **addr, size_t *size) { + unsigned long start_pfn, end_pfn; + if (!ima_kexec_buffer_size) return -ENOENT; + /* + * Calculate the PFNs for the buffer and ensure + * they are with in addressable memory. + */ + start_pfn = PFN_DOWN(ima_kexec_buffer_phys); + end_pfn = PFN_DOWN(ima_kexec_buffer_phys + ima_kexec_buffer_size - 1); + if (!pfn_range_is_mapped(start_pfn, end_pfn)) { + pr_warn("IMA buffer at 0x%llx, size = 0x%zx beyond memory\n", + ima_kexec_buffer_phys, ima_kexec_buffer_size); + return -EINVAL; + } + *addr = __va(ima_kexec_buffer_phys); *size = ima_kexec_buffer_size; -- 2.50.1

2 weeks

1
0
0 0

+ mm-memfd-fix-information-leak-in-hugetlb-folios.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/memfd: fix information leak in hugetlb folios has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-memfd-fix-information-leak-in-hugetlb-folios.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: Deepanshu Kartikey <kartikey406(a)gmail.com> Subject: mm/memfd: fix information leak in hugetlb folios Date: Wed, 12 Nov 2025 20:20:34 +0530 When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd. Link: https://lkml.kernel.org/r/20251112145034.2320452-1-kartikey406@gmail.com Fixes: 89c1905d9c14 ("mm/gup: introduce memfd_pin_folios() for pinning memfd folios") Signed-off-by: Deepanshu Kartikey <kartikey406(a)gmail.com> Reported-by: syzbot+f64019ba229e3a5c411b(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/all/20251112031631.2315651-1-kartikey406@gmail.com/ [v1] Closes: https://syzkaller.appspot.com/bug?extid=f64019ba229e3a5c411b Suggested-by: Oscar Salvador <osalvador(a)suse.de> Suggested-by: David Hildenbrand <david(a)redhat.com> Tested-by: syzbot+f64019ba229e3a5c411b(a)syzkaller.appspotmail.com Cc: Vivek Kasireddy <vivek.kasireddy(a)intel.com> Cc: Jason Gunthorpe <jgg(a)nvidia.com> Cc: Jason Gunthorpe <jgg(a)nvidia.com> (v2) Cc: Christoph Hellwig <hch(a)lst.de> (v6) Cc: Dave Airlie <airlied(a)redhat.com> Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memfd.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) --- a/mm/memfd.c~mm-memfd-fix-information-leak-in-hugetlb-folios +++ a/mm/memfd.c @@ -96,9 +96,36 @@ struct folio *memfd_alloc_folio(struct f NULL, gfp_mask); if (folio) { + u32 hash; + + /* + * Zero the folio to prevent information leaks to userspace. + * Use folio_zero_user() which is optimized for huge/gigantic + * pages. Pass 0 as addr_hint since this is not a faulting path + * and we don't have a user virtual address yet. + */ + folio_zero_user(folio, 0); + + /* + * Mark the folio uptodate before adding to page cache, + * as required by filemap.c and other hugetlb paths. + */ + __folio_mark_uptodate(folio); + + /* + * Serialize hugepage allocation and instantiation to prevent + * races with concurrent allocations, as required by all other + * callers of hugetlb_add_to_page_cache(). + */ + hash = hugetlb_fault_mutex_hash(memfd->f_mapping, idx); + mutex_lock(&hugetlb_fault_mutex_table[hash]); + err = hugetlb_add_to_page_cache(folio, memfd->f_mapping, idx); + + mutex_unlock(&hugetlb_fault_mutex_table[hash]); + if (err) { folio_put(folio); goto err_unresv; _ Patches currently in -mm which might be from kartikey406(a)gmail.com are mm-memfd-fix-information-leak-in-hugetlb-folios.patch ocfs2-validate-cl_bpc-in-allocator-inodes-to-prevent-divide-by-zero.patch

2 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror