[24.04_linux-nvidia-6.17-next] NVIDIA: VR: SAUCE: cxl: guard unlinked endpoints#465
Draft
nirmoy wants to merge 867 commits into
Draft
Conversation
BugLink: https://bugs.launchpad.net/bugs/2143032 KASAN reports a stack-out-of-bounds access in validate_region_offset() while running the cxl-poison.sh unit test because the printk format specifier, %pr format, is not a match for the resource_size_t type of the variables. %pr expects struct resource pointers and attempts to dereference the structure fields, reading beyond the bounds of the stack variables. Since these messages emit an 'A exceeds B' type of message, keep the resource_size_t's and use the %pa specifier to be architecture safe. BUG: KASAN: stack-out-of-bounds in resource_string.isra.0+0xe9a/0x1690 [] Read of size 8 at addr ffff88800a7afb40 by task bash/1397 ... [] The buggy address belongs to stack of task bash/1397 [] and is located at offset 56 in frame: [] validate_region_offset+0x0/0x1c0 [cxl_core] Fixes: c3dd676 ("cxl/region: Add inject and clear poison by region offset") Signed-off-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 257c4b0) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 The HPA to DPA translation for poison injection assumes that the base address starts from where the CXL region begins. When the extended linear cache is active, the offset can be within the DRAM region. Adjust the offset so that it correctly reflects the offset within the CXL region. [ dj: Add fixes tag from Alison ] Fixes: c3dd676 ("cxl/region: Add inject and clear poison by region offset") Link: https://patch.msgid.link/20251031173224.3537030-5-dave.jiang@intel.com Reviewed-by: Alison Schofield <alison.schofield@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit b6cfddd) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 The node/zone quirk section of the cxl documentation is incorrect. The actual reason for fallback allocation misbehavior in the described configuration is due to a kswapd/reclaim thrashing scenario fixed by the linked patch. Remove this section. Link: https://lore.kernel.org/linux-mm/20250919162134.1098208-1-hannes@cmpxchg.org/ Signed-off-by: Gregory Price <gourry@gourry.net> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 82b5d7e) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 devm_cxl_port_enumerate_dports() is not longer used after below commit commit 4f06d81 ("cxl: Defer dport allocation for switch ports") Delete it and the relevant interface implemented in cxl_test. Signed-off-by: Li Ming <ming.li@zohomail.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 3f5b8f7) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 - Corrected spelling of "bandwdith" -> "bandwidth" - Fixed "wht" -> "with" Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 040acb4) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. system_wq should be the per-cpu workqueue, yet in this name nothing makes that clear, so replace system_wq with system_percpu_wq. The old wq (system_wq) will be kept for a few release cycles. See 128ea9f ("workqueue: Add system_percpu_wq and system_dfl_wq") for cause of changes. [ dj: Add reference to commit that initiated the change. ] Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Acked-by: Davidlohr Bueso <dave@stgolabs.net> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com>> --- Link: https://patch.msgid.link/20251030163839.307752-1-marco.crivellari@suse.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 952e905) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 In preparation for adding a test module that exercises the address translation calculations, extract the core calculations into stand- alone functions that operate on base parameters without dependencies on struct cxl_region. Perform additional parameter validation to protect against a test module sending bad parameters. Export the validation function, as well as the three core translation functions for use by test module cxl_translate only. This refactoring enables unit testing of the address translation logic with controlled inputs, while preserving identical functionality in the existing code paths. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Alison Schofield <alison.schofield@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit b78b9e7) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 In preparation for adding a test module that can exercise the address translation functions performed by the CXL Driver, refactor the XOR implementation like this: - Extract the core calculation into a standalone helper function, - Export the new function for use by test module cxl_translate only, - Enhance the parameter validation since this new function will be called from a test module with no guarantee of valid parameters, - Move the define of struct cxl_cxims_data to cxl.h so the test module can build xormaps. Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Alison Schofield <alison.schofield@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 4fe516d) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 Commit 4fe516d ("cxl/acpi: Make the XOR calculations available for testing") split xormap handling code to create a reusable helper function but inadvertently dropped the check of HBIW values before dereferencing cxlrd->platform_data. When HBIW is 1 or 3, no xormaps are needed and platform_data may be NULL, leading to a potential NULL pointer dereference. Affects platform configs using XOR Arithmetic with HBIWs of 1 or 3, when performing DPA->HPA address translation for CXL events. Those events would be any of poison ops, general media, or dram. Restore the early return check for HBIW values of 1 and 3 before dereferencing platform_data. Fixes: 4fe516d ("cxl/acpi: Make the XOR calculations available for testing") Signed-off-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260109194946.431083-1-alison.schofield@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 49d1063) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 Add a loadable test module that validates CXL address translation calculations using parameterized test vectors. The module tests both host-to-device and device-to-host address translations for Modulo and XOR interleave arithmetic. Two types of testing are provided: 1. Parameterized test vectors: Test vectors are passed as module parameters in the format: "dpa pos r_eiw r_eig hb_ways math expected_spa". Round-trip validation is performed: - Translate a DPA and position to a SPA - Verify the result matches expected SPA - Translate that SPA back to a DPA and position - Verify round-trip consistency 2. Internal validation testing: When no test vectors are provided, the module performs validation of the translation functions by checking parameter boundaries and running 10,000 iterations of randomly generated valid parameters to exercise the core calculation functions. The module uses the CXL Driver translation functions through symbols exported exclusively for cxl_translate. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Alison Schofield <alison.schofield@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 06377c5) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 The cxl_acpi module spams "Extended linear cache calculation failed" when the hmat memory target is not found for a node. This is normal when the memory target does not contain extended linear cache attributes. Adjust cxl_acpi_set_cache_size() to just return 0 if error is returned from hmat_get_extended_linear_cache_size(). That is the only error returned from hmat_get_extended_linear_cache_size() as -ENOENT. Also remove the check for -EOPNOTSUPP in cxl_setup_extended_linear_cache() since that errno is never returned by cxl_acpi_set_cache_size(). [dj: Flipped minor return logic suggested by Jonathan ] Suggested-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20251003185509.3215900-1-dave.jiang@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit f0c5d3b) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 Add a region sysfs attribute to show the size of the extended linear cache if there is any. The attribute is invisible when the cache size is 0, which indicates it does not exist. Moved the cxl_region_visible() location in order to pick up the new sysfs attribute definition. [ dj: Fixed spelling errors noted by Benjamin ] Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20251022203052.4078527-1-dave.jiang@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit d6602e2) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 Failing the first sysfs_update_group() needs to explicitly kfree the resource as it is too early for cxl_region_iomem_release() to do so. Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Gregory Price <gourry@gourry.net> Fixes: d6602e2 (cxl/region: Add support to indicate region has extended linear cache) Link: https://patch.msgid.link/20260202191330.245608-1-dave@stgolabs.net Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 77b310b) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 The size of this type is architecture specific, and the recommended way to print it portably is through the custom %pap format string. Fixes: d6602e2 ("cxl/region: Add support to indicate region has extended linear cache") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com>> --- Reviewed-by: Alison Schofield <alison.schofield@intel.com> Link: https://patch.msgid.link/20251204095237.1032528-1-arnd@kernel.org Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 88c72ba) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 When a decoder is locked, it means that its configuration cannot be changed. CXL spec r3.2 8.2.4.20.13 discusses the details regarding locked decoders. Locking happens when bit 8 of the decoder control register is set and then the decoder is committed afterwards (CXL spec r3.2 8.2.4.20.7). Given that the driver creates a virtual decoder for each CFMWS, the Fixed Device Configuration (bit 4) of the Window Restriction field is considered as locking for the virtual decoder by the driver. The current driver code disregards the locked status and a region can be destroyed regardless of the locking state. Add a region flag to indicate the region is in a locked configuration. The driver will considered a region locked if the CFMWS or any decoder is configured as locked. The consideration is all or nothing regarding the locked state. It is reasonable to determine the region "locked" status while the region is being assembled based on the decoders. Add a check in region commit_store() to intercept when a 0 is written to the commit sysfs attribute in order to prevent the destruction of a region when in locked state. This should be the only entry point from user space to destroy a region. Add a check is added to cxl_decoder_reset() to prevent resetting a locked decoder within the kernel driver. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20251105201826.2901915-1-dave.jiang@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 2230c4b) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 The CXL decoder flags are defined as bitmasks, not bit indices. Using test_bit() to check them interprets the mask value as a bit index, which is the wrong test. For CXL_DECODER_F_LOCK the test reads beyond the defined bits, causing the test to always return false and allowing resets that should have been blocked. Replace test_bit() with a bitmask check. Fixes: 2230c4b ("cxl: Add handling of locked CXL decoder") Signed-off-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Gregory Price <gourry@gourry.net> Tested-by: Gregory Price <gourry@gourry.net> Link: https://patch.msgid.link/98851c4770e4631753cf9f75b58a3a6daeca2ea2.1771873256.git.alison.schofield@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (backported from commit 0a70b7c) [jan: Resolve conflict in cxl_region_setup_flags() for handling CXL_DECODER_F_LOCK check] Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 With the current code flow, once the generic target is updated target->registered is set and the remaining code is skipped. So return immediately instead of going through the checks and then skip. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20251105235115.85062-2-dave.jiang@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 15e1426) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 The function name region_res_match_cxl_range() does not accurately convey the operation of address comparison with cache size. Rename to spa_maps_hpa() to provide a better function name. Suggested-by: Dan Williams <dan.j.williams@intel.com> Link: https://lore.kernel.org/linux-cxl/68eea19c7e67e_2f899100a8@dwillia2-mobl4.notmuch/ Reviewed-by: Jonathan Cameron <jonathan.cameron@huwei.com> Reviewed-by: Gregory Price <gourry@gourry.net> Link: https://patch.msgid.link/20251106170108.1468304-2-dave.jiang@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit c43521b) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 Update the comment in spa_maps_hpa() to clearly convey the construction of extended linear cache. Suggested-by: Dan Williams <dan.j.williams@intel.com> Link: https://lore.kernel.org/linux-cxl/68eea19c7e67e_2f899100a8@dwillia2-mobl4.notmuch/ Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gregory Price <gourry@gourry.net> Link: https://patch.msgid.link/20251106170108.1468304-3-dave.jiang@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 8d27dd0) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 A root decoder's callback handlers are collected in struct cxl_rd_ops. The structure is dynamically allocated, though it contains only a few pointers in it. This also requires to check two pointes to check for the existence of a callback. Simplify the allocation, release and handler check by embedding the ops statically in struct cxl_root_decoder. Implementation is equivalent to how struct cxl_root_ops handles the callbacks. [ dj: Fix spelling error in commit log. ] Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Robert Richter <rrichter@amd.com> Link: https://patch.msgid.link/20251114075844.1315805-2-rrichter@amd.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (backported from commit 6123133) [jan: Resolve minor conflict due to code lines shift] Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 Simplify the xor arithmetric setup code by grouping it in a single block. No need to split the block for QoS setup. It is safe to reorder the call of cxl_setup_extended_linear_cache() because there are no dependencies. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Robert Richter <rrichter@amd.com> Tested-by: Gregory Price <gourry@gourry.net> Link: https://patch.msgid.link/20251114075844.1315805-3-rrichter@amd.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit c42a4d2) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 Simplify the code by removing local variable @inc. The variable is not used elsewhere, remove it and directly increment the target number. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Robert Richter <rrichter@amd.com> Link: https://patch.msgid.link/20251114075844.1315805-4-rrichter@amd.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 7e71fa6) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 Create a global define for the size of the mock CXL auto region used in cxl_test. Remove the declared size in mock_init_hdm_decoder() function. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Tested-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Fabio M. De Francesco <fabio.m.de.francesco@linux.intel.com> Link: https://patch.msgid.link/20251117144611.903692-2-dave.jiang@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit fa59c35) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 Add a module parameter to allow activation of extended linear cache on the auto region for cxl_test. The current platform implementation for extended linear cache is 1:1 of DRAM and CXL memory. A CFMWS is created with the size of both memory together where DRAM takes the first part of the memory range and CXL covers the second part. The current CXL auto region on cxl_test consists of 2 256M devices that creates a 512M region. The new extended linear cache setup will have 512M DRAM and 512M CXL memory for a total of 1G CFMWS. The hardware decoders must have their starting offset moved to after the DRAM region to handle the CXL regions. [ dj: Fixup commenting style. (Jonathan) ] Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Tested-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Fabio M. De Francesco <fabio.m.de.francesco@linux.intel.com> Link: https://patch.msgid.link/20251117144611.903692-3-dave.jiang@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (backported from commit 4b1c046) [jan: Resolve minor conflict due to code line "base = window->base_hpa" being moved] Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 Add the mock wrappers for hmat_get_extended_linear_cache_size() in order to emulate the ACPI helper function for the regions that are mock'd by cxl_test. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Tested-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Fabio M. De Francesco <fabio.m.de.francesco@linux.intel.com> Link: https://patch.msgid.link/20251117144611.903692-4-dave.jiang@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 68f4a85) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 Since commit 733b57f ("cxl/pci: Early setup RCH dport component registers from RCRB") is not necessary under mocking tests. [ dj: Fixup commit representation flagged by checkpatch. ] [ dj: Ammend subject line to indicate which function. ] Signed-off-by: Alejandro Lucero <alucerop@amd.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com>> --- Reviewed-by: Ira Weiny <ira.weiny@intel.com> Link: https://patch.msgid.link/20251118182202.2083244-1-alejandro.lucero-palau@amd.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit 26c5b0d) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 Commit 364ee9f ("cxl/test: Enhance event testing") changed the loop iterator in mock_get_event() from a static constant, CXL_TEST_EVENT_CNT, to a dynamic global variable, ret_limit. The intent was to vary the number of events returned per call to simulate events occurring while logs are being read. However, ret_limit is modified without synchronization. When multiple threads call mock_get_event() concurrently, one thread may read ret_limit, another thread may increment it, and the first thread's loop condition and size calculation see and use the updated value. This is visible during cxl_test module load when all memdevs are initializing simultaneously, which includes getting event records. It is not tied to the cxl-events.sh unit test specifically, as that operates on a single memdev. While no actual harm results (the buffer is always large enough and the record count fields correctly reflect what was written), this is a correctness issue. The race creates an inconsistent state within mock_get_event() and adding variability based on a race appears unintended. Make ret_limit a local variable populated from an atomic counter. Each call gets a stable value that won't change during execution. That preserves the intended behavior of varying the return counts across calls while eliminating the race condition. This implementation uses "+ 1" to produce the full range of 1 to CXL_TEST_EVENT_RET_MAX (4) records. Previously only 1, 2, 3 were produced. Signed-off-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com>> --- Link: https://patch.msgid.link/20251116013819.1713780-1-alison.schofield@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit b6369da) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 mock_get_event() uses an uninitialized local variable, nr_overflow, to populate the overflow_err_count field. That results in incorrect overflow_err_count values in mocked cxl_overflow trace events, such as this case where the records are reported as 0 and should be non-zero: [] cxl_overflow: memdev=mem7 host=cxl_mem.6 serial=7: log=Failure : 0 records from 1763228189130895685 to 1763228193130896180 Fix by using log->nr_overflow and remove the unused local variable. A follow-up change was considered in cxl_mem_get_records_log() to confirm that the overflow_err_count is non-zero when the overflow flag is set [1]. Since the driver has no functional dependency on this constraint, and a device that violates this specific requirement does not cause incorrect driver behavior, no validation check is added. [1] CXL 3.2, Table 8-65 Get Event Records Output Payload Signed-off-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com>> --- Link: https://patch.msgid.link/20251116013036.1713313-1-alison.schofield@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> (cherry picked from commit f1840ef) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 Holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference after looking up the sart device. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sven Peter <sven@kernel.org> (cherry picked from commit f95f3bc) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2143032 Simplify the canvas lookup error handling by dropping the OF node reference sooner. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://patch.msgid.link/20250926142454.5929-3-johan@kernel.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> (cherry picked from commit 075daf2) Signed-off-by: Jiandi An <jan@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors. Fixes: cef401d ("net: fix possible wrong checksum generation") Fixes: f4c50a4 ("xfrm: esp: avoid in-place decrypt on shared skb frags") Signed-off-by: William Bowling <vakzz@zellic.io> Reviewed-by: Eric Dumazet <edumazet@google.com> Tested-by: Jiayuan Chen <jiayuan.chen@linux.dev> Link: https://patch.msgid.link/20260513041635.1289541-1-vakzz@zellic.io Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit f84eca5 linux-next) CVE-2026-46300 Signed-off-by: Cengiz Can <cengiz.can@canonical.com> Acked-by: Manuel Diewald <manuel.diewald@canonical.com> Acked-by: Alessio Faina <alessio.faina@canonical.com> Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com> (cherry picked from commit a4ff3d3c60e21078729b28362b123ad2348edba9 questing/linux) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail
to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when
moving frags from source to destination. __pskb_copy_fclone() defers
the rest of the shinfo metadata to skb_copy_header() after copying
frag descriptors, but that helper only carries over gso_{size,segs,
type} and never touches skb_shinfo()->flags; skb_shift() moves frag
descriptors directly and leaves flags untouched. As a result, the
destination skb keeps a reference to the same externally-owned or
page-cache-backed pages while reporting skb_has_shared_frag() as
false.
The mismatch is harmful in any in-place writer that uses
skb_has_shared_frag() to decide whether shared pages must be detoured
through skb_cow_data(). ESP input is one such writer (esp4.c,
esp6.c), and a single nft 'dup to <local>' rule -- or any other
nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d
skb in esp_input() with the marker stripped, letting an unprivileged
user write into the page cache of a root-owned read-only file via
authencesn-ESN stray writes.
Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors
were actually moved from the source. skb_copy() and skb_copy_expand()
share skb_copy_header() too but linearize all paged data into freshly
allocated head storage and emerge with nr_frags == 0, so
skb_has_shared_frag() returns false on its own; they need no change.
The same omission exists in skb_gro_receive() and skb_gro_receive_list().
The former moves the incoming skb's frag descriptors into the
accumulator's last sub-skb via two paths (a direct frag-move loop and
the head_frag + memcpy path); the latter chains the incoming skb whole
onto p's frag_list. Downstream skb_segment() reads only
skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's
shinfo as the nskb -- both p and lp must carry the marker.
The same omission also exists in tcp_clone_payload(), which builds an
MTU probe skb by moving frag descriptors from skbs on sk_write_queue
into a freshly allocated nskb. The helper falls into the same family
and warrants the same fix for consistency; no TCP TX-side in-place
writer is currently known to reach a user page through this gap, but
a future consumer depending on the marker would regress silently.
The same omission exists in skb_segment(): the per-iteration flag
merge takes only head_skb's flag, and the inner switch that rebinds
frag_skb to list_skb on head_skb-frags exhaustion does not fold the
new frag_skb's flag into nskb. Fold frag_skb's flag at both sites
so segments drawing frags from frag_list members carry the marker.
Fixes: cef401d ("net: fix possible wrong checksum generation")
Fixes: f4c50a4 ("xfrm: esp: avoid in-place decrypt on shared skb frags")
Suggested-by: Sabrina Dubroca <sd@queasysnail.net>
Suggested-by: Sultan Alsawaf <sultan@kerneltoast.com>
Suggested-by: Ben Hutchings <ben@decadent.org.uk>
Suggested-by: Lin Ma <malin89@huawei.com>
Suggested-by: Jingguo Tan <tanjingguo@huawei.com>
Suggested-by: Aaron Esau <aaron1esau@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
Tested-by: Rajat Gupta <rajat.gupta@oss.qualcomm.com>
Link: https://patch.msgid.link/ageeJfJHwgzmKXbh@v4bel
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
(cherry picked from commit 48f6a53 netdev/net)
CVE-2026-46300
Signed-off-by: Cengiz Can <cengiz.can@canonical.com>
Acked-by: Manuel Diewald <manuel.diewald@canonical.com>
Acked-by: Alessio Faina <alessio.faina@canonical.com>
Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com>
(cherry picked from commit 99dc4844b446f1d5b34888c17b75f94329cd2489 questing/linux)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2151747 The function is returning -ENOMEM and leaking the allocated buffer when allocation succeeds instead of failing. Fix it by inverting the condition. Fixes: 931a09f ("UBUNTU: SAUCE: apparmor5.0.0 [28/38]: apparmor: prompt: enable userspace upcall for mediation") CVE-2026-47326 Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com> (cherry picked from commit 479d8b1d965c3a07254774828d9fad1bbb08e58a questing/linux) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2151747 big_resp was being silently ignored, and an zero-initialized uresp would be passed on to aa_listener_unotif_response. Fix it by passing big_resp to handler when it's set. Fixes: 931a09f ("UBUNTU: SAUCE: apparmor5.0.0 [28/38]: apparmor: prompt: enable userspace upcall for mediation") Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com> (cherry picked from commit 7a54fb53ae83e2f02762b8e4f168d6a8a48ed0b2 questing/linux) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2151747 If kstrdup succeeded, the variable 'name' was being check instead of the assigned glob. Also, later if the creation of clone fails, there is a call to kfree name, which is not a variable allocated by kmalloc. The intended target of kfree would be glob. Fixes: 931a09f ("UBUNTU: SAUCE: apparmor5.0.0 [28/38]: apparmor: prompt: enable userspace upcall for mediation") CVE-2026-47327 CVE-2026-47328 Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com> (cherry picked from commit 5659f93a16d625959ba7131cd0d25887f0450f24 questing/linux) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2151747 Due to how C interprets negative values as true, the validation of response_is_valid_name could be bypassed if invalid data was passed into that function. Fixes: 931a09f ("UBUNTU: SAUCE: apparmor5.0.0 [28/38]: apparmor: prompt: enable userspace upcall for mediation") CVE-2026-47329 Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com> (cherry picked from commit 463fc7627311f8f03971391bb515ef1c161bd280 questing/linux) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…ntext BugLink: https://bugs.launchpad.net/bugs/2148809 With the current code, this variable is never used while uninitialized because uresp is never NULL, but LLVM/clang fails to build. Fixes: 931a09f ("UBUNTU: SAUCE: apparmor5.0.0 [28/38]: apparmor: prompt: enable userspace upcall for mediation") CVE-2026-47330 Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com> (cherry picked from commit a230538c8ea22115a4d642b4b2f2aa6feea00cd4 questing/linux) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2151747 By using sizeof(unotif) we are getting the size of the pointer, while the intent is be to get the size of the struct apparmor_notif_filter. Fixes: 931a09f ("UBUNTU: SAUCE: apparmor5.0.0 [28/38]: apparmor: prompt: enable userspace upcall for mediation") CVE-2026-47332 Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com> (cherry picked from commit dd80000bc0e8c6cb26bc4dfdf6a142306f80835d questing/linux) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…ilter BugLink: https://bugs.launchpad.net/bugs/2151747 The current calculation gives the size as size + filter in the end, while what was really meant was size - filter, being that filter contains the offset into the filter dfa in the notif struct. Fixes: 931a09f ("UBUNTU: SAUCE: apparmor5.0.0 [28/38]: apparmor: prompt: enable userspace upcall for mediation") CVE-2026-47333 Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com> (cherry picked from commit 11ab962d1e06ad4cc879f6e33b67d00520766b80 questing/linux) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2151747 kref_init runs twice for listener->count. This is essentially harmless since it's set to 1 both times. Fixes: 931a09f ("UBUNTU: SAUCE: apparmor5.0.0 [28/38]: apparmor: prompt: enable userspace upcall for mediation") Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com> (cherry picked from commit d4cbfeefbad93ddbc3098deac7e0c689bb58e936 questing/linux) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…in_lock BugLink: https://bugs.launchpad.net/bugs/2151747 knotif_update_from_uresp_name calls functions that allocate memory with GFP_KERNEL, but its caller is holding a spin_lock and that should not happen, so change it to GFP_ATOMIC. Fixes: 931a09f ("UBUNTU: SAUCE: apparmor5.0.0 [28/38]: apparmor: prompt: enable userspace upcall for mediation") CVE-2026-47334 Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com> (cherry picked from commit c397d0f8c1c15f19ea448c3f45082060e098aa49 questing/linux) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2151747 addr4 was used before assignment in the case where the family was AF_UNSPEC. Fixes: ace1294 ("UBUNTU: SAUCE: apparmor5.0.0 [14/38]: apparmor: net: add fine grained ipv4/ipv6 mediation") CVE-2026-47337 Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com> (cherry picked from commit b188036bef77d1314072135d4825ec563f2a7751 questing/linux) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2151747 pdb->dfa could be NULL if unpack_dfa fails, causing a NULL pointer dereference. Fixes: 2e12c5f ("apparmor: add additional flags to extended permission.") Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com> Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com> (cherry picked from commit 9bfdc10b472db15c6f4f58395a34caa369112f21 questing/linux) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2154172 skb_gro_receive() can currently copy frags between the source and GRO skb, without checking the zerocopy status, and in particular the SKBFL_MANAGED_FRAG_REFS flag. When SKBFL_MANAGED_FRAG_REFS is set, the skb doesn't hold a reference on the pages in shinfo->frags. Appending those frags to another skb's frags without fixing up the page refcount can lead to UAF. When either the last skb in the GRO chain (the one we would append frags to) or the source skb is zerocopy, don't merge the skbs. Fixes: 753f1ca ("net: introduce managed frags infrastructure") Reported-by: Huzaifa Sidhpurwala <huzaifas@redhat.com> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/c3b7f906bbfcbdfd7b4fa9d6c18a438870df85be.1779307748.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 4db79a3 netdev/net) Signed-off-by: Cengiz Can <cengiz.can@canonical.com> Acked-by: Manuel Diewald <manuel.diewald@canonical.com> Acked-by: Edoardo Canepa <edoardo.canepa@canonical.com> Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com> (cherry picked from commit efe783ecd06686e0590aec4af754ac72f04cfc05 questing/linux) Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2154045 The register-based PARTITION_INFO_GET path trusted the firmware-provided indices when copying partition descriptors into the caller buffer. Reject inconsistent counts or index progressions so the copy loop cannot write past the allocated array. Fixes: ba85c64 ("firmware: arm_ffa: Add support for FFA_PARTITION_INFO_GET_REGS") Link: https://patch.msgid.link/20260428-ffa_fixes-v2-6-8595ae450034@kernel.org (fixed cur_idx when exactly one descriptor in the first fragment) Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> (cherry picked from commit 3974ea1) Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154045 FFA_PARTITION_INFO_GET_REGS reports the size of each partition information descriptor in x2[63:48]. However, __ffa_partition_info_get_regs() walks the returned register payload with a hardcoded 24-byte stride (regs += 3), even though the size is already read into buf_sz. That works for the FF-A v1.1/v1.2 24-byte descriptor layout, where each descriptor consumes three registers. Newer FF-A revisions can extend the descriptor while keeping the existing fields at the front. For example, a 48-byte descriptor consumes six registers, so advancing by only three registers desynchronises the parser and can make it read subsequent entries from the middle of a descriptor. Use the advertised descriptor size to derive the register stride. Validate that the size is register-aligned, large enough for the fields parsed by the driver, and that the requested number of descriptors fits in the returned x3..x17 register window. The driver still copies only the fields it understands, but now skips over any trailing descriptor fields correctly. Fixes: ba85c64 ("firmware: arm_ffa: Add support for FFA_PARTITION_INFO_GET_REGS") Suggested-by: Sudeep Holla <sudeep.holla@kernel.org> Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Link: https://patch.msgid.link/20260518203116.42624-1-jamien@nvidia.com (sudeep.holla: Minor rewordng of the commit message and subject) Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> (backported from commit 01b9cae linux-next) Signed-off-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154302 Per CXL r3.1, sec 8.1.5.2, the Secondary Bus Reset (SBR) bit in the Bridge Control register of a CXL port has no effect unless the "Unmask SBR" bit in the Port Control Extensions Register is set. After b1956e2 ("PCI/CXL: Fail bus reset if upstream CXL Port has SBR masked"), Linux checks the "Unmask SBR" bit in pci_reset_bus_function(). But when probe==true, it previously returned 0, incorrectly indicating that SBR is a viable reset method for the device. As a result, "bus" is listed in the device's "reset_method" attribute even though the hardware is incapable of performing it. If a user writes "bus" to "reset_method" or triggers a reset that falls back to SBR, the operation fails with "write error: Inappropriate ioctl for device". If the link is operating in CXL mode (pcie_is_cxl()), return -ENOTTY immediately unless "Unmask SBR" is set, regardless of the probe argument. This ensures that "bus" is not advertised in "reset_methods" when the hardware prevents it, improving clarity for users and aligning the sysfs capability report with actual hardware behavior. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> [bhelgaas: commit log, use pcie_is_cxl()] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260225133801.30231-1-vidyas@nvidia.com (cherry picked from commit 702c1d5) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Lee Trager <ltrager@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2154457 Some Pericom/Diodes PI7C9X3G606GPC switches require downstream Port 4 BAR0 to mirror BAR0 of the immediate upstream port. Firmware may apply this during boot, but Linux PCI resource assignment can move the upstream BAR0 and leave Port 4 without the required mirror. Diodes confirmed that Tile0/P4 is OS-visible as device 04, function 0 on the bus below the upstream port. Add a final and early resume quirk for that downstream function. The quirk verifies that the immediate upstream bridge is the same switch, then writes Port 4 BAR0 from the upstream BAR0 after resource assignment and during early resume. If BAR0 is configured as a 64-bit memory BAR, mirror BAR1 as the upper dword as well. Port 4 BAR0 may read back as zero even after a successful write, so the write must be validated by platform-specific means. Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvivida.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2156557 Add cputype definitions for C1-Ultra. These will be used for errata detection in subsequent patches. These values can be found in the C1-Ultra TRM: https://developer.arm.com/documentation/108014/0100/ ... in section A.5.1 ("MIDR_EL1, Main ID Register"). Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org> (backported from commit 60349e6 linux-next) [mochs: Minor context adjustment due to absent definitions] Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2156557 Add cputype definitions for C1-Premium. These will be used for errata detection in subsequent patches. These values can be found in the C1-Premium TRM: https://developer.arm.com/documentation/109416/0100/ ... in section A.5.1 ("MIDR_EL1, Main ID Register"). Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org> (backported from commit d28413b linux-next) [mochs: Minor context adjustment due to absent definitions] Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2156557 A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org> (backported from commit cfd391e linux-next) [mochs: Minor context adjustment due to absent definitions] Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2156557 NVIDIA Olympus cores are affected by the TLBI completion issue tracked as CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses ARM64_WORKAROUND_REPEAT_TLBI to issue an additional broadcast TLBI;DSB sequence and ensure affected memory write effects are globally observed. Add MIDR_NVIDIA_OLYMPUS to the repeat-TLBI match list so the same mitigation is enabled on affected Olympus systems. Also document the NVIDIA Olympus erratum in the arm64 silicon errata table and list it in the Kconfig help text. Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org> (cherry picked from commit ec7216f linux-next) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
CVE-Enable ARM64_ERRATUM_4118414 to mitigate 2025-10263 on NVIDIA platforms. BugLink: https://bugs.launchpad.net/bugs/2156557 Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Signed-off-by: Brad Figg <bfigg@nvidia.com>
Collaborator
Author
BaseOS Kernel ReviewSummaryNo issues found across the reviewed commits. Findings: no problems found Latest watcher review: open review Kernel deb build: failed (failure log, build artifacts) Head: This comment is maintained by nv-pr-bot. It is updated when the GitHub watcher publishes a newer review. |
Contributor
PR Validation ReportPatchscan ✅ No Missing FixesAll cherry-picked commits checked — no missing upstream fixes found. PR Lint ❌ Errors foundDetailsChecking 1 commits... Cherry-pick digest: ┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐ │ Local │ Referenced upstream / Patch subject │ Patch-ID │ Subject │ SoB chain │ ├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤ │ a945fdb6435c │ [SAUCE] cxl: guard unlinked memdev endpoints │ N/A │ N/A │ nirmoyd │ └──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘ Lint: all checks passed. PR metadata: E: PR targets 24.04_linux-nvidia-6.17-next but body has no https://bugs.launchpad.net/... link |
cxlmd->endpoint starts as ERR_PTR(-ENXIO) until endpoint port registration links the memdev to a real cxl_port. Treat NULL and error pointers as "endpoint not linked" before dereferencing cxlmd->endpoint in CXL helper paths. Fixes: eb61834 ("cxl/mem: Introduce cxl_memdev_attach for CXL-dependent operation") Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
nirmoy
force-pushed
the
codex/nvbug6274048-cxl-endpoint-guard-6.17-next
branch
from
5dd7359 to
a945fdb
Compare
nirmoy
changed the title
nvidia-bfigg
force-pushed
the
24.04_linux-nvidia-6.17-next
branch
from
a53b6ed to
7a62271
Compare
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.
Summary
Fix NVBug 6274048 for
24.04_linux-nvidia-6.17-next.cxlmd->endpointstarts asERR_PTR(-ENXIO)until endpoint port registration completes. Guard CXL helper paths withIS_ERR_OR_NULL()before dereferencing it.BOS note
I did not find evidence that this 6.17-next boot/probe NULL dereference has reproduced on BOS. BOS CXL Type-2/reset coverage is tracked separately:
CONFIG_VFIO_CXL_CORE) and 07fa68eb25751 (vfio_cxl_reset()).PCI/CXL: Hide SBR from reset_methods if masked by CXL).Those SHAs are on
upstream/26.04_linux-nvidia-bos. If the same earlycxlmd->endpointaccess is reproduced on BOS, backport this guard there too.Testing
git diff --checkscripts/checkpatch.pl --strict --no-tree: cleanCONFIG_WERRORwas disabled for an existing unrelatedenum cxl_regloc_typewarning.