summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-08-13power: supply: bq27xxx: bq27z561: fix invalid AverageEnergy addressHenrik Grimler
bq27z561 currently uses the AveragePower reg, 0x22, for reading both AveragePower and AvailableEnergy. The technical reference manual does not mention AvailableEnergy, and it does not make sense to read a cumulative, always positive, property like AvailableEnergy from a rate property like AveragePower. Set REG_AE as invalid to fix it. Fixes: 6f24ff97e323 ("power: supply: bq27xxx_battery: Add the BQ27Z561 Battery monitor") Signed-off-by: Henrik Grimler <henrik.grimler@axis.com> Link: https://patch.msgid.link/20260811-bq27z746-v1-5-3a4fa38205cc@axis.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-08-13power: supply: bq27xxx: bq28z610: fix invalid AverageEnergy addressHenrik Grimler
bq28z610 currently uses the AveragePower reg, 0x22, for reading both AveragePower and AvailableEnergy. The technical reference manual does not mention AvailableEnergy, and it does not make sense to read a cumulative, always positive, property like AvailableEnergy from a rate property like AveragePower. Set REG_AE as invalid to fix it. Fixes: 707d678a5c7c ("power: supply: bq27xxx_battery: Add the BQ28z610 Battery monitor") Signed-off-by: Henrik Grimler <henrik.grimler@axis.com> Link: https://patch.msgid.link/20260811-bq27z746-v1-4-3a4fa38205cc@axis.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-08-13power: supply: bq27xxx: bq27520g4: fix REG_TTES addressHenrik Grimler
According to the technical reference manual the StandbyTimeToEmpty (TTES) register is at 0x1a, not 0x1c. At 0x1c StateOfHealth instead resides. Fixes: 8835cae5f2ab ("power: supply: bq27xxx: adds specific support for bq27520-g4 revision.") Signed-off-by: Henrik Grimler <henrik.grimler@axis.com> Link: https://patch.msgid.link/20260811-bq27z746-v1-3-3a4fa38205cc@axis.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-08-13power: supply: max17040: synchronize work cancellation on suspendJianing Li
max17040_work() requeues itself after every poll. cancel_delayed_work() only cancels a pending instance and does not wait for a callback that is already running. If system suspend races with the polling callback, the callback can continue accessing the fuel gauge and requeue itself after the suspend callback returns. Use cancel_delayed_work_sync() to ensure polling is quiesced before suspend completes. Fixes: c6f4a42de60b ("Add MAX17040 Fuel Gauge driver") Cc: stable@vger.kernel.org Signed-off-by: Jianing Li <m13940358460@163.com> Link: https://patch.msgid.link/20260810004701.1683-1-m13940358460@163.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-08-12power: supply: lp8727: fix use-after-free in lp8727_release_irq()Fan Wu
lp8727_isr_func(), the threaded IRQ handler, is the only caller that arms pchg->work via schedule_delayed_work(). lp8727_release_irq() currently cancels the work before freeing the IRQ, so an IRQ delivered in between can re-arm the work through the threaded handler. After .remove returns the devm layer frees pchg while lp8727_delayed_func() may still run and dereference it. Free the IRQ first so the threaded handler is quiesced and can no longer queue work, then cancel the delayed work to drain the final generation. This issue was found by an in-house static analysis tool. Fixes: d71fda016102 ("lp8727_charger: Clean up the interrupt handler") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Link: https://patch.msgid.link/20260807033520.8551-1-fanwu01@zju.edu.cn Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-08-12power: supply: bq256xx: drain usb_work before freeing the chargerFan Wu
The USB-PHY notifier queues usb_work, whose handler calls power_supply_changed(bq->charger). The reset devm action only unregisters the notifier and was registered before the power supplies, so devm frees bq->charger on unwind before the action runs; a usb_work still queued can then dereference it. Register the reset action after the power supplies, so it unregisters the notifiers and drains usb_work before the supplies are released. Initialize usb_work and obtain the PHY references before registering the notifiers, so the worker cannot run before the supplies exist. Found by static analysis. Fixes: 32e4978bb920 ("power: supply: bq256xx: Introduce the BQ256XX charger driver") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Link: https://patch.msgid.link/20260804145511.103470-1-fanwu01@zju.edu.cn Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-08-12power: supply: qcom_battmgr: fix battery chemistry strncmp lengthTingguo Cheng
The battery_chemistry field is a 4-byte array without guaranteed null termination. Using BATTMGR_CHEMISTRY_LEN (4) as the strncmp length for 3-character string literals implicitly requires chemistry[3] == '\0', which may not hold. Use 3 instead to match only the significant bytes. Signed-off-by: Tingguo Cheng <tingguo.cheng@oss.qualcomm.com> Link: https://patch.msgid.link/20260812-fix-qcom-batt-chemistry-strn-v1-1-458545e02641@oss.qualcomm.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-08-12char: ipmi: use named initializers for acpi_device_idPawel Zalewski (The Capable Hub)
Use a named initializer for the acpi_device_id fields which makes the code more readable and consistent with how lists are initialized in the rest of the kernel code base. Also drop explicitly setting fields to 0 where it is redundant. While we are at it - unify the list terminator to have a single space between the brackets and no trailing comma. Signed-off-by: Pawel Zalewski (The Capable Hub) <pzalewski@thegoodpenguin.co.uk> Message-ID: <20260807-acpi-char-v1-3-742c450254dd@thegoodpenguin.co.uk> Signed-off-by: Corey Minyard <corey@minyard.net>
2026-08-12ipmi: Fix leak in __ipmi_bmc_registerMichail Tatas
In case that ida_alloc(&ipmi_bmc_ida,...) succeeds and then platform_device_register() fails, ipmi_bmc_ida is leaked. Fix by freeing the error path Signed-off-by: Michail Tatas <michail.tatas@gmail.com> Message-ID: <anUK_HOy_pCgvsBm@michalis-linux> Signed-off-by: Corey Minyard <corey@minyard.net>
2026-08-12ipmi: Remove all sysfs files on registration failureYuho Choi
ipmi_add_smi() creates the nr_users and nr_msgs files before trying to create the maintenance_mode file. If that last creation fails, the error path removes only nr_users before dropping the final reference to the interface. Remove nr_msgs as well so no sysfs attribute embedded in the freed interface remains registered. Fixes: 627118470fcc ("ipmi: Add a maintenance mode sysfs file") Cc: stable@vger.kernel.org # 6.18 Signed-off-by: Yuho Choi <dbgh9129@gmail.com> Message-ID: <20260803015550.618808-1-dbgh9129@gmail.com> Signed-off-by: Corey Minyard <corey@minyard.net>
2026-08-12Merge tag 'microchip-dt64-7.3' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into soc/dt Microchip ARM64 device tree updates for v7.3 This update includes: - the device tree nodes for the QSPI controllers on LAN9691 SoC * tag 'microchip-dt64-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux: arm64: dts: microchip: lan969x: add QSPI nodes Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-08-12power: supply: bd99954: Drop bad register fieldsMatti Vaittinen
The bd99954 driver creates regmap fields for all the registers. All the fields for VBUS_UCD_FCTRL_SET (extended command 0x33) are accidentally created for VCC_UCD_FCTRL_SET (extended command 0x2b), causing all reads/writes for the fields to access wrong register. Luckily the fields for VBUS_UCD_FCTRL_SET are unused. Taking a look at the data-sheet all the fields in the VBUS_UCD_FCTRL_SET are marked as: "In normal operation, please don’t set these registers" with not much of additional documentation. As the fields are wrong and because there seems to be no users of the fields - it is better to just drop them. This will also decrease the memory footprint. Drop incorrect VBUS_UCD_FCTRL_SET fields. Datasheet: https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/battery_management/bd99954xxx-e.pdf Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Fixes: 0902f8366491 ("power: supply: Support ROHM bd99954 charger") Tested-by: Kalle Niemi <kaleposti@gmail.com> Link: https://patch.msgid.link/758fd430d02286a6f18603a8aecfe443f5ddeb8e.1786356145.git.mazziesaccount@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-08-12power: supply: bd71828: Do not hide errorsMatti Vaittinen
The bd71828 reports success / continues operation even when some regmap operations fail. This can lead incorrect data to be reported. Return appropriate errors when operations fail. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Fixes: 5bff79dad20a ("power: supply: Add bd718(15/28/78) charger driver") Tested-by: Kalle Niemi <kaleposti@gmail.com> Link: https://patch.msgid.link/22db56cf35252d2d8f67828a0554e8daac7ae251.1786356145.git.mazziesaccount@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-08-12power: supply: bd71828: Drop duplicate power-supply propertyMatti Vaittinen
The POWER_SUPPLY_PROP_HEALTH is added into property-array twice. Drop the duplicate property. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Fixes: 5bff79dad20a ("power: supply: Add bd718(15/28/78) charger driver") Tested-by: Kalle Niemi <kaleposti@gmail.com> Link: https://patch.msgid.link/518283ec9163943fcd1b53ad61fc3025fd346d83.1786356145.git.mazziesaccount@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-08-12power: supply: bd71828: Fix current directionMatti Vaittinen
Both the current and the average current registers contain same 'direction' -bit to denote the direction of the current. The code reading these registers incorrectly caches the direction read from the first register, and uses it also for the second. Fix this by initializing the direction bit for both register reads. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Fixes: 5bff79dad20a ("power: supply: Add bd718(15/28/78) charger driver") Tested-by: Andreas Kemnade <andreas@kemnade.info> # Kobo Clara 2e rev B Tested-by: Kalle Niemi <kaleposti@gmail.com> Link: https://patch.msgid.link/22c6816204b3f2a8b50df8171e384937822d195b.1786356145.git.mazziesaccount@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-08-12power: supply: bd71815: Fix temperature readingMatti Vaittinen
The temperature read from the hardware is never returned to caller. Furthermore, the check for temperature validity is wrong. This yields garbage value to be returned to caller, and also detection of bad values read from hardware to fail. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Fixes: 5bff79dad20a ("power: supply: Add bd718(15/28/78) charger driver") Tested-by: Kalle Niemi <kaleposti@gmail.com> Link: https://patch.msgid.link/4ae3dfa7fc80372977fd29c837321f96d551bf6f.1786356145.git.mazziesaccount@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-08-12ixd: add devlink supportAmritha Nambiar
Enable initial support for the devlink interface with the ixd driver. The ixd hardware is a single function PCIe device. So, the PCIe adapter gets its own devlink instance to manage device-wide resources or configuration. $ devlink dev show pci/0000:83:00.6 $ devlink dev info pci/0000:83:00.6 pci/0000:83:00.6: driver ixd serial_number 00-a0-c9-ff-ff-23-45-67 versions: fixed: device.type MEV running: fw.mgmt.api 2.0 Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Tested-by: Bharath R <Bharath.r@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-12ixd: add the core initializationLarysa Zaremba
As the mailbox is setup, initialize the core. This makes use of the send and receive mailbox message framework for virtchnl communication between the driver and device Control Plane (CP). To start with, driver confirms the virtchnl version with the CP. Once that is done, it requests and gets the required capabilities and resources needed such as max vectors, queues, vports etc. Use a unified way of handling the virtchnl messages, where a single function handles all related memory management and the caller only provides the callbacks to fill the send buffer and to handle the response. Place generic control queue message handling separately to facilitate the addition of protocols other than virtchannel in the future. Co-developed-by: Amritha Nambiar <amritha.nambiar@intel.com> Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: Bharath R <Bharath.r@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-12ixd: add reset checks and initialize the mailboxLarysa Zaremba
At the end of the probe, trigger hard reset, initialize and schedule the after-reset task. If the reset is complete in a pre-determined time, initialize the default mailbox, through which other resources will be negotiated. Co-developed-by: Amritha Nambiar <amritha.nambiar@intel.com> Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Bharath R <Bharath.r@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-12ixd: add basic driver framework for Intel(R) Control Plane FunctionLarysa Zaremba
Add module register and probe functionality. Add the required support to register IXD PCI driver, as well as probe, remove and shutdown callbacks. Enable the PCI device and request to reserve the memory resources that will be used by the driver. Finally map the BAR0 address space. For now, use devm_kzalloc() to allocate adapter, as it requires the least amount of code. In a later commit, it will be replaced with a devlink alternative. Co-developed-by: Amritha Nambiar <amritha.nambiar@intel.com> Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: Bharath R <Bharath.r@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-12idpf: print a debug message and bail in case of non-event ctlq messageLarysa Zaremba
Unlike previous internal idpf ctlq implementation, libie_cp calls the default message handler for all received messages that do not have a matching xn transaction, not only for VIRTCHNL2_OP_EVENT. This leads to many error messages printing garbage, because the parsing expected a valid event message, but got e.g. a delayed response for a timed-out transaction. The information about timed-out transactions and otherwise unhandleable messages can still be valuable for developers, so print the information with dynamic debug and exit the function, so the following functions can parse valid events in peace. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-12idpf: make mbx_task queueing and cancelling more consistentLarysa Zaremba
One of the assumptions of libie_cp and pre-refactor idpf control queue handling is such that all Rx processing is handled by a single task, which is to be cancelled before the mailbox destruction. Aside from cancelling, it is also important to make sure that idpf_intr_rel() never reschedules it afterwards. In order to comply, in the init path, do the first queueing of mbx_task in idpf_init_dflt_mbx(), and in deinit and reset, always cancel the task in idpf_deinit_dflt_mbx(), in every single flow call idpf_mb_intr_rel_irq() beforehand. Reviewed-by: Emil Tantilov <emil.s.tantilov@intel.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-12idpf: refactor idpf to use libie control queuesPavan Kumar Linga
Support to initialize and configure controlqs, and manage their transactions was introduced in libie. As part of it, most of the existing controlq structures are renamed and modified. Use those APIs in idpf and make all the necessary changes. Previously for the send and receive virtchnl messages, there used to be a memcpy involved in controlq code to copy the buffer info passed by the send function into the controlq specific buffers. There was no restriction to use automatic memory in that case. The new implementation in libie removed copying of the send buffer info and introduced DMA mapping of the send buffer itself. To accommodate it, use dynamic memory for the larger send buffers. For smaller ones (<= 128 bytes) libie still can copy them into the pre-allocated message memory. Those changes result in a pretty big diff, but the changes are fairly trivial and localized. In case of receive, idpf receives a page pool buffer allocated by the libie and care should be taken to release it after use in the idpf. idpf_idc_rdma_vc_send_sync() no longer truncates oversized responses or zeroes *recv_len on error, but this was confirmed to have no practical impact for any existing callers. This refactoring introduces roughly additional 40KB of module storage used for systems that only run idpf, so idpf + libie_cp + libie_pci takes about 7% more storage than just idpf before refactoring. We now pre-allocate small TX buffers, so that does increase the memory usage, but reduces the need to allocate. This results in additional 256 * 128B of memory permanently used, increasing the worst-case memory usage by 32KB but our ctlq RX buffers need to be of size 4096B anyway (not changed by the patchset), so this is hardly noticeable. As for the timings, the fact that we are mostly limited by the HW response time which is far from instant, is not changed by this refactor. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Co-developed-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-12idpf: refactor idpf to use libie_pci APIsPavan Kumar Linga
Use libie_pci init and MMIO APIs where possible, struct idpf_hw cannot be deleted for now as it also houses control queues that will be refactored later. Memory regions are added and removed in layers, so e.g. mailbox and rstat are added first and not removed until teardown. libie_pci stores the regions in the order of addition, so no new locks/checks are required, despite the data structure change. Use libie_cp header for libie_ctlq_ctx that contains mmio info from the start in order to not increase the diff later. Reviewed-by: Madhu Chittim <madhu.chittim@intel.com> Reviewed-by: Sridhar Samudrala <sridhar.samudrala@intel.com> Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Co-developed-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-12idpf: remove unused code for getting RSS info from deviceLarysa Zaremba
idpf_send_get_set_rss_lut_msg() and idpf_send_get_set_rss_key_msg() do not handle the get=true path properly. Response validation is insufficient, memcpy size is wrong, LE-to-CPU conversion is missing. Fortunately, those functions are never used with get=true. Given how broken this dead code is, it is unlikely to be useful in the future. Rename idpf_send_get_set_rss_lut_msg() to idpf_send_set_rss_lut_msg(), idpf_send_get_set_rss_key_msg() to idpf_send_set_rss_key_msg(), remove the get parameter and remove all get=true cases from the function. Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-12idpf: remove 'vport_params_reqd' fieldPavan Kumar Linga
While sending a create vport message to the device control plane, a create vport virtchnl message is prepared with all the required info to initialize the vport. This info is stored in the adapter struct but never used thereafter. So, remove the said field. Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Reviewed-by: Madhu Chittim <madhu.chittim@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-12libie: add bookkeeping support for control queue messagesPhani R Burra
Small send control queue message buffers are managed and reused by libie itself, bigger send buffers are consumed. All are tracked with the unique transaction (Xn) ids until they receive response or time out. Responses can be received out of order, therefore transactions are stored in an array and tracked though a bitmap. Rx buffers utilize page_pool. Pre-allocated DMA memory is used where possible. It reduces the driver overhead in handling memory allocation/free and message timeouts. Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Phani R Burra <phani.r.burra@intel.com> Co-developed-by: Victor Raj <victor.raj@intel.com> Signed-off-by: Victor Raj <victor.raj@intel.com> Co-developed-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com> Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com> Tested-by: Bharath R <bharath.r@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Co-developed-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-12libie: add control queue supportPhani R Burra
Libie will now support control queue setup and configuration APIs. These are mainly used for mailbox communication between drivers and control plane. Make use of the libeth_rx page pool support for managing controlq buffers. Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Phani R Burra <phani.r.burra@intel.com> Co-developed-by: Victor Raj <victor.raj@intel.com> Signed-off-by: Victor Raj <victor.raj@intel.com> Co-developed-by: Sridhar Samudrala <sridhar.samudrala@intel.com> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com> Co-developed-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com> Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Tested-by: Bharath R <bharath.r@intel.com> Co-developed-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-12libeth: allow to create fill queues without NAPIPavan Kumar Linga
Control queues can utilize libeth_rx fill queues, despite working outside of NAPI context. The only problem is standard fill queues requiring NAPI that provides them with the device pointer. Introduce a way to provide the device directly without using NAPI. Suggested-by: Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com> Tested-by: Bharath R <bharath.r@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-12libie: add PCI device initialization helpers to libiePhani R Burra
idpf and ixd drivers serve different PCI functions on the same device, therefore their PCI configuration flow is very similar. Add support functions for idpf and ixd to configure PCI functionality and access MMIO space. Add a mapping list which can be traversed by a driver, e.g. to pass certain I/O mappings to the auxbus devices. Such list is also traversed by the libie_pci_get_mmio_addr() helper, which allows for easier memory access. Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Phani R Burra <phani.r.burra@intel.com> Co-developed-by: Victor Raj <victor.raj@intel.com> Signed-off-by: Victor Raj <victor.raj@intel.com> Co-developed-by: Sridhar Samudrala <sridhar.samudrala@intel.com> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com> Co-developed-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com> Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com> Tested-by: Bharath R <bharath.r@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Co-developed-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-12virtchnl: move virtchnl and virtchnl2 headers to 'include/linux/net/intel'Victor Raj
virtchnl2 headers will be used by both idpf and ixd drivers, so they have to be moved to an include directory. On top of that, it would be useful to place all iavf headers together with other intel networking headers. Move abovementioned intel header files into 'include/linux/net/intel'. While at it, remove the self-include from iavf_types.h. Suggested-by: Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by: Sridhar Samudrala <sridhar.samudrala@intel.com> Signed-off-by: Victor Raj <victor.raj@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-08-12objtool/klp: Fix .kcfi_traps special section extractionJosh Poimboeuf
create_fake_symbols() creates a symbol per entry for special sections. It does so in two steps: first for the sections which have ANNOTATE_DATA_SPECIAL annotations, then for the rest, using entsize or the reloc count to infer the entry size. The second step skips the sections already handled by the first one by looking for a symbol at offset 0. That heuristic is too fuzzy: with Clang and CONFIG_CFI, it misfires on .kcfi_traps because Clang emits a .Ltmp* assembler-local label at the start of the section, so no symbols are created and clone_special_sections() extracts nothing. klp-build still reports SUCCESS, but the livepatch module has no __kcfi_traps section and the traps for the patched functions are lost. Look for the actual fake symbols created by the first step instead. Fixes: da4326573ae8d ("objtool/klp: Fix kCFI trap handling") Reported-by: Joe Lawrence <joe.lawrence@redhat.com> Closes: https://lore.kernel.org/r/akQNqlfFC0T5pcMa@redhat.com Acked-by: Song Liu <song@kernel.org> Link: https://patch.msgid.link/8faaead205b219607b6fc2359ae743be824056eb.1786230311.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
2026-08-12audit: avoid dropping live tree ref on fsnotify rule autoremoveJérémy Jean
audit_del_rule() is used for both netlink deletion templates and internal fsnotify autoremove. The former passes a parsed template which owns a temporary tree reference; the latter passes the installed entry itself. The unconditional audit_put_tree() at the end of audit_del_rule() assumes the template case. For mixed AUDIT_DIR plus AUDIT_EXE rules, an fsnotify autoremove event therefore drops the installed rule's live tree reference. Repeating this across rules sharing the same tree can free the tree while another rule still references it, and a later autoremove dereferences the freed pathname while comparing rules. Move the temporary-tree put to audit_rule_change(), the caller that owns deletion templates. Keep it in the AUDIT_DEL_RULE cleanup so both successful deletion and -ENOENT still release the parser-owned tree. Cc: stable@kernel.org Fixes: 34d99af52ad4 ("audit: implement audit by executable") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr> Reviewed-by: Ricardo Robaina <rrobaina@redhat.com> Tested-by: Ricardo Robaina <rrobaina@redhat.com> [PM: dropped unnecessary comment for line length reasons] Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-08-12objtool/klp: Fix vmlinux .klp.symid link error for .exitcall.exit symbolsPuranjay Mohan
Building a kernel via klp-build fails to link: `__exitcall_aes_mod_exit' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.exitcall.exit' of vmlinux.o `__exitcall_dax_exit' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.exitcall.exit' of vmlinux.o `__exitcall_hid_exit' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.exitcall.exit' of vmlinux.o `__exitcall_usb_serial_module_exit' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.exitcall.exit' of vmlinux.o module_exit() on a built-in emits a static __exitcall_$fn pointer into .exitcall.exit, which vmlinux.lds.h discards unconditionally via EXIT_CALL. When two built-in translation units define a module_exit() function of the same name, the resulting local symbols collide, symid_needed() sees a duplicate and emits a .klp.symid entry for each, referencing symbols the linker then throws away. Same-named module_exit() functions are not rare: dax_exit drivers/dax/device.c, drivers/dax/fsdev.c hid_exit drivers/hid/hid-core.c, drivers/hid/usbhid/hid-core.c aes_mod_exit arch/arm64/crypto/aes-ce-ccm-glue.c, lib/crypto/aes.c usb_serial_module_exit module_usb_serial_driver() expands to this fixed name in each of its ~49 users The last one makes the collision structural rather than accidental: any kernel with two built-in USB serial drivers has it. This is not arch specific either; it only requires the objects to be built in rather than modular, which is why a monolithic config trips it while a typical distro config does not. Add .exitcall.exit to the discarded section list so its symbols don't get symids. This is the same failure mode as "objtool/klp: Fix vmlinux .klp.symid link error for .no_trim_symbol symbols", for another unconditionally discarded allocated section. Fixes: 029223d30162 ("objtool/klp: Add .klp.symid for sympos disambiguation") Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Link: https://patch.msgid.link/m24igzlbxf.fsf@kernel.org Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
2026-08-12f2fs: unify add/remove ino entry API for all ino typesChao Yu
- Call f2fs_add_ino_entry() and f2fs_remove_ino_entry() for ORPHAN_INO - introduce __f2fs_add_ino_entry() to wrap __add_ino_entry(), so that both f2fs_add_ino_entry() and f2fs_set_dirty_device() will call __f2fs_add_ino_entry(). So, after this change: add delete lookup ORPHAN_INO f2fs_add_ino_entry f2fs_remove_ino_entry N/A FLUSH_INO f2fs_set_dirty_device f2fs_remove_ino_entry f2fs_is_dirty_device APPEND_INO f2fs_add_ino_entry f2fs_remove_ino_entry f2fs_exist_written_data UPDATA_INO f2fs_add_ino_entry f2fs_remove_ino_entry f2fs_exist_written_data TRANS_DIR_INO f2fs_add_ino_entry N/A f2fs_exist_written_data XATTR_DIR_INO f2fs_add_ino_entry N/A f2fs_exist_written_data Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-08-12f2fs: fix to zero post-EOF data when extending file sizeChao Yu
generic/794 4s ... - output mismatch (see /share/git/fstests/results//generic/794.out.bad) --- tests/generic/794.out 2026-06-12 08:46:32.766426241 +0800 +++ /share/git/fstests/results//generic/794.out.bad 2026-07-05 18:32:55.000000000 +0800 @@ -1,4 +1,16 @@ QA output created by 794 append_write +FAIL: non-zero data in gap [4080,4096) after shutdown+remount +000000 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a >ZZZZZZZZZZZZZZZZ< +* +001000 truncate_up ... (Run 'diff -u /share/git/fstests/tests/generic/794.out /share/git/fstests/results//generic/794.out.bad' to see the entire diff) Ran: generic/794 Failures: generic/794 Failed 1 of 1 tests Steps of generic/794: 1. write 4096 bytes to file w/ 0x5a 2. use fiemap to get PBA of first block in file 3. truncate file to 4080 4. umount; write 4096 bytes to file w/ 0x5a directly via PBA; mount 5. extend filesize via a) append 4096 from offset 4096, or b) truncate 8192, or c) fallocate 4096 from offset 4096 6. verify the gap is zeroed in memory [4080,4096) 7. sync range 4096 from offset 4096; shutdown -f (flush meta before shutdown) 8. umount; mount; verify [4080,4096) is zeroed or not. When extending file size (e.g. via truncate, fallocate, or write) across an unaligned EOF boundary, we need to ensure that post-EOF data in the partial page is zeroed out in pagecache and marked dirty, then writeback the cache to persist zeroed data before committing inode w/ updated i_size. This help to prevent stale disk data beyond the previous EOF from being exposed after remounting or crash recovery. Since f2fs is a LFS filesystem, we only support direct write via PBA in pinfile, and pinfile has section-aligned filesize, so in Android, there should no problem, but for other usage in different environment, let's fix this w/ fsync_mode=strict mount option. Cc: stable@kernel.org Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-08-12f2fs: fix to off-by-one issue in f2fs_zero_post_eof_page()Chao Yu
Otherwise, it will drop one more page after new_size which is not necessary. Cc: stable@kernel.org Fixes: ba8dac350faf ("f2fs: fix to zero post-eof page") Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-08-12sched_ext: Convert scx_bpf_cid_override() to __arena array argumentsTejun Heo
scx_bpf_cid_override() predates the cid-form arena transition and takes its arrays as verifier-checked mem+size buffers, forcing scx_qmap to keep the cpu_to_cid and shard_start arrays in writable bss while the rest of its state lives in the arena. Unify on arena arguments before cid-form schedulers start seeing real use. BPF now translates between BPF and kernel arena addresses for __arena arguments. Take the arrays as __arena arguments, with the counts passed in entries. The counts now size the snapshot copies and are bounds-checked before them. scx_qmap moves the arrays into struct qmap_arena. As the arena is mmapped at load, the loader populates them between load and attach instead of before load. The arena argument address translation is currently implemented only on x86-64. Schedulers calling this kfunc load only there for now. Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-12sched_ext: Convert sub-cap kfuncs to __arena cmask argumentsTejun Heo
The sub-cap kfuncs take their cmask arguments as __ign pointers. The values cross the kfunc boundary as unchecked scalars and scx_cmask_ref_init() rebases them into the arena by hand. BPF now translates between BPF and kernel arena addresses for __arena arguments. Tag the cmask arguments __arena so the kfuncs receive kernel addresses and scx_cmask_ref_init() loses the hand-rolled conversion. The optional denied_out keeps its NULL not-provided signal via __arena__nullable. The mandatory masks use plain __arena. scx_qmap's call sites drop the (void *)(long) casts since the BPF-side declarations type the cmask arguments __arena and take arena pointers directly. The arena argument address translation is currently implemented only on x86-64. Schedulers calling these kfuncs load only there for now. Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-12sched_ext: Pass kernel arena pointers to ops_cid callbacksTejun Heo
The cid-form set_cmask() and sub_caps_updated() callbacks receive cmasks that the kernel builds in the arena, and the kernel converts the kernel addresses to the BPF arena pointer form by hand before each call. BPF now translates between BPF and kernel arena addresses for __arena arguments. Tag the arguments __arena in the cfi stubs and the ops_cid member declarations and pass the kernel arena addresses directly, dropping the manual scx_kaddr_to_arena() conversions and the now-unused helper. The delivered value is unchanged and existing BPF-side code works as before. The arena argument address translation is currently implemented only on x86-64. cid-form schedulers implementing these callbacks load only there for now. Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-12Merge branch 'for-7.3' into for-7.3-arena-argsTejun Heo
2026-08-12PCI: Introduce PCI_SLOT_PLACEHOLDER constant for slot_nr placeholder valueFarhan Ali
Introduce a constant for placeholder value and update the kerneldoc for pci_create_slot() to reference PCI_SLOT_PLACEHOLDER instead of -1 throughout. No functional change. Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Farhan Ali <alifm@linux.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Tyrel Datwyler <tyreld@linux.ibm.com> Cc: linuxppc-dev@lists.ozlabs.org Link: https://patch.msgid.link/20260805165518.794-2-alifm@linux.ibm.com
2026-08-12PCI/ASPM: Mask ASPM states based on Devicetree propertiesKrishna Chaitanya Chundru
Some platforms require selectively disabling specific ASPM states on a given PCIe link to avoid link instability or functional failures caused by board-level connectivity constraints such as PCB routing, connectors, slots, or external cabling. Devicetree supports disabling ASPM L0s, L1, and L1 PM Substates via the 'aspm-no-l0s', 'aspm-no-l1' [1], and 'aspm-no-l1ss' [2] properties. However, the ASPM driver does not currently honor these properties when initializing the default link state. When firmware enables L1 PM Substates before the kernel takes over, masking aspm_support alone is insufficient to disable them in hardware. pcie_config_aspm_link() guards L1SS configuration behind a check on aspm_capable, which is derived from aspm_support. Once aspm_support is masked, pcie_config_aspm_l1ss() is never called, leaving firmware-enabled L1SS substates active in hardware. Fix this by introducing pcie_link_has_aspm_override() to check for DT override properties on either endpoint of the link. In pcie_aspm_override_default_link_state(), use it to: - Mask aspm_support, aspm_default, and aspm_enabled for any disabled state, so software's view of the link stays in sync with what is actually programmed in hardware. Leaving aspm_enabled stale would make pcie_aspm_enabled() and the aspm sysfs attributes report a state as active even after it has been masked, and could cause pcie_config_aspm_link()'s "already in requested state" check to skip reprogramming hardware to match. - Explicitly call pcie_config_aspm_l1ss(link, 0) before masking aspm_support when firmware has L1SS active and DT requests disabling L1 or L1SS, since pcie_config_aspm_link() will no longer do so once aspm_capable is derived from the masked aspm_support. Move the aspm_default initialization and pcie_aspm_override_default_link_state() call in pcie_aspm_cap_init() to before the "Restore L0s/L1" block. pcie_aspm_cap_init() disables L1 in hardware prior to aspm_l1ss_init() and re-enables it only in the restore block. Calling pcie_config_aspm_l1ss() while L1 is already disabled satisfies its precondition ("Caller must disable L1 first"), whereas the previous placement after the restore violated it. Since the restore block writes back the parent_lnkctl/child_lnkctl snapshot taken from hardware before the DT override ran, mask the L0s and L1 enable bits out of that snapshot for any state the override has just disabled in aspm_support. Otherwise the restore step would unconditionally reprogram the link back to firmware's original L0s/L1 configuration, defeating the Devicetree override it is meant to enforce. Move pcie_config_aspm_l1ss() earlier in the file so it can be called from pcie_aspm_override_default_link_state(). Link [1]: https://github.com/devicetree-org/dt-schema/pull/188 Link [2]: https://github.com/devicetree-org/dt-schema/pull/190 Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260727-aspm-v6-3-2ebb3ee7ef71@oss.qualcomm.com
2026-08-12PCI/ASPM: Disable/restore ASPM on every function for multi-function devicesKrishna Chaitanya Chundru
pcie_aspm_cap_init() disables ASPM L0s/L1 before touching L1SS config, then restores the pre-existing state afterward. Both steps only ever touched link->downstream, i.e. function 0 of the downstream component, leaving sibling functions (>0) on a multi-function device untouched. This means the "disable" step does not actually disable ASPM link-wide on a multi-function device: a sibling function can still have L1 enabled even after this step runs. PCIe r7.0, sec 7.5.3.7, recommends programming the same ASPM Control value for all functions of a multi-function device, and pcie_config_aspm_link() already loops over every function on the bus for exactly this reason. Loop over every function on linkbus->devices for both the disable and restore steps, keeping the existing sec 7.5.3.7 ordering (disable downstream functions before upstream, restore upstream before downstream functions). The masked pcie_capability_clear_and_set_word() accessor from the previous commit makes this safe: it only ever touches the ASPM Control bits, so function-specific bits elsewhere in LNKCTL (e.g. Read Completion Boundary, CLKREQ Enable) on sibling functions are left untouched. Fixes: 7447990137bf ("PCI/ASPM: Disable L1 before disabling L1 PM Substates") Closes: https://lore.kernel.org/all/20260721143945.86E7D1F000E9@smtp.kernel.org/ Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260727-aspm-v6-2-2ebb3ee7ef71@oss.qualcomm.com
2026-08-12ceph: use the mount idmap for the owner checks in the SET_LAYOUT ioctlsZhan Xusheng
ceph_ioctl_set_layout() and ceph_ioctl_set_layout_policy() call inode_owner_or_capable() with &nop_mnt_idmap instead of the idmap of the mount the ioctl was issued on. CephFS supports idmapped mounts (FS_ALLOW_IDMAP), so on such a mount this compares the caller's fsuid against the unmapped on-disk owner rather than the mapped owner: the actual owner can be wrongly denied with -EACCES and an unrelated caller wrongly allowed. Both functions already have the struct file, so use file_mnt_idmap(file) instead. Cc: stable@vger.kernel.org Fixes: cee38bbf5556 ("ceph: add owner/capability checks for CEPH_IOC_SET_LAYOUT*") Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com> Reviewed-by: Xiubo Li <xiubo.li@clyso.com> Reviewed-by: Alex Markuze <amarkuze@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2026-08-12ceph: fix MDS random selection readiness predicateYiming Zhu
CEPH_MDS_IS_READY() is parsed so that the ternary expression can return true for an MDS entry with state 0 when it is not laggy. This allows the random selector to choose a down/DNE rank. Group the ternary expression under the state check so zero-state ranks are not treated as ready. Cc: stable@vger.kernel.org Fixes: b38c9eb4757d ("ceph: add possible_max_rank and make the code more readable") Link: https://tracker.ceph.com/issues/78648 Signed-off-by: Yiming Zhu <zhuyiming@kuaishou.com> Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2026-08-12libceph: Avoid using invalid osd indices from primary_tempRaphael Zimmer
A corrupted osdmap received from a Ceph monitor or OSD may contain osd indices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts that don't exist, i.e., that are greater than max_osd or smaller than CEPH_HOMELESS_OSD (-1). These indices are used to create the up and acting set in ceph_pg_to_up_acting_osds(), called from calc_target(). While most of these osd indices are checked, the one from primary_temp is not. Subsequently, this may lead to calc_target() returning this (potentially invalid) index as target osd for a (linger) request. Because the osd_state, osd_weight, and osd_addr arrays only contain max_osd entries (with indices 0 to max_osd -1), this leads to out-of-bounds accesses when trying to read values from these arrays. This patch fixes the issue by adding a check to get_temp_osds(), so that only valid osd indices from primary_temp are used, and it falls back to using the primary from pg_temp or the up set if it is invalid. [ idryomov: changelog ] Cc: stable@vger.kernel.org Fixes: 5e8d4d36bf23 ("libceph: add support for primary_temp mappings") Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de> Reviewed-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2026-08-12libceph: fix OOB read in decode_watchers() via missing bounds checkPavitra Jha
ceph_start_decoding() validates that struct_len bytes remain in the buffer after the encoding header, but accepts struct_len=0 as valid: ceph_decode_need(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an obj_list_watch_response_t reply with struct_len=0, ceph_start_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads. The immediately following ceph_decode_32(p) in decode_watchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzalloc_objs() as the watcher count. The sibling function decode_watcher() already uses the safe variants (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32) after its own ceph_start_decoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight. Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end, *num_watchers, bad), consistent with the established pattern. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges beyond OSD session establishment. [ idryomov: trim changelog ] Cc: stable@vger.kernel.org Fixes: a4ed38d7a180 ("libceph: support for CEPH_OSD_OP_LIST_WATCHERS") Signed-off-by: Pavitra Jha <jhapavitra98@gmail.com> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2026-08-12libceph: fix multiple unsafe decodes in decode_locker()Pavitra Jha
decode_locker() in cls_lock_client.c contains three unsafe decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_copy() at the locker_id_t name field has no preceding bounds check. With p == end after ceph_start_decoding() accepts struct_len=0, this reads sizeof(ceph_entity_name) = 9 bytes past the validated buffer boundary. 2. *p += sizeof(struct ceph_timespec) after the locker_info_t header is an unchecked pointer advance. A malicious OSD can position p past end, causing all subsequent _safe checks to pass against a bogus boundary. 3. len = ceph_decode_32(p) has no preceding bounds check, and the immediately following *p += len is uncapped. A malicious OSD can send len=0xffffffff, advancing p gigabytes past end and escaping the decode window entirely. Fix all three by replacing bare operations with their safe variants: ceph_decode_copy -> ceph_decode_copy_safe *p += sizeof(...) -> ceph_decode_skip_n ceph_decode_32(p) -> ceph_decode_32_safe *p += len -> ceph_decode_skip_n A new label is added to return -EINVAL on any bounds violation. -EINVAL is appropriate here: the data received from the OSD is structurally malformed, which is an invalid argument to the decode contract regardless of whether the caller or the wire is at fault. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition) without any further privileges beyond OSD session establishment. [ idryomov: use ceph_decode_skip_string() to skip description, trim changelog ] Cc: stable@vger.kernel.org Fixes: d4ed4a530562 ("libceph: support for lock.lock_info") Signed-off-by: Pavitra Jha <jhapavitra98@gmail.com> Reviewed-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2026-08-12libceph: tolerate addrvecs with multiple entries of the same typeKefu Chai
ceph_decode_entity_addrvec() rejects any addrvec containing more than one entry that matches the requested msgr type (LEGACY or MSGR2), logging "another match of type N in addrvec" and returning -EINVAL. Some admin tooling (e.g. pveceph mon create from Proxmox VE) generates addrvecs with multiple same-type entries when public_network lists more than one CIDR: it picks one local IP per subnet and emits both a v2 and a v1 entry for each IP. Monmaps shaped this way cause: libceph: mon0 (1)10.10.10.15:6789 session established libceph: another match of type 1 in addrvec libceph: problem decoding monmap, -22 No Ceph code uses the extra entries: since Nautilus, the userspace messenger (AsyncMessenger) unconditionally picks the first address of the requested type and ignores any subsequent matches. Match that behavior: use the first matching entry and silently skip any subsequent ones. This is a compatibility fix for existing deployments and does not enable dual-stack or multi-subnet address selection. [ idryomov: tweak ceph_decode_entity_addrvec() comment ] Cc: stable@vger.kernel.org Fixes: a5cbd5fc22d5 ("libceph, ceph: get and handle cluster maps with addrvecs") Link: https://bugzilla.proxmox.com/show_bug.cgi?id=7518 Signed-off-by: Kefu Chai <k.chai@proxmox.com> Reviewed-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>