[26.04_linux-nvidia-bos] CVE may/26.04 linux nvidia bos#434
Open
ltrager wants to merge 216 commits into
Open
Conversation
Ignore: yes Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…idia Ignore: yes Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit 1a32c7f noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 0d1a2de noble:linux-nvidia-6.17) [jacobmartin: dropped uses of CONFIG_PREEMPT_NONE / CONFIG_PREEMPT_VOLUNTARY, these have been disabled upstream for arm64 and amd64 arches by commit 7dadeaa ("sched: Further restrict the preemption modes") in favor of CONFIG_PREEMPT_LAZY, which is default in the parent kernel.] Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
Add support for exposing rprovides data for standalone modules too. Switch to exposing provides as a shared debian/substvar file and use that in the templates. Ignore: yes Signed-off-by: Brad Figg <bfigg@nvidia.com> Signed-off-by: Ian May <ian.may@canonical.com> (cherry picked from commit afacdda noble:linux-nvidia/main-next) Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit 52ba185) (cherry picked from commit 52ba185 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 8f0710a noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
This reverts commit 7a51fff. This stale debian/dkms-versions scripting is still used for derivatives of linux without a linux-main-modules package to parse the main package's dkms-versions file for out-of-tree module builds. Ignore: yes Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
When nvidia-fs-dkms is available as a dkms package, we want to default to using the signed modules if possible. Adding a version number for the nvidia-fs modules package enables the inbox modules to be selected over an equivalent dkms version. Ignore: yes Signed-off-by: Ian May <ian.may@canonical.com> (cherry picked from commit 607379d noble:linux-nvidia/main-next) Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit f6927df) (cherry picked from commit f6927df noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 750ba56 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…nvidia kernels BugLink: https://bugs.launchpad.net/bugs/2060327 Signed-off-by: Brad Figg <bfigg@nvidia.com> Acked-by: Brad Figg <bfigg@nvidia.com> Signed-off-by: Ian May <ian.may@canonical.com> [jacobmartin: Add note to changed configs] Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit 9b2615a noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit e3b5061 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…ations BugLink: https://bugs.launchpad.net/bugs/2060327 Signed-off-by: Brad Figg <bfigg@nvidia.com> Acked-by: Brad Figg <bfigg@nvidia.com> Signed-off-by: Ian May <ian.may@canonical.com> [jacobmartin: Add annotations note for changed configs] Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit 3d31ea0 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 6de4075 noble:linux-nvidia-6.17) [jacobmartin: set new CoreSight configs: - CONFIG_CORESIGHT_TNOC=m - CONFIG_CORESIGHT_CTCU=m] Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
Ignore: yes Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit 448ddcb) (cherry picked from commit 448ddcb noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit b4e9b91 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2061930 BugLink: https://bugs.launchpad.net/bugs/2067106 There are systems in production that don't have firmware that supports coresight_etm4x. Instead of removing completely, blacklist coresight_etm4x so systems with the correct firmware can use the module. Signed-off-by: Ian May <ian.may@canonical.com> Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Brad Figg <bfigg@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (backported from commit 217d1ae noble:linux-nvidia-6.14) [maskedarray: adjusted context] Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 3f7d900 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2067111 Nvidia provide a way to flash the UEFI via capsule loader in arm64. CAPSULE_LOADER is also built-in in L4T kernel so for the easy use, need to make CAPSULE_LOADER as built-in in arm64. Nvidia-BugLink: https://nvbugspro.nvidia.com/bug/4601764 Signed-off-by: Brad Figg <bfigg@nvidia.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> (cherry picked from commit efbc80a noble:linux-nvidia-6.11) Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit 58d6077) (cherry picked from commit 58d6077 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 812ae1e noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2095028 This is used for GPU memory mapping. The solution is a WAR while waiting for the upstream solution that would use dmabuf to map the entire range in a single sequence. Related topics: https://lore.kernel.org/kvm/20240624065552.1572580-1-vivek.kasireddy@intel.com/ https://lore.kernel.org/kvm/cover.1719909395.git.leon@kernel.org/ Signed-off-by: Ankit Agrawal <ankita@nvidia.com> (cherry picked from commit d3d7b64f1a3274e5df04dee1a8062f54a3fa1116 nvidia/kstable/dev/nic/iommufd_vsmmu-12122024) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Brad Figg <bfigg@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 15e066a noble:linux-nvidia-6.11) Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit 8fcaed8 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit ef306c8 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…ualization BugLink: https://bugs.launchpad.net/bugs/2095028 This adds the following config options to annotations: CONFIG_ARM_SMMU_V3_IOMMUFD=y CONFIG_IOMMUFD_DRIVER_CORE=y CONFIG_IOMMUFD_VFIO_CONTAINER=y CONFIG_NVGRACE_GPU_VFIO_PCI=m CONFIG_VFIO_CONTAINER=n CONFIG_VFIO_IOMMU_TYPE1=- For CMA size requirements, the 64K kernel configuration needs 640MB in the worst-case scenario, while the 4K kernel configuration requires 40MB. Due to the current CMA alignment requirement of 512MB on 64k kernel and 128MB on 4k kernel, use each as default For 64k kernel, CONFIG_CMA_SIZE_MBYTES=1024 For 4k kernel, CONFIG_CMA_SIZE_MBYTES=128 These config options has been defined in debian.master CONFIG_IOMMUFD=m CONFIG_IOMMU_IOPF=y Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Kai-Heng Feng <kaihengf@nvidia.com> Acked-by: Koba Ko <kobak@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (backported from commit 35a55f3 24.04_linux-nvidia-adv-6.8-next) Signed-off-by: Koba Ko <kobak@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Brad Figg <bfigg@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> (backported from commit 1314cf0 noble:linux-nvidia-6.11) Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit d09b7e2 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (backported from commit 3660ee5 noble:linux-nvidia-6.17) [mochs: Removed CONFIG_TEGRA241_CMDQV=n; we want it =y from debian.master] Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2096888 Add ACPI support to 8250_mtk driver. This makes it possible to use UART on ARM-based desktops with EDK2 UEFI firmware. Acked-by: Brad Figg <bfigg@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 4647186 noble:linux-nvidia-6.11) Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit d73760e noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 072848c noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2096882 Acked-by: Brad Figg <bfigg@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> (backported from commit a99eb0f noble:linux-nvidia-6.11) [jacobmartin: Drop addition of 13d3:3604 already added by upstream commit f9685f3 ("Bluetooth: btusb: Add MediaTek MT7925-B22M support ID 0x13d3:0x3604"). Drop driver_info flag "BTUSB_VALID_LE_STATES" as it was inverted by upstream commit 0fec656 ("Bluetooth: btusb: Invert LE State flag to set invalid rather then valid")] Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (backported from commit a1d77cd noble:linux-nvidia-6.14) [maskedarray: adjusted context] Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit f79eaa9 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…eam low power BugLink: https://bugs.launchpad.net/bugs/2107509 Add a quirk to avoid U1 and U2 low power state operations during bulk stream transfers. Change-Id: Iaff484625eca6708713d0c2acaeddfc1103ac7d2 Signed-off-by: Us Chien <us.chien@mediatek.com> Signed-off-by: Yenchia Chen <yenchia.chen@mediatek.com> Signed-off-by: Terje Bergstrom <tbergstrom@nvidia.com> Acked-by: Brad Figg <bfigg@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 07399e8 noble:linux-nvidia-6.11) Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (backported from commit e521e80) [maskedarray: changed the XHCI_NVIDIA_MT8901_HOST quirk bit value to 51] Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 08ca4af noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2109730 Realtek R8127 driver can be downloaded from https://www.realtek.com/Download/List?cate_id=584 Where it is maintained as out of tree module. This patch adds the extracted content of r8127-11.014.00.tar.bz2 in the folder drivers/net/ethernet/realtek/r8127. 4bd62fc87de32760fb1f3b9cd3ec14e933035623 r8127-11.014.00.tar.bz2 All the clean-up, makefile and Kconfig related changes will be done in the subsequent commits. The source code contains a GPL2 compatible license. All the license information and Realtek copyright notice will be maintained in each file and newly added files. Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Ian May <ianm@nvidia.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Signed-off-by: Ian May <ianm@nvidia.com> (cherry picked from commit 7faf7ac noble:linux-nvidia-6.11) Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit e45f1b7 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 24068b2 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2109730 These files are not needed to build r8127 as part of kernel source code build, so removed these non required files. Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Ian May <ianm@nvidia.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Signed-off-by: Ian May <ianm@nvidia.com> (cherry picked from commit 063d338 noble:linux-nvidia-6.11) Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit 712fc60 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit ee5f3b0 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2109730 This commit moved all files from src folder to parent folder itself. Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Ian May <ianm@nvidia.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Signed-off-by: Ian May <ianm@nvidia.com> (cherry picked from commit a5fe39b noble:linux-nvidia-6.11) Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit 1802cd3 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit f83397f noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2109730 In the original code, r8127 driver was build as out of tree module. This commit adds Kconfig and updates Makefile for building it with kernel build. r8127 driver internally uses different config flags and these are set through EXTRA_CFLAGS. These config flags are now set in the Makefile with ccflags-y. All the flags, that were getting enabled by default in the original code, have been enabled in ccflags-y. This commit is not enabling any extra flags. Some of the files compilation are dependent upon a particular flag. Now, only default flags are set, so these files will become unused, This commit has removed these files. Signed-off-by: Terje Bergstrom <tbergstrom@nvidia.com> Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Ian May <ianm@nvidia.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Signed-off-by: Ian May <ianm@nvidia.com> (backported from commit 04ea6d0 noble:linux-nvidia-6.11) [jacobmartin: adjust context around RTASE definitions introduced in K6.14] Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit 6217fea noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit d423ea7 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…127 module BugLink: https://bugs.launchpad.net/bugs/2109730 Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Matt Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Ian May <ianm@nvidia.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Signed-off-by: Ian May <ianm@nvidia.com> (cherry picked from commit 59db394 noble:linux-nvidia-6.11) Signed-off-by: Jacob Martin <jacob.martin@canonical.com> (cherry picked from commit aaa5490) (cherry picked from commit aaa5490 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 1edd05e noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2111511 - crb_acpi_add() checks for start method - If start method is ACPI_TPM2_CRB_WITH_ARM_FFA, then it invokes tpm_crb_ffa_init(). - The tpm_crb_ffa_init() uses IS_REACHABLE() #if IS_REACHABLE(CONFIG_TCG_ARM_CRB_FFA) int tpm_crb_ffa_init(void); #else static inline int tpm_crb_ffa_init(void) { return 0; } #endif So, either tpm_crb (configured with CONFIG_TCG_CRB) should be module or we need to make tpm_crb_ffa (CONFIG_TCG_ARM_CRB_FFA) built-in. - CONFIG_TCG_CRB is selected by other configs so making it module won't be feasible. We can enable CONFIG_TCG_ARM_CRB_FFA to make tpm_crb_ffa built-in. - This also requires to select CONFIG_ARM_FFA_TRANSPORT=y Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Acked-by: Noah Wager <noah.wager@canonical.com> Signed-off-by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 60809f8) (cherry picked from commit 60809f8 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit b054f0b noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2114230 The FFH (Functional Fixed Hardware) operation region is maintained by ARM in https://developer.arm.com/documentation/den0048/latest/ OperationRegion (RegionName, RegionSpace, Offset, Length) For ARM FFH, Offset is used to identify the functionality offered by this FFH address space. It must be set to one of the following values: - 0x0 to indicate usage of 32-bit calling convention - 0x1 to indicate usage of 64-bit calling convention. - All other values are reserved. For GB10 and other similar SOC’s, to communicate with embedded controller, a new specification is being defined. It is currently in draft stage and maintained in https://github.com/OpenDevicePartnership/documentation/blob/main/bookshelf/Shelf%204%20Specifications/EC%20Interface/src/README.md https://github.com/OpenDevicePartnership/documentation/blob/main/bookshelf/Shelf%204%20Specifications/EC%20Interface/src/secure-ec-services-overview.md Offset 4 section: https://github.com/OpenDevicePartnership/documentation/blob/main/bookshelf/Shelf%204%20Specifications/EC%20Interface/src/secure-ec-services-overview.md#operation-region-definition This specification internally uses offset 0x4 which is not defined in published ARM specification. So, when ACPI request comes with offset 0x4, then it will fail due to missing support. This commit adds support for custom offset handler. A new EC interface driver will be added in subsequent patches which will registers it callback function. When FFH operation region will be executed with offsets other than 0x0 and 0x1, then it will be forwarded to custom handler. Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 89b7d03 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit df76ec3 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2114230 Please refer https://github.com/OpenDevicePartnership/documentation/blob/main/bookshelf/Shelf%204%20Specifications/EC%20Interface/src/secure-ec-services-overview.md for details regarding FFA device details for secure EC services communication. The HID 'MSFT000C' is reserved for FFA devices. This HID is documented in https://github.com/OpenDevicePartnership/documentation/blob/main/bookshelf/Shelf%204%20Specifications/EC%20Interface/src/secure-ec-services-overview.md#hid-definition This commit adds a platform driver which binds with FFA device. In its probe routine, it executes the AVAL method to check if FFA can be used for secure EC services communication. Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 555e41e noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit bdd6ed0 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2114230 Please refer https://github.com/OpenDevicePartnership/documentation/blob/main/bookshelf/Shelf%204%20Specifications/EC%20Interface/src/secure-ec-services-overview.md for details regarding FFA device details for secure EC services communication. Each secure EC service is identified by separate UUID. When generic FFA module loads (ffa_module), then it gets the list of partitions. Each EC service is a FFA partition and ffa_module creates a device for each partition. These devices will be added in arm_ffa bus type. The device will be named as arm-ffa-<number>. For binding with these devices, a driver needs to be registered in arm_ffa bus type. This driver uses structure ‘struct ffa_driver’ where it uses UUID as ID table. The binding of the driver to device happens on basis of UUID. The secure EC services FFA driver is dependent upon main FFA device to be created (which uses ACPI ID MSFT000C), so ffa_driver_register()/ffa_driver_unregister() is invoked from nvidia_ffa_probe()/nvidia_ffa_remove(). Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 9613a5c noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 5ede0e8 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2114230 Please refer https://github.com/OpenDevicePartnership/documentation/blob/main/bookshelf/Shelf%204%20Specifications/EC%20Interface/src/secure-ec-services-overview.md for details regarding FFA device details for secure EC services communication. When ACPI interpreter runs code with FFH operation region offset 4, then this data is meant for EC secure services. The FFH buffer has data in FFA_REQ_PACKET format. In this packet, it has UUID for EC service and then the service specific raw data. This commit adds a custom FFH offset handler. When request comes with custom offset then it will be handled by nvdia FFA EC driver. Inside the custom ffh callback, it extracts the UUID and gets the ffa_device for it. Then it fills raw data in ffa_send_direct_data2 and invoke sync_send_receive2() routine for that ffa_device. Once it gets the response back, then it fill data in FFA_RESP_PACKET format and ACPI interpreter passes that data to upper layer. NOTE: In the above document, the FFA_REQ_PACKET and FFA_RESP_PACKET uses different format. But in latest firmware code, the ACPI implementation is done using same format for both request and response (follows the FFA_REQ_PACKET format). The status bit will be updated in the response (0 for success and 1 for failure). This mixed endian is documented in https://cdrdv2-public.intel.com/772722/asl-tutorial-v20190625.pdf In addition to Concatenate, there are several useful macros that generate buffers from strings. For example, the ToUUID macro takes a string of the form aabbccdd-eeff-gghh-iijj-kkllmmnnoopp where aa through pp represent one byte values encoded with hexadecimal characters. This string gets converted to a 16-byte buffer that looks like the following: Buffer() { dd, cc, bb, aa, ff, ee, hh, gg, ii, jj, kk, ll, mm, nn, oo, pp } This mixture of little endian and big-endian encoding UUID is called a mixed-endian format. The use of strings and the ToUUID macro is a convenient way to avoid having to manually encode the mixed-endian format. There are many other macros that provide similar conveniences, such as EISAID. In kernel, it is represented with guid_t. Inside nvidia_ffh_handler(), we need to covert buffer of 16 bytes from FFA UUID to AML UUID format. nvidia_get_uuid_from_aml_buf() converts the AML UUID buffer into FFA UUID format. Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 40ca7bc noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 613505b noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2114230 - During boot time, ACPI probe happens first. It calls _STA method for each added device. - Inside _STA method for device managed by EC, it uses FFH offset 4. - The request will fail since there is no custom handler registered for offset 0x4 and device will be disabled. - If rescan happens on acpi bus, then device _STA method will be called again. This commit adds support to get acpi id from UUID and invokes acpi_bus_scan(). NOTE: nvidia_get_acpi_id_from_uuid() returns ACPI ID only for few services. We don't have a corresponding driver available for all the services in the current code. For few services only, its node uses generic ACPI ID and has driver available. For rest of the service, the driver is not yet available, or the published spec is not updated with full ACPI sample code. Once we have driver available for that, then we can add those ACPI IDs in this list. Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 971a25e noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit e4ec414 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2114230 The commit 897e9e6 ("firmware: arm_ffa: Initial support for scheduler receiver interrupt") adds support for SGI interrupts in the FFA driver. However, the validation for SGIs in the GICv3 is too strict, causing the driver probe to fail. This patch relaxes the SGI validation check, allowing callers to use SGIs if the requested SGI number is greater than or equal to MAX_IPI, which fixes the TFA driver probe failure. This issue is observed on NVIDIA server platform with FFA-v1.1. PTP clock support registered EDAC MC: Ver: 3.0.0 ARM FF-A: Driver version 1.1 ARM FF-A: Firmware version 1.1 found GICv3: [Firmware Bug]: Illegal GSI8 translation request ARM FF-A: Failed to create IRQ mapping! ARM FF-A: Notification setup failed -61, not enabled ARM FF-A: Failed to register driver sched callback -95 scmi_core: SCMI protocol bus registered This patch was sent in arm mailing list for upstream but it got rejected. https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240813033925.925947-1-sdonthineni@nvidia.com/ The proper fix requires some kind of mechanism by which a SGI can be requested by module but that needs discussion with arm and it will take time. This patch will break only if MAX_IPI value gets changed. This patch adds a BUILD_BUG_ON() to catch that situation. Once proper solution is concluded then this patch will be reverted. Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (backported from commit fd136cf) [maskedarray: removed enum ipi_msg_type definition as it appears in upstream commit "irqchip/gic-v5: Add GICv5 LPI/IPI support"] Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit df84d5d noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2114230 Please refer https://github.com/OpenDevicePartnership/documentation/blob/main/bookshelf/Shelf%204%20Specifications/EC%20Interface/src/secure-ec-services-overview.md for details regarding FFA device details for secure EC services communication. 1. We need to get virtual IDs which a EC service supports. In the FFA node, the _DSD object contains this information. If we look the sample from above document, Name(_DSD, Package() { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), //Device Prop UUID Package() { Package(2) { "arm-arml0002-ffa-ntf-bind", Package() { 1, // Revision 2, // Count of following packages Package () { ToUUID("330c1273-fde5-4757-9819-5b6539037502"), // Service1 UUID Package () { 0x01, //Cookie1 (UINT32) 0x07, //Cookie2 } }, Package () { ToUUID("b510b3a3-59f6-4054-ba7a-ff2eb1eac765"), // Service2 UUID Package () { 0x01, //Cookie1 0x03, //Cookie2 } } } } } }) // _DSD() Then it uses a nexted package structure. nvidia_ffa_fill_notification_map() added in this commit parses the _DSD object and fill the notification id map for that service. 2. Once the virtual ID is get then it needs to map to physical ID by invoking function 1 in the notify service. 3. The UUID for notification service is B510B3A3-59F6-4054-BA7A-FF2EB1EAC765. An FFA device will be created for this notification service by ffa_module. This notify service needs to be probed first. To make that happen, a separate ffa_driver instance is created and it is getting registered first. 4. We can do 1:1 mapping between virtual ID and hardware ID. 5. We need to invoke notify_request() with hardware notification ID. It registers callback function for notification. 6. Once notification comes then we need to evaluate _DSM method with virtual ID (which will be mapped same as hardware ID). 7. The function 2 in the notify service should destroy the mapping. But it is nither implemented in the firmware not its documentation is available. A TODO comment is added in nvidia_ffa_notification_destroy(). Also, if we unload and reload the modules, the existing mapping still exists. In nvidia_ffa_notification_setup(), ignore the error for this case. When firmware is updated, then the error will be returned. 8. The notification service FFA device is needed by each EC secure services FFA device to get virtual notification list. Now following device dependency chain is created. FFA device <- notification service FFA device <- EC secure services FFA device To satisfy this, call driver registration in its dependent driver probe routine. Similarly, do the driver registration in its dependent driver removed routine. Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 1287a1d noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 605dde1 noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…river BugLink: https://bugs.launchpad.net/bugs/2114230 The NVIDIA FFA and EC secure services driver enables the communication with EC (Embedded Controller). Make this driver built-in to enable EC communication at early boot. Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 9ea0251) (cherry picked from commit 9ea0251 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit 31b28ea noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…pinctrl driver BugLink: https://bugs.launchpad.net/bugs/2117784 Kernel GPIO subsystem mapping hardware pin number to a different range of gpio number. Add gpio-range structure to hold the mapped gpio range in pinctrl driver. That enables the kernel to search a range of mapped gpio range against a pinctrl device. Signed-off-by: Jonas Chen <yung-chi.chen@mediatek.com> Signed-off-by: Yenchia Chen <yenchia.chen@mediatek.com> Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Acked-by: nvmochs Acked-by: Noah Wager <noah.wager@canonical.com> Acked-by: Jacob Martin <jacob.martin@canonical.com> Signed-off--by: Brad Figg <bfigg@nvidia.com> (cherry picked from commit 1049985 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com> (cherry picked from commit c113e8d noble:linux-nvidia-6.17) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
Contributor
PR Validation ReportPatchscan ✅ No Missing FixesAll cherry-picked commits checked — no missing upstream fixes found. PR Lint ❌ Errors foundDetailsChecking 6 commits...
Cherry-pick digest:
┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐
│ Local │ Referenced upstream / Patch subject │ Patch-ID │ Subject │ SoB chain │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ b40e5fb9a812 │ [SAUCE] ptrace: slightly saner 'get_dumpable()' logic │ N/A │ N/A │ torvalds, gregkh, ltrager │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 908e2c557b1f │ [SAUCE] rxrpc: also unshare data/response packets when paged fra │ N/A │ N/A │ imv4bel, torvalds, gregkh │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 08097a3eee9d │ 24481a7f5733 rxrpc: Fix conn-level packet handling to unshare RE │ match │ match │ preserved + ltrager added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 20595b2621f8 │ 55b2984c96c3 rxrpc: Fix rxrpc_input_call_event() to only unshare │ match │ match │ preserved + ltrager added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 24aa14fe8343 │ 1f2740150f90 rxrpc: Fix potential UAF after skb_unshare() failur │ match │ match │ preserved + ltrager added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 5e00e0991915 │ [SAUCE] xfrm: esp: avoid in-place decrypt on shared skb frags │ N/A │ N/A │ h3xrabbi, klassert, gregk │
└──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘
Lint results:
E: b40e5fb9a812 ("ptrace: slightly saner 'get_dumpable()' logic"): not SAUCE/UBUNTU/Revert but has no upstream reference trailer (cherry picked from commit ... or backported from ...)
E: 908e2c557b1f ("rxrpc: Also unshare DATA/RESPONSE packets when pag"): not SAUCE/UBUNTU/Revert but has no upstream reference trailer (cherry picked from commit ... or backported from ...)
E: 5e00e0991915 ("xfrm: esp: avoid in-place decrypt on shared skb fr"): not SAUCE/UBUNTU/Revert but has no upstream reference trailer (cherry picked from commit ... or backported from ...)
|
ltrager
changed the title
Collaborator
@nirmoy I think some of these encountered "errors" because the SHAs were from stable as opposed to Linus' repo. Any thoughts on how we can improve this? If we add a trailing repo/branch after the SHA in the pick tag will the scanner recognize that? |
Collaborator
Author
|
I used stable since upstream handles any merge conflicts allowing us to have clean cherry picks. I can use Linus's tree if that is what is expected. One thought, can the scanner add a second git remote containing the stable tree? That would allow it to verify the SHAs in the repo without much extra work. |
Collaborator
@nvmochs oh, that's new. The current scanner won't parse a repo/branch suffix. Can we add Update: The commit is there in linux repo with different hash. I think I can add a search by subject if hash find fails. for a2e4efa |
Collaborator
Picking from linux-stable is fine, but for any patches that are not picked from upstream, please add an identifier after the SHA on the pick line. For the ones in this PR that were picked from -stable, I recommend using "linux-stable". e.g. |
Collaborator
Search by subject sounds like a good backup plan. |
ltrager
force-pushed
the
cve-may/26.04_linux-nvidia-bos
branch
from
b922b55 to
a744893
Compare
Collaborator
Let me think about it on how to do that" that means we need the linux-stable branch. |
Collaborator
Author
|
All commits are now tagged with |
Collaborator
|
all six PR commits match the diff of their referenced cherry-picked commits:
|
Collaborator
But not all of these were picked from linux-stable. It looks like these three were picked from upstream, so they do not require an identifier after the SHA (or if you prefer to include an identifier, it should be linux). |
nirmoy
added
help wanted
Collaborator
|
Agree with Matt some are upstreams. |
Collaborator
@ltrager ^^ (not sure if you saw this comment earlier since I forgot to tag you) |
ltrager
force-pushed
the
cve-may/26.04_linux-nvidia-bos
branch
from
a744893 to
39cc81e
Compare
commit f4c50a4 upstream. MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data(). Fixes: cac2661 ("esp4: Avoid skb_cow_data whenever possible") Fixes: 03e2a30 ("esp6: Avoid skb_cow_data whenever possible") Fixes: 7da0dde ("ip, udp: Support MSG_SPLICE_PAGES") Fixes: 6d8192b ("ip6, udp6: Support MSG_SPLICE_PAGES") Reported-by: Hyunwoo Kim <imv4bel@gmail.com> Reported-by: Kuan-Ting Chen <h3xrabbit@gmail.com> Tested-by: Hyunwoo Kim <imv4bel@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Kuan-Ting Chen <h3xrabbit@gmail.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 52646cbd00e765a6db9c3afe9535f26218276034 linux-stable) Signed-off-by: Lee Trager <ltrager@nvidia.com>
If skb_unshare() fails to unshare a packet due to allocation failure in rxrpc_input_packet(), the skb pointer in the parent (rxrpc_io_thread()) will be NULL'd out. This will likely cause the call to trace_rxrpc_rx_done() to oops. Fix this by moving the unsharing down to where rxrpc_input_call_event() calls rxrpc_input_call_packet(). There are a number of places prior to that where we ignore DATA packets for a variety of reasons (such as the call already being complete) for which an unshare is then avoided. And with that, rxrpc_input_packet() doesn't need to take a pointer to the pointer to the packet, so change that to just a pointer. Fixes: 2d1faf7 ("rxrpc: Simplify skbuff accounting in receive path") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260422161438.2593376-4-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 1f27401) Signed-off-by: Lee Trager <ltrager@nvidia.com>
Fix rxrpc_input_call_event() to only unshare DATA packets and not ACK, ABORT, etc.. And with that, rxrpc_input_packet() doesn't need to take a pointer to the pointer to the packet, so change that to just a pointer. Fixes: 1f27401 ("rxrpc: Fix potential UAF after skb_unshare() failure") Closes: https://sashiko.dev/#/patchset/20260422161438.2593376-4-dhowells@redhat.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260423200909.3049438-2-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 55b2984) Signed-off-by: Lee Trager <ltrager@nvidia.com>
The security operations that verify the RESPONSE packets decrypt bits of it in place - however, the sk_buff may be shared with a packet sniffer, which would lead to the sniffer seeing an apparently corrupt packet (actually decrypted). Fix this by handing a copy of the packet off to the specific security handler if the packet was cloned. Fixes: 17926a7 ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260422161438.2593376-5-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 24481a7) Signed-off-by: Lee Trager <ltrager@nvidia.com>
commit aa54b1d upstream. The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused. Fixes: d0d5c0c ("rxrpc: Use skb_unshare() rather than skb_cow_data()") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit d45179f8795222ce858770dc619abe51f9d24411 linux-stable) Signed-off-by: Lee Trager <ltrager@nvidia.com>
commit 31e62c2 upstream. The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional "drop capabilities" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached "last dumpability" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override. Reported-by: Qualys Security Advisory <qsa@qualys.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Kees Cook <kees@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 01363cb3fbd0238ffdeb09f53e9039c9edf8a730 linux-stable) Signed-off-by: Lee Trager <ltrager@nvidia.com>
ltrager
force-pushed
the
cve-may/26.04_linux-nvidia-bos
branch
from
39cc81e to
b40e5fb
Compare
Collaborator
Author
|
ah thanks for pointing that out. I pulled from stable which branches after those patches were applied. |
Collaborator
|
Thanks Lee...no further comments from me.
|
sforshee
reviewed
May 22, 2026
Collaborator
sforshee
left a comment
sforshee
left a comment
There was a problem hiding this comment.
Looks good.
Acked-by: Seth Forshee <sforshee@nvidia.com>
nvidia-bfigg
force-pushed
the
26.04_linux-nvidia-bos
branch
from
b496691 to
3ab3db0
Compare
Collaborator
|
Hey @ltrager |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the following CVE with clean cherry picks from 7.0 stable
LP: https://bugs.launchpad.net/ubuntu/+source/linux-nvidia-bos-7.0/+bug/2153504
Tested by building the nvidia-bos kernel and booting on a GH200