summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-07-21geneve: make geneve_fill_info() RTNL independentEric Dumazet1-11/+24
Now that geneve->cfg is an RCU-protected pointer, update geneve_fill_info() to read the configuration under RCU read lock instead of relying on RTNL. Also add const qualifiers to the dereferenced pointers where appropriate and fix local variable declaration ordering. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260707145331.3717941-4-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21geneve: convert config to RCU-protected pointerEric Dumazet1-95/+118
geneve_changelink() currently updates configuration by copying it over the old one using memcpy() under RTNL, forcing data path pause via geneve_quiesce() and synchronize_net() to avoid reading torn values. Convert geneve->cfg to an RCU-protected pointer, allowing lockless and safe reads under RCU read lock without synchronization overhead. Key changes: - Introduced geneve_config_alloc/free() helpers for lifecycle. - geneve_configure() allocates config and publishes it via RCU. - Setting dev->priv_destructor = geneve_free_dev handles config cleanup if register_netdevice() fails or during netdev unregistration. - geneve_changelink() performs RCU swap; old config is freed via call_rcu_hurry(). - Allocates new dst_cache during changelink to prevent pcpu sharing. - Removed geneve_quiesce/unquiesce() and synchronize_net() from changelink. - Added rcu_barrier() to module exit to wait for pending callbacks. - Updated data path to use rcu_dereference(). - Updated geneve_fill_info() to use rtnl_dereference() for now. Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260707145331.3717941-3-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21geneve: pass geneve_config pointer to helper functionsEric Dumazet1-64/+76
In preparation for converting geneve->cfg to an RCU-protected pointer, update helper functions to explicitly accept a const struct geneve_config pointer instead of dereferencing geneve->cfg directly. Signed-off-by: Eric Dumazet <edumazet@google.com> Suggested-by: Paolo Abeni <pabeni@redhat.com> Link: https://patch.msgid.link/20260707145331.3717941-2-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21drm/gpusvm: Zero HMM PFNs before scanning rangesStanislav Kinsburskii1-1/+1
drm_gpusvm_scan_mm() asks HMM to report the current CPU page-table state without faulting missing entries by leaving default_flags set to zero. The HMM PFN array is still caller-owned input/output state, and the framework may preserve input bits while filling entries. It is not safe for the caller to hand HMM an uninitialized array and then treat entries without HMM_PFN_VALID as an authoritative unpopulated result. Use kvcalloc() for the temporary PFN array so entries that are not reported as valid start from the documented zero state. This prevents random stack or heap contents from being interpreted as HMM PFN flags or PFN values during the scan. Fixes: f1d08a586482 ("drm/gpusvm: Introduce a function to scan the current migration state") Cc: stable@vger.kernel.org Signed-off-by: Stanislav Kinsburskii <skinsburskii@gmail.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/178406967042.1113483.2116704310277917086.stgit@skinsburskii
2026-07-21drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evictMatthew Brost1-1/+3
If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path. Fixes: 99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20260714170025.3487974-1-matthew.brost@intel.com
2026-07-21net: stmmac: eic7700: add support for eth1 clock inversion variantZhi Li1-8/+103
The eth1 MAC exhibits silicon-inherent RX and TX timing behavior that differs from the eth0 implementation. At 1000Mbps, RX sampling requires clock inversion due to a fixed MAC input skew that cannot be compensated by standard RGMII delay settings. The TX path includes a fixed ~2ns internal delay introduced by the MAC silicon. This delay is always present and is already accounted for in the device tree tx-internal-delay-ps property as part of the effective output timing. The tx-internal-delay-ps property describes the effective delay seen at the MAC output. Since the hardware register controls only the programmable portion of the delay, the driver subtracts the fixed silicon-inherent component before programming the delay register. Use compatible-specific match data to identify the eth1 variant and apply RX clock inversion only at 1000Mbps. The PHY interface mode is adjusted via phy_fix_phy_mode_for_mac_delays() to avoid double-application of RGMII delays when MAC-side delays are already present. Link speed dependency means RX sampling configuration is applied in the fix_mac_speed callback after negotiation. No behavior changes for the existing eth0 controller. Signed-off-by: Zhi Li <lizhi2@eswincomputing.com> Link: https://patch.msgid.link/20260707064234.1333-1-lizhi2@eswincomputing.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21net: stmmac: eic7700: make RGMII delay properties optionalZhi Li1-6/+0
Make rx-internal-delay-ps and tx-internal-delay-ps optional in the EIC7700 DWMAC driver. The driver previously required both properties to be present and would fail probe when they were missing. This restricts valid hardware configurations where RGMII timing is instead provided by the PHY or board design. Update the driver to treat missing delay properties as zero delay, allowing systems without explicit MAC-side delay tuning to operate correctly. This aligns the driver behavior with the updated device tree binding and provides a safe default configuration when MAC-side delay programming is not required. Signed-off-by: Zhi Li <lizhi2@eswincomputing.com> Link: https://patch.msgid.link/20260707064218.1316-1-lizhi2@eswincomputing.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-20cdrom: fix stack out-of-bounds read in CDROMVOLCTRLXu Rao1-0/+1
mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao <raoxu@uniontech.com> Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Link: https://patch.msgid.link/20260720194421.1497-2-phil@philpotter.co.uk Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-07-20bnx2x: fix null pointer dereference in bnx2x_free_mem_bp()Abdun Nihaal1-4/+4
In one of the error path in bnx2x_alloc_mem_bp(), bnx2x_free_mem_bp() may be called with bp->fp uninitialized. And so, there could be a null pointer dereference in bnx2x_free_mem_bp(). Fix that by initializing the fp_array_size after the bp->fp pointer is correctly initialized. Cc: stable+noautosel@kernel.org # untested fix to unlikely error path Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260707054618.932108-1-nihaal@cse.iitm.ac.in Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-20bonding: fix devconf_all NULL dereference when IPv6 is disabledZhaolong Zhang1-1/+2
When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: <TASK> ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Fix this by adding ipv6_mod_enabled() condition check in the caller. Fixes: 4e24be018eb9 ("bonding: add new parameter ns_targets") Signed-off-by: Qianheng Peng <pengqh1@chinatelecom.cn> Signed-off-by: Zhaolong Zhang <zhangzl68@chinatelecom.cn> Reviewed-by: Hangbin Liu <liuhangbin@gmail.com> Link: https://patch.msgid.link/20260707010622.487333-1-zhangzl2013@126.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-20net: phy: marvell: fix return codeMichael Walle1-1/+1
Return the correct error code, not the value written to the register. Fixes: a219912e0fec ("net: phy: marvell: implement config_inband() method") Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260706120637.1947685-1-mwalle@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21ata: libata-sff: don't busy-wait for PIO data-in command completionRichard Weinberger1-7/+17
Unlike PIO data-out, the PIO data-in protocol raises no completion interrupt, the last interrupt announces the final data block, and once the host has drained it from the data register the ending status must be obtained synchronously. ata_sff_hsm_move() does this by spinning in ata_wait_idle() for up to 10ms. Usually this is not a big deal unless the device is slow. In my case it's a CF card which keeps BSY asserted for multiple milliseconds(!) after the final data block. Since the waiting happens in the interrupt handler, under the port lock with interrupts disabled, the CPU is hogged for milliseconds on every read command. To improve the situation, bound the inline wait to ~100us. If the device is still busy after that, mark the command ATA_TFLAG_POLLING, so the interrupt handler won't race for it, and obtain the ending status via ata_sff_pio_task(), which sleeps between status checks instead of spinning with the lock held. Since ata_sff_pio_task() may now finish a data-in command, it must wait for both BSY and DRQ to clear at HSM_ST_LAST, matching what ata_wait_idle() enforced. Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2026-07-21power: supply: macsmc: Support macOS 27 SMC firmwareSasha Finkelstein1-7/+45
The SMC firmware included in macOS 27 changed the size of BCF0 key from 4 to 1 bytes. This key is used for indicating that battery state is critically low. In addition, B0RM key has changed endianness. Reviewed-by: Sven Peter <sven@kernel.org> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Reviewed-by: Janne Grunau <j@jannau.net> Cc: stable@vger.kernel.org Fixes: 0ebf821cf6c7 ("power: supply: Add macsmc-power driver for Apple Silicon") Signed-off-by: Sasha Finkelstein <k@chaosmail.tech> Link: https://patch.msgid.link/20260712-gate-power-v4-1-aa59c6583247@chaosmail.tech Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-21rust: device: make lifetime on `Core` and `CoreInternal` invariantGary Guo1-3/+3
Currently the lifetime on `Core` and `CoreInternal` is covariant. This means that they can be coerced into shorter living lifetimes. On `probe` function, signature has `&'bound Device<Core<'a>>`; the type's wellformness would imply `'a: 'bound` and thus the type can be coerced `&'bound Device<Core<'bound>>`, defeating the purpose of having the lifetime bound to prevent users of the `Core` type to escape the function. Fix this by making the lifetime invariant, so the coercion is impossible. The lifetime here only needs to be "branded" so it does not coerce or unify with other lifetimes, so we do not need to ensure `'bound: 'a`. This requires modifying `nova-core` which relies on this implied bound due to pre-2024 capture rule. The "use" bound can be removed if built with edition 2024. Fixes: 24799831d631 ("rust: device: make Core and CoreInternal lifetime-parameterized") Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260713201455.640151-1-gary@kernel.org [ Fixup the debugfs sample to use an explicit lifetime instead of Core<'_>. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-21power: supply: max17040: handle missing status supplierJianing Li1-1/+5
MAX17040 does not report charger state itself, so the driver forwards POWER_SUPPLY_PROP_STATUS to a supplier power supply. If no supplier is registered, power_supply_get_property_from_supplier() returns -ENODEV and leaves the output value untouched. max17040_get_property() currently ignores that error and returns success, so userspace can read an uninitialized status value from the battery power supply. This happens on systems that use the fuel gauge without a charger supplier relationship in firmware. Return POWER_SUPPLY_STATUS_UNKNOWN when no supplier provides STATUS, and propagate other supplier lookup errors. Fixes: f4b782af61ae ("power: max17040: pass status property from supplier") Cc: stable@vger.kernel.org # 6.7+ Signed-off-by: Jianing Li <m13940358460@163.com> Link: https://patch.msgid.link/20260701061042.1008-1-m13940358460@163.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-20Bluetooth: btusb: validate Realtek vendor event lengthPengpeng Hou1-1/+3
btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation. Fixes: 044014ce85a1 ("Bluetooth: btrtl: Add Realtek devcoredump support") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-07-20of: reserved_mem: prevent OOB when too many dynamic regions are definedSang-Heon Jeon1-3/+11
On boot, fdt_scan_reserved_mem() saves each dynamically-placed /reserved-memory subnode into a local array of size MAX_RESERVED_REGIONS. If the device tree defines more than MAX_RESERVED_REGIONS dynamically-placed regions, fdt_scan_reserved_mem() writes past the end of the local array. Add a bounds check that logs an error and skips the excess regions, restoring the original behavior. Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory regions are processed") Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com> Link: https://patch.msgid.link/20260614133807.2165124-2-ekffu200098@gmail.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-20of: reserved_mem: print skipped node name when too many regions are definedSang-Heon Jeon1-1/+2
When too many reserved memory regions are defined, fdt_init_reserved_mem_node() logs an error and skips the region without naming the node. Print the node name so the skipped node can be identified, matching fdt_scan_reserved_mem(). Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com> Link: https://patch.msgid.link/20260614133807.2165124-3-ekffu200098@gmail.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-20Merge tag 'mm-hotfixes-stable-2026-07-20-11-37' of ↵Linus Torvalds1-4/+1
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "12 hotfixes. 8 are cc:stable and the remainder address post-7.1 issues or aren't considered appropriate for backporting. 10 are for MM. All are singletons - please see the relevant changelogs for details" * tag 'mm-hotfixes-stable-2026-07-20-11-37' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/memory-failure: trace: change memory_failure_event to ras subsystem mm: page_reporting: allow driver to set batch capacity mm/kmemleak: fix checksum computation for per-cpu objects mm/damon/core: disallow overlapping input ranges for damon_set_regions() MAINTAINERS: add Usama as a THP reviewer fat: avoid stack overflow warning mm/damon/core: validate ranges in damon_set_regions() m68k: avoid -Wunused-but-set-parameter in clear_user_page() mm/huge_memory: set PG_has_hwpoisoned only after new folio head is established mm/page_vma_mapped: fix device-private PMD handling MAINTAINERS: s/SeongJae/SJ/ userfaultfd: prevent registration of special VMAs
2026-07-20drm/panel: panel-edp: Adjust T8 timing for AUO B116XAK01.6 and B140XTK02.4Dio Zhang1-2/+2
Screen garbage or flickering can be observed during mode changes (such as VT switches) on systems using the AUO B116XAK01.6 and B140XTK02.4 panels. This occurs because the backlight is enabled before the video signal stabilizes. Waveform measurements show that the panel signal takes around 140ms to stabilize after a mode change, meaning the previous 50ms T8 timing was insufficient. To resolve this issue, adjust the eDP panel delay entry from delay_200_500_e50 to delay_200_500_e200 (increasing T8 from 50ms to 200ms). This matches the updated panel specifications from AUO, which now formally define T8 as 200ms to mask any display abnormalities during mode changes. Signed-off-by: Dio Zhang <dioyc_zhang@compal.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260720025358.2781136-1-dioyc_zhang@compal.corp-partner.google.com
2026-07-20regcache: Warn if regcache_sync() is called in cache_only modeMark Brown1957-4411/+6405
phucduc.bui@gmail.com <phucduc.bui@gmail.com> did a bit of work to help people avoid running into silly errors. Link: https://patch.msgid.link/20260720033238.52479-1-phucduc.bui@gmail.com
2026-07-20regcache: Validate cache_only state in regcache_sync_region()bui duc phuc1-0/+4
Add a WARN_ON() check to ensure regcache_sync_region() is not called while cache_only is enabled. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260720033238.52479-2-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-20regcache: Warn if regcache_sync() is called in cache_only modebui duc phuc1-0/+10
Calling regcache_sync() while cache_only is enabled is invalid API usage, since writes are intentionally kept in the cache and cannot be synchronized to hardware. Document that callers must disable cache_only before calling regcache_sync(), and reject incorrect usage with a WARN_ON() and -EINVAL. Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260720033238.52479-1-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-20blk-crypto: Allow control over whether hardware is usedEric Biggers1-1/+2
fscrypt uses inline encryption hardware only when the "inlinecrypt" mount option is given. I'd like to keep that behavior even after standardizing on the blk-crypto API for file contents encryption. That is, the default should continue to be the well-tested CPU-based encryption code, and the use of inline encryption hardware should continue to be an opt-in feature for systems where it's beneficial and has been fully validated (including verifying ciphertext correctness). To support this use case, extend blk_crypto_config with a new flag BLK_CRYPTO_CFG_ALLOW_HW. For now it's always set. Later commits will change that. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260713023708.9245-4-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20remoteproc: Remove redundant dev_err()/dev_err_probe()Pan Chuang8-31/+12
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"), devm_request_irq() and devm_request_threaded_irq() automatically log detailed error messages on failure. Remove the now-redundant driver-specific dev_err() and dev_err_probe() calls. Signed-off-by: Pan Chuang <panchuang@vivo.com> Acked-by: Paul Cercueil <paul@crapouillou.net> # Ingenic Link: https://lore.kernel.org/r/20260717065224.600593-1-panchuang@vivo.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-07-20remoteproc: Add AMD MicroBlaze/V BRAM-based remote processor driverBen Levinsky3-0/+223
Add a remoteproc driver for AMD MicroBlaze/V soft-core processor subsystems instantiated in programmable logic and using dual-port BRAM for firmware storage and execution. The driver parses the firmware memory window from the remoteproc device node's reg property, interprets that address and size in the processor-local address space, and then uses standard devicetree address translation through the parent bus ranges property to obtain the corresponding Linux-visible system physical address. The resulting translated region is registered as the executable remoteproc carveout and coredump segment. The processor is controlled through an active-low reset GPIO and a subsystem clock. The clock is enabled before reset is released, and the processor is kept in reset until firmware loading completes. The firmware-name property is optional, allowing firmware to be assigned later through the remoteproc framework. Firmware images without a resource table are also accepted. Signed-off-by: Ben Levinsky <ben.levinsky@amd.com> Link: https://lore.kernel.org/r/20260714202441.554065-3-ben.levinsky@amd.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-07-20drm/panfrost: Remove unused scheduled_jobs listMaíra Canal2-2/+0
The scheduled_jobs list head was introduced in commit f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") but never used. Remove the dead field and its initialization. Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://patch.msgid.link/20260710121423.2820472-2-mcanal@igalia.com Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
2026-07-20regulator: mt6358: use regmap helper to read fixed LDO calibrationDaniel Golle1-1/+1
The "fixed" LDOs with output voltage calibration use mt6358_get_buck_voltage_sel as their get_voltage_sel op, but the MT6358_REG_FIXED and MT6366_REG_FIXED entries do not populate da_vsel_reg/da_vsel_mask. The op therefore reads register 0x0 with a zero mask and shifts the result by ffs(0) - 1 = -1, which is undefined behaviour and gets flagged by UBSAN on every boot on MT6366 boards: UBSAN: shift-out-of-bounds in drivers/regulator/mt6358-regulator.c:384:38 shift exponent -1 is negative Call trace: mt6358_get_buck_voltage_sel+0xc8/0x120 regulator_get_voltage_rdev+0x70/0x170 set_machine_constraints+0x504/0xc38 regulator_register+0x324/0xc68 Besides the undefined shift, the returned selector is always 0, so the actual calibration offset programmed in <reg>_ANA_CON0 is never reported. The descriptor already carries the correct vsel_reg/vsel_mask (the ANA_CON0 calibration field), matching the regulator_set_voltage_sel_regmap op already in use. Read the selector back through regulator_get_voltage_sel_regmap instead. Fixes: cf08fa74c716 ("regulator: mt6358: Add output voltage fine tuning to fixed regulators") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Tested-by: Chen-Yu Tsai <wens@kernel.org> Link: https://patch.msgid.link/dcd98d81dede338c9bbb9700a9613c848b702e49.1784336005.git.daniel@makrotopia.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-20drm/xe/madvise: Skip invalidation for purgeable state updatesArvind Yadav1-2/+17
Purgeable state updates only change VMA/BO metadata. They do not zap PTEs when switching between DONTNEED and WILLNEED. PTEs are zapped later if the BO is actually purged. xe_vm_invalidate_madvise_range() waits on the VM dma-resv before checking vma->skip_invalidation. Since purgeable madvise marks all affected VMAs to skip invalidation, this wait is unnecessary and can stall on unrelated in-flight work. Skip the invalidate path entirely for purgeable state updates. v2: - Replace inline 'args->type != DRM_XE_VMA_ATTR_PURGEABLE_STATE' check with a small helper madvise_range_needs_invalidation(). (Himal) Suggested-by: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20260526135447.2973029-1-arvind.yadav@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Fixes: ada7486c5668 ("drm/xe: Implement madvise ioctl for xe") Cc: <stable@vger.kernel.org> # v6.18+ (cherry picked from commit 134377098b9c14abd31c3bcac00c9653f0f0c4c3) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-20USB: serial: io_ti: reject oversized boot-mode firmwarePengpeng Hou1-0/+6
do_boot_mode() copies the firmware payload, excluding its four-byte prefix, into a fixed 15.5 KiB staging buffer. check_fw_sanity() already proves that the image contains its seven-byte header and validates the declared image length and checksum, but it does not impose this boot-mode destination limit. Reject images whose payload does not fit before allocating and filling the staging buffer. Fixes: d12b219a228e ("edgeport-ti: use request_firmware()") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Johan Hovold <johan@kernel.org>
2026-07-20drm/hyperv: Move MODULE_DEVICE_TABLE to the device_id arraysUwe Kleine-König (The Capable Hub)1-2/+2
It matches the usual coding style to have the MODULE_DEVICE_TABLE macro directly after the respective arrays. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Link: https://patch.msgid.link/7f9d4a239c76b6bb384048ea5591a21ed87d9b0e.1782925276.git.u.kleine-koenig@baylibre.com
2026-07-20drm/hyperv: Explicitly set subvendor and subdevice for pci match arrayUwe Kleine-König (The Capable Hub)1-2/+2
.subvendor and .subdevice were set to 0 implicitly, so only devices with these two values set to 0 in hardware can probe automatically. Make this requirement explicit. While touching this array item, also make use of the pci macro designed for that case. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Link: https://patch.msgid.link/019450ffb519d02821364afca32b9f48bcd8d2b6.1782925276.git.u.kleine-koenig@baylibre.com
2026-07-20drm/hyperv: Unregister pci driver in error path before module unloadUwe Kleine-König (The Capable Hub)1-1/+5
The pci driver must not kept registered if the module is unloaded after vmbus_driver_register() fails. So check the return value of vmbus_driver_register() and unregister the pci driver on failure. Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device") Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Link: https://patch.msgid.link/4b7dbf00ce4ff664b7d5dd74b2f39d8d87c1ade9.1782925276.git.u.kleine-koenig@baylibre.com
2026-07-20hwmon: occ: validate poll response sensor blocksPengpeng Hou1-8/+30
The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active. Fixes: aa195fe49b03 ("hwmon (occ): Parse OCC poll response") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://lore.kernel.org/r/20260720115826.14813-1-pengpeng@iscas.ac.cn Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-07-20ovpn: use monotonic clock for peer keepalive timeoutsMarco Baffo2-4/+4
Replace ktime_get_real_seconds() with the monotonic ktime_get_boottime_seconds() to ensure the keepalive mechanism is robust against system clock modifications. Right now, the driver uses ktime_get_real_seconds() to track peer timeouts, relying on the system wall-clock. An administrative time adjustment or an NTP sync that steps the clock forward can cause `now' to instantly exceed `last_recv + timeout'. When this occurs, the driver artificially expires healthy peers. Depending on the OpenVPN user-space configuration, this triggers a premature tunnel restart (if --keepalive or --ping-restart is used) or a complete disconnection of the client (if --ping-exit is used). Fixes: 3ecfd9349f40 ("ovpn: implement keepalive mechanism") Signed-off-by: Marco Baffo <marco@mandelbit.com> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
2026-07-20USB: serial: mxuport: validate firmware header sizePengpeng Hou1-0/+7
mxuport_probe() reads version bytes at fixed offsets after request_firmware() succeeds. Firmware loading success does not prove that the blob reaches the highest version offset. Reject short firmware images before reading the version bytes. This is source-level parser hardening; no affected device or crash was observed. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Fixes: ee467a1f2066 ("USB: serial: add Moxa UPORT 12XX/14XX/16XX driver") Signed-off-by: Johan Hovold <johan@kernel.org>
2026-07-20media: bcm2835-unicam: Fix pipeline wrong validation for unpacked formatsEugen Hristev1-1/+2
The commit 08f9794d9b79 ("media: bcm2835-unicam: Fix RGB format / mbus code association") introduced a check to see whether the format requested is the same as the fourcc in the format list. However, this breaks the case when userspace requested an unpacked fourcc, e.g. RG10. Unicam can work with or without unpacking pixels, e.g. pRAA or RG10, depending on what userspace requests. In the unpacking case, a dedicated register is being set. If the userspace requests pRAA, this works, because the check validates the pipeline: v4l2-ctl -d /dev/video0 --set-fmt-video=width=3280,height=2464,pixelformat=pRAA \ --stream-mmap --stream-count=1 --stream-to=frame.raw but, with v4l2-ctl -d /dev/video0 --set-fmt-video=width=3280,height=2464,pixelformat=RG10 \ --stream-mmap --stream-count=1 --stream-to=frame.raw unicam complains at validation level: image: format mismatch: 0x300f <=> RG10 little-endian (0x30314752) This should work, because MEDIA_BUS_FMT_SRGGB10_1X10 can be packed into either RG10 or pRAA depending on the packing register. To fix this, modified the condition check to also allow in the case when requested format (fmt->pixelformat) is equal to fmtinfo->unpacked_fourcc. Fixes: 08f9794d9b79 ("media: bcm2835-unicam: Fix RGB format / mbus code association") Cc: stable@vger.kernel.org Signed-off-by: Eugen Hristev <ehristev@kernel.org> Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> [Sakari Ailus: Added Cc: stable.] Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-20drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VMIcenowy Zheng1-0/+2
The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [<ffffffff01e989d4>] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [<ffffffff01ed3a40>] pvr_vm_unmap+0x34/0x68 [powervr] [<ffffffff01ec69da>] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [<ffffffff8080ce0a>] drm_ioctl_kernel+0x8e/0xdc [<ffffffff8080d016>] drm_ioctl+0x1be/0x3e0 [<ffffffff802bec3e>] __riscv_sys_ioctl+0xba/0xc4 [<ffffffff80d858b2>] do_trap_ecall_u+0x23e/0x3f4 [<ffffffff80d92288>] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*(). Cc: stable@vger.kernel.org Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Fixes: 4bc736f890ce ("drm/imagination: vm: make use of GPUVM's drm_exec helper") Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260714073641.1935075-1-zhengxingda@iscas.ac.cn Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-20ovpn: fix use after free in unlock_ovpn()Marco Baffo1-2/+3
unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer->release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body. Fixes: 80747caef33d ("ovpn: introduce the ovpn_peer object") Signed-off-by: Marco Baffo <marco@mandelbit.com> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
2026-07-20ovpn: hold peer before scheduling keepalive workShuvam Pandey1-2/+4
ovpn_peer_keepalive_send() passes its peer reference to ovpn_xmit_special(), which ultimately drops it. The keepalive scheduler currently queues the work first and takes the reference only after schedule_work() reports that the work was queued. Once schedule_work() queues the item, another CPU may run the worker before the caller gets to ovpn_peer_hold(). In that case the worker can consume a reference that was not acquired for it, corrupting the peer lifetime accounting. Take the peer reference before queueing the work and drop it again when the work was already pending. Fixes: 3ecfd9349f40 ("ovpn: implement keepalive mechanism") Cc: stable@vger.kernel.org Signed-off-by: Shuvam Pandey <shuvampandey1@gmail.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
2026-07-20ovpn: fix peer refcount leak in TCP error pathsPavitra Jha1-2/+4
When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&peer->tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window: CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error): ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2 schedule_work() <- queued schedule_work() <- NO-OP (work already pending) ovpn_tcp_peer_del_work runs: ovpn_peer_del() ovpn_peer_put() <- refcnt+1 <- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point. Fixes: a6a5e87b3ee4 ("ovpn: avoid sleep in atomic context in TCP RX error path") Cc: stable@vger.kernel.org Signed-off-by: Pavitra Jha <jhapavitra98@gmail.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
2026-07-20ovpn: avoid putting unrelated P2P peer on socket releaseQing Ming1-1/+0
ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn->peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed access sites include ovpn_peer_remove(), ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn(). Fix this by returning from the socket mismatch branch without putting the peer. Fixes: f6226ae7a0cd ("ovpn: introduce the ovpn_socket object") Signed-off-by: Qing Ming <a0yami@mailbox.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
2026-07-20RDMA/ionic: Add robust udata compatibility checks to all uapi verbsAbhijit Gangurde2-0/+39
Enable the robust udata contract by setting uverbs_robust_udata and adding proper input validation and output handling to all verbs that accept struct ib_udata. For verbs with no driver request or response struct, add ib_no_udata_io(). For create_ah, which already responds with ionic_ah_resp, add the missing input validation via ib_is_udata_in_empty(). Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com> Link: https://patch.msgid.link/20260717092345.2533564-1-abhijit.gangurde@amd.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-20RDMA/mana_ib: Adopt robust udataKonstantin Taranov6-14/+83
Enable the uverbs robust udata interface in mana_ib by setting uverbs_robust_udata and converting the driver to the new udata handling model. Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-20RDMA/mlx5: use kmalloc() for UMR translation buffersLeon Romanovsky2-10/+9
mlx5r_umr_alloc_xlt() allocates physically contiguous scratch buffers that are DMA mapped only in the DMA_TO_DEVICE direction. kmalloc() provides the required contiguity and alignment for these sizes while preserving the existing GFP allocation policy. The emergency translation buffer has the same requirements. Convert all of these UMR buffers to kmalloc() and release them with kfree(), which no longer requires the caller to supply the allocation order. Link: https://patch.msgid.link/20260715-get_pages-to-kmalloc-v1-4-b0b7fce288be@nvidia.com Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
2026-07-20RDMA/usnic: use kmalloc() for the page pointer arrayLeon Romanovsky1-2/+2
usnic_uiom_get_pages() uses a page-sized array of struct page pointers as temporary storage for pin_user_pages(). Nothing requires the array to come directly from the page allocator. Use kmalloc() for the array and kfree() after the pinning loop. Link: https://patch.msgid.link/20260715-get_pages-to-kmalloc-v1-3-b0b7fce288be@nvidia.com Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
2026-07-20RDMA/mlx4: use kzalloc() for the fast registration page listLeon Romanovsky1-3/+3
mlx4_alloc_priv_pages() allocates a zeroed, page-sized buffer for a DMA-to-device page list. kmalloc() provides the required physical contiguity, and a PAGE_SIZE allocation retains the alignment needed to keep the list within one page. Use kzalloc() for the buffer and kfree() on the error and teardown paths. Link: https://patch.msgid.link/20260715-get_pages-to-kmalloc-v1-2-b0b7fce288be@nvidia.com Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
2026-07-20RDMA/cxgb4: use kmalloc() for the PBL address arrayLeon Romanovsky1-2/+2
c4iw_reg_user_mr() allocates a page-sized temporary array of DMA addresses while programming a PBL. The array has no page-specific requirements, so allocate it with kmalloc() and release it with kfree(). This avoids the casts required by the page allocator and lets the free operation derive the allocation size from the object. Link: https://patch.msgid.link/20260715-get_pages-to-kmalloc-v1-1-b0b7fce288be@nvidia.com Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
2026-07-20RDMA/irdma: Enable uverbs_robust_udata compliance flagJacob Moroni1-0/+1
The irdma driver has been audited to confirm that: 1. Methods which do not accept udata input perform an explicit check for no (or zero value) input. 2. Methods which do accept input perform the correct validation to ensure that additional udata beyond the kernel's current ABI definition is zero, and to enforce the required minimum length. 3. Methods which do not return udata responses use the proper helper. Signed-off-by: Jacob Moroni <jmoroni@google.com> Link: https://patch.msgid.link/20260713171257.3131493-7-jmoroni@google.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-20RDMA/irdma: Fix legacy i40iw compat check in create_qpJacob Moroni1-2/+6
The irdma driver maintains backward compatibility with the legacy i40iw userspace provider by checking the length of the user response buffer in irdma_create_qp. Previously, the check relied on udata->outlen < sizeof(uresp). That is technically okay since there have only ever been two sizes for the resp struct (legacy and current). However, it would be a problem if the resp struct is ever expanded in the future because it would end up triggering the legacy fallback path for non-legacy irdma providers that just haven't moved over to the newer expanded struct yet. Fix this by explicitly checking for the exact legacy resp size. Signed-off-by: Jacob Moroni <jmoroni@google.com> Link: https://patch.msgid.link/20260713171257.3131493-6-jmoroni@google.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
generated by cgit (git 2.54.0.dirty) at 2026-09-30 04:47:31 +0000