dma_resv_wait_timeout() returns a positive 'remaining jiffies' value
on success, 0 on timeout, and -errno on failure.
panfrost_ioctl_wait_bo() returns this 'long' result from an int-typed
ioctl handler, so positive values reach userspace as bogus errors.
Explicitly set ret to 0 on the success path.
Fixes: f3ba91228e ("drm/panfrost: Add initial panfrost driver")
Cc: stable@vger.kernel.org
Signed-off-by: Gyeyoung Baek <gye976@gmail.com>
Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/fe33f82fded7be1c18e2e0eb2db451d5a738cf39.1776581974.git.gye976@gmail.com
Signed-off-by: Steven Price <steven.price@arm.com>
dma_resv_wait_timeout() returns a positive 'remaining jiffies' value
on success, 0 on timeout, and -errno on failure.
rocket_ioctl_prep_bo() returns this 'long' result from an int-typed
ioctl handler, so positive values reach userspace as bogus errors.
Explicitly set ret to 0 on the success path.
Fixes: 525ad89dd9 ("accel/rocket: Add IOCTLs for synchronizing memory accesses")
Cc: stable@vger.kernel.org
Signed-off-by: Gyeyoung Baek <gye976@gmail.com>
Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Link: https://patch.msgid.link/c0ebf83b345721701b22d8f5bc41c52c0ecf5e16.1776581974.git.gye976@gmail.com
Signed-off-by: Steven Price <steven.price@arm.com>
It is a typo to use trcvmidcctlr0 to save and restore TRCVMIDCCTLR1.
Use trcvmidcctlr1 instead.
Fixes: f5bd523690 ("coresight: etm4x: Convert all register accesses")
Signed-off-by: Leo Yan <leo.yan@arm.com>
Reviewed-by: James Clark <james.clark@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20260408-arm_cs_fix_trcvmidcctlr1_typo-v1-1-6a5695363b46@arm.com
System register ETMs and ETE are unlikely to be preserved on CPU power
down. The ETE DT binding also never documented
"arm,coresight-loses-context-with-cpu" so nobody would have legitimately
been able to use that binding to fix it and ACPI has no such binding at
all.
Fix it by hard coding the setting for sysreg ETMs (ETE is always sysreg)
or ACPI boots. Use a local variable when setting up save_state so that
it's immune to concurrent probing when devices have different
configurations which is an issue with modifying the global.
This fixes the following error when using Coresight with ACPI on the FVP
which supports CPU PM:
coresight ete0: External agent took claim tag
WARNING: drivers/hwtracing/coresight/coresight-core.c:248 at coresight_disclaim_device_unlocked+0xe0/0xe8, CPU#0: perf/117
Fixes: 35e1c9163e ("coresight: ete: Add support for ETE tracing")
Signed-off-by: James Clark <james.clark@linaro.org>
Reviewed-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20260505-james-cs-ete-pm_save_enable-v3-1-485d21dd79b8@linaro.org
When specifying a 2GB AUX buffer, the ETR driver ends up allocating only
a 1MB buffer instead:
# echo 'file coresight-tmc-etr.c +p' > \
/sys/kernel/debug/dynamic_debug/control
# perf record -e cs_etm/@tmc_etr0,timestamp=0/u -C 0 -m ,2G -- test
coresight tmc_etr0: allocated buffer of size 1024KB in mode 0
The page index is an 'int' type, and shifting it by PAGE_SHIFT overflows
when the resulting value exceeds 2GB. This produces a negative value,
causing the driver to fall back to the minimum buffer size (1MB).
Cast the page index to a wider type to accommodate large buffer sizes.
Also fix a similar issue in the buffer offset calculation.
Reported-by: Michiel van Tol <michiel.vantol@arm.com>
Fixes: 99443ea19e ("coresight: Add generic TMC sg table framework")
Fixes: eebe8dbd86 ("coresight: tmc: Decouple the perf buffer allocation from sysfs mode")
Signed-off-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20260217-arm_coresight_fix_big_buffer_size-v1-1-774e893d8e3f@arm.com
The backlight driver depends on the MFD cgbc-core driver, which already
depends on X86. The explicit X86 dependency for the backlight driver is
redundant and can be safely removed.
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Link: https://patch.msgid.link/20260427-backlight-cgbc-remove-x86-dependency-v2-1-da9f2375a34a@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
The qdss_cti function is initialized twice in the nord_functions array.
Remove the duplicate entry.
Fixes: c24dd0826f ("pinctrl: qcom: add the TLMM driver for the Nord platforms")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605061633.BJLI5voT-lkp@intel.com/
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Recent changes to add shrinker support introduced a use after free
vulnerability.
When a BO is evicted from the shrinker callback, all its CPU and GPU
mappings are invalidated. It can happen that another GPU mapping is
created for the BO after the eviction. Because of the new GPU mapping,
BO will be added back to one of the reclaim list but the state of
corresponding vm_bo will not be changed.
If vm_bo remains in evicted state and shrinker callback is invoked
again then the new GPU mapping won't be invalidated. As a result the
backing pages, which were acquired on the creation of new GPU mapping,
can get reclaimed and reused whilst they are still mapped to the GPU.
To prevent the use after free possibility, this commit removes the
evicted check for vm_bo so that all GPU mappings are checked for
invalidation.
v2:
- Update comment and add a newline in
panthor_vm_evict_bo_mappings_locked().
Fixes: fb42964e2a ("drm/panthor: Add a GEM shrinker")
Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Akash Goel <akash.goel@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/20260413080253.1288157-1-akash.goel@arm.com
__pkvm_host_donate_guest() flips the host stage-2 PTE for the
donated page to a non-valid annotation via
host_stage2_set_owner_metadata_locked() and then calls
kvm_pgtable_stage2_map() to install the matching guest stage-2
mapping. The map's return value is wrapped in WARN_ON() and
otherwise discarded, asserting that the call cannot fail.
WARN_ON() at nVHE EL2 panics, so this assertion is only correct
if the call genuinely cannot fail. kvm_pgtable_stage2_map() can
fail with -ENOMEM even at PAGE_SIZE granularity: the donate path
verifies PKVM_NOPAGE for the guest IPA before the map, so the
walker must allocate fresh page-table pages from the vcpu
memcache, and the host controls the vcpu memcache via the topup
interface. An under-provisioned donation request would otherwise
turn a recoverable -ENOMEM into a fatal hyp panic.
Bound the worst-case walker allocation alongside the existing
__host_check_page_state_range() / __guest_check_page_state_range()
pre-checks, using the helper introduced for host->guest share. If
the vcpu memcache holds fewer pages than kvm_mmu_cache_min_pages(),
return -ENOMEM before any state mutation.
Fixes: 1e579adca1 ("KVM: arm64: Introduce __pkvm_host_donate_guest()")
Assisted-by: Gemini:gemini-3.1-pro review-prompts
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260501112149.2824881-7-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
__pkvm_host_share_guest() ends with kvm_pgtable_stage2_map() to
install the guest stage-2 mapping, after a forward pass that mutates
the host vmemmap (sets PKVM_PAGE_SHARED_OWNED and increments
host_share_guest_count) for every page in the range. The map's
return value is wrapped in WARN_ON() and otherwise discarded,
asserting that the call cannot fail.
WARN_ON() at nVHE EL2 panics, so this assertion is only correct if
the call genuinely cannot fail. kvm_pgtable_stage2_map() can fail
with -ENOMEM when the stage-2 walker exhausts the caller's
memcache, and the host controls the vcpu memcache via the topup
interface, so an under-provisioned share request would otherwise
turn a recoverable -ENOMEM into a fatal hyp panic.
Bound the worst-case walker allocation in the existing pre-check
pass so that kvm_pgtable_stage2_map() cannot fail at the call
site, using kvm_mmu_cache_min_pages() -- the same bound host EL1
uses for its own stage-2 maps. If the vcpu memcache holds fewer
pages, return -ENOMEM before any state mutation.
Fixes: d0bd3e6570 ("KVM: arm64: Introduce __pkvm_host_share_guest()")
Assisted-by: Gemini:gemini-3.1-pro review-prompts
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260501112149.2824881-6-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
The hypercall handlers call pkvm_refill_memcache() to top up the
hyp_vcpu memcache before invoking __pkvm_host_{share,donate}_guest().
pkvm_ownership_selftest invokes those functions directly with a
static selftest_vcpu that has an empty memcache.
Seed selftest_vcpu's memcache from the prepopulated selftest
pages, leaving the remainder for selftest_vm.pool. Required by
the memcache-sufficiency pre-check added in the following
patches.
Assisted-by: Gemini:gemini-3.1-pro review-prompts
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260501112149.2824881-5-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
__deactivate_fgt() declares its first parameter as "htcxt" but the body
references "hctxt". The parameter is unused; the macro silently captures
"hctxt" from the enclosing scope. Both existing callers
(__deactivate_traps_hfgxtr() and __deactivate_traps_ich_hfgxtr()) happen
to define a local "struct kvm_cpu_context *hctxt", so the macro works
by coincidence.
A future caller without an "hctxt" local in scope, or naming it
differently, would compile but bind to the wrong context. Align the
parameter name with the sibling __activate_fgt() macro.
The "vcpu" parameter remains unused in the body, kept for API symmetry
with __activate_fgt() (which uses it).
Fixes: f5a5a406b4 ("KVM: arm64: Propagate and handle Fine-Grained UNDEF bits")
Assisted-by: Gemini:gemini-3.1-pro review-prompts
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260501112149.2824881-4-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
On VHE, __hyp_call_panic() unconditionally calls __deactivate_traps(vcpu)
on the vcpu pointer read from host_ctxt->__hyp_running_vcpu. That pointer
is cleared after every guest exit (and is never set when no guest is
running), so an unexpected EL2 exception landing in _guest_exit_panic,
e.g. via the el2t*_invalid / el2h_irq_invalid vectors - reaches this
function with vcpu == NULL. __deactivate_traps() then dereferences vcpu
via ___deactivate_traps() -> vserror_state_is_nested() -> vcpu_has_nv()
-> vcpu->arch.features, faulting inside the panic handler and obscuring
the original failure.
The nVHE counterpart (hyp_panic() in arch/arm64/kvm/hyp/nvhe/switch.c)
already guards its vcpu-using cleanup with "if (vcpu)"; mirror that
here. sysreg_restore_host_state_vhe() does not depend on vcpu and
continues to run unconditionally, preserving panic forensics. The
trailing panic("...VCPU:%p", vcpu) prints "(null)" safely via printk's
%p handling.
Fixes: 6a0259ed29 ("KVM: arm64: Remove hyp_panic arguments")
Assisted-by: Gemini:gemini-3.1-pro review-prompts
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260501112149.2824881-3-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
SCTLR_EL2.EIS and SCTLR_EL2.EOS control whether exception entry and
exit at EL2 are Context Synchronisation Events (CSEs). Per ARM DDI
0487 M.b D24.2.175 (p. D24-9754):
- !FEAT_ExS: the bit is RES1, so the entry/exit is unconditionally
a CSE.
- FEAT_ExS: the reset value is architecturally UNKNOWN; software
must set the bit to make the entry/exit a CSE.
INIT_SCTLR_EL2_MMU_ON in arch/arm64/include/asm/sysreg.h sets neither
bit. KVM/arm64 hot paths rely on ERET from EL2 being a CSE, and on
synchronous EL1->EL2 entry being a CSE, to elide explicit ISBs after
MSRs to context-switching system registers (HCR_EL2, ZCR_EL2,
ptrauth keys, etc.). On FEAT_ExS hardware those reliances are not
architecturally backed unless EOS=1 (and, for entry, EIS=1).
Until commit 0a35bd285f ("arm64: Convert SCTLR_EL2 to sysreg
infrastructure"), SCTLR_EL2_RES1 was a hand-rolled mask that
included BIT(11) (EOS) and BIT(22) (EIS), so INIT_SCTLR_EL2_MMU_ON
was setting both unconditionally. The conversion made
SCTLR_EL2_RES1 auto-generated; because the sysreg tooling only
models unconditionally-RES1 fields and EIS/EOS are RES1 only when
FEAT_ExS is absent, the auto-generated mask is UL(0). The seven
other bits dropped from the old mask (positions 4, 5, 16, 18, 23,
28, 29) are unconditionally RES1 in the E2H=0 SCTLR_EL2 layout per
DDI 0487 M.b D24.2.175, so dropping them is harmless. EIS and EOS
are the only bits whose semantics changed for FEAT_ExS hardware
and where the kernel relies on the value being 1.
Make the guarantee explicit: include SCTLR_ELx_EIS | SCTLR_ELx_EOS in
INIT_SCTLR_EL2_MMU_ON so that EL2 exception entry and exit are
unconditionally CSEs regardless of whether FEAT_ExS is implemented.
This matches the pairing in arch/arm64/kvm/config.c which treats EIS
and EOS together as RES1 under !FEAT_ExS.
Fixes: 0a35bd285f ("arm64: Convert SCTLR_EL2 to sysreg infrastructure")
Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com>
Assisted-by: Gemini:gemini-3.1-pro review-prompts
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260501112149.2824881-2-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
This driver faults when intel vsec driver is unbound from PCI driver
interface. For example:
echo 0000:00:03.1 > /sys/bus/pci/drivers/intel_vsec/unbind
This is caused by accessing plr->dbgfs_dir after vsec_tpmi driver is
removed. Here vsec_tpmi driver is the parent. On unbind, the parent
device remove callback is called first which here will remove debugfs
interface. Hence plr->dbgfs_dir is no longer valid.
Register notifier for TPMI_CORE_EXIT and make this pointer to NULL,
so that debugfs_remove_recursive() is not called with bad plr->dbgfs_dir
pointer.
After notifier is returned the vsec_tpmi driver will call remove debugfs
by calling debugfs_remove_recursive().
Fixes: 811f67c516 ("platform/x86/intel/tpmi: Add new auxiliary driver for performance limits")
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Stable@vger.kernel.org
Link: https://patch.msgid.link/20260430151103.1549733-4-srinivas.pandruvada@linux.intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
In some cases a driver using services of vsec_tpmi driver requires some
processing before vsec_tpmi exits. For example a children using debugfs
can't use debugfs as this will be deleted by the vsec_tpmi driver.
This is the case when unbind using PCI driver interface. In this case
the remove callback of vsec_tpmi driver is called first, then remove
callback of its children.
Add support of blocking chain notifiers support. Notify on successful probe
and before clean up in the remove callback.
Fixes: 811f67c516 ("platform/x86/intel/tpmi: Add new auxiliary driver for performance limits")
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Stable@vger.kernel.org
Link: https://patch.msgid.link/20260430151103.1549733-3-srinivas.pandruvada@linux.intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
It is possible that the driver handling device is enumerated before
registering debugfs. If the driver wants to access debugfs by calling
tpmi_get_debugfs_dir(), this will return error in this case.
Hence register debugfs before creating devices.
Fixes: 811f67c516 ("platform/x86/intel/tpmi: Add new auxiliary driver for performance limits")
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Stable@vger.kernel.org
Link: https://patch.msgid.link/20260430151103.1549733-2-srinivas.pandruvada@linux.intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
PSCI specification defines the SYSTEM_SUSPEND feature which enables the
firmware to implement the suspend to RAM (S2RAM) functionality by
transitioning the system to a deeper low power state. When the system
enters such state, the power to the peripheral devices might be removed. So
the respective device drivers must prepare for the possible removal of the
power by performing actions such as shutting down or resetting the device
in their system suspend callbacks.
The Linux PM framework allows the platform drivers to convey this info to
device drivers by calling the pm_set_suspend_via_firmware() and
pm_set_resume_via_firmware() APIs.
Hence, if the PSCI firmware supports SYSTEM_SUSPEND feature, call the above
mentioned APIs in the psci_system_suspend_begin() and
psci_system_suspend_enter() callbacks.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
[mani: reworded the description to be more elaborative]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
QCOM_RPMH and QCOM_RPMHPD can be build only as modules when
QCOM_COMMAND_DB is module itself.
Fixes: 1c25ca9bb5 ("ARM: multi_v7_defconfig: enable more Qualcomm drivers")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Drop all redundant entries:
1. SERIAL_BCM63XX is default=y for ARCH_BCMBCA.
2. USB_GPIO_VBUS is conflicting with enabled USB_CONN_GPIO since
commit 0ce0f9d078 ("usb: phy: phy-gpio-vbus-usb: Add device tree
probing").
3. SND_HDA_CODEC_REALTEK_LIB is selected by other codecs,
SND_HDA_CODEC_ALC269 by default.
4. SND_PXA_SOC_SSP depends on ARCH_PXA which is only for multi v5.
5. SND_SOC_ROCKCHIP is gone since commit cae3cc435d ("ASoC: rockchip:
Standardize ASoC menu") and can be simply dropped without effect.
6. SND_SOC_TLV320AIC32X4 is selected by SND_SOC_TLV320AIC32X4_I2C/SPI.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
CONFIG_SND_ATMEL_SOC is gone since commit 4f30f84feb ("ASoC: atmel:
Standardize ASoC menu") and can be simply dropped without effect.
No impact on include/generated/autoconf.h.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Acked-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
I2C_DESIGNWARE_PLATFORM is default=y via I2C_DESIGNWARE_CORE, which is
enabled. No impact on include/generated/autoconf.h.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Acked-by: Dinh Nguyen <dinguyen@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Only re-shuffle entries to match savedefconfig, without removing any
symbols. This helps in reviewing defconfig when comparing with
savedefconfig and looking for obsolete symbols. No impact on
include/generated/autoconf.h.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
in the pinctrl subsystem augmenting Kconfig and defconfigs in
sequence.
This is just the defconfig changes.
This should be pulled into the SoC defconfigs branch for 7.2
to avoid conflicts in linux-next.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAmn7k1AACgkQQRCzN7AZ
XXPJ/A//c5y1EJD3YZp5brIeZDNZKC84YLCVjkyAiLsPmBkGqP2LCaGnQfi8VVez
Ojn1vrDSPKef/uqeRrCnen29zAwCz8cpErFyiZysRap1PMsxYYHtAvP4yh8ZU0Ei
zlzvxRuaDvkkbt1n2vdfMamuBOvDlPetnFe0u5NEZstv2NvDYK5oEwHdVhFIKVbU
fQI9yPS7L7b+REJrQpbF/Ou3hvv8SKUFVn4xYLzld459rSDwkImYhyoHGMTQ9juN
3ymW6TQS4u9x0/yUYmwCZpbxvg1D4RmvyfHB0O855xuLR02sBo5iTrU3pBzCStxI
F/SegoNO969cHfk/RddfVHF1QjsdaylVTksbmV4XSGt1Mbsj+uONzm0NSOT33CIm
veqxd34Jr/HDh/uEoMCDAx15ZFg4lKtqUyLkXaVlLUkmbuyCXunil/yx7r+d7Ejc
Sud51KwJsAAJJoIf1lsPbYg7SMvXPyQ0TLQzb01MaNvzwWemqEJ12bPVO0mk3VkV
cfC/woWD0vnqudW7A8y4sHoAt9G/mQ4l9PwqiDboGHxDqR+2YQoM1+eXHaKPWfr4
ehE1Gh7K9bx9mAC83Y3C/3ycPetsmMNrymgwEryQCHng70+10hGGASn2bi6VlTCI
dPx7v72XxXAsy+kMEQ3fl18bG05VPJeK/HfxT0s254Aksy7k/O4=
=xC8l
-----END PGP SIGNATURE-----
Merge tag 'v7.2-qcom-pinctrl-defconfigs' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl into soc/defconfig
This is a split-off of a patch that was applied in two parts
in the pinctrl subsystem augmenting Kconfig and defconfigs in
sequence.
This is just the defconfig changes.
This should be pulled into the SoC defconfigs branch for 7.2
to avoid conflicts in linux-next.
* tag 'v7.2-qcom-pinctrl-defconfigs' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: qcom: Make important drivers default (2)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Development of Linux kernel progressed over last 10 years and it is easy
to generate now initramfs for building own kernel, e.g. with Yocto or
mkosi. Therefore for a few years of reviews on mailing lists, all new
options enabled in arm64 defconfig were with assumption of having
initramfs which can load bare minimum of modules to mount filesystem
from network or disk. Basically network driver as built-in is not
anymore essential to boot the system, so switch almost all Ethernet
drivers to modules to save on kernel image size.
Similarly 9P network filesystem for QEMU, especially that testing kernel
unuder QEMU does not have any size or build process constraints and can
use initramfs with -initrd argument. Note that having network drivers
does not break NFS root, because whatever loading method, e.g. TFTP,
which brought the kernel image can bring also the initramfs with network
adapters (and I have been using such method for years for my Samsung
boards).
Notable exceptions / diff explanations:
1. Mark I2C as built-in, used by CONFIG_IGB as a module.
2. CONFIG_BCM4908_ENET and CONFIG_BCMASP appear in the diff, because
they were default=y (via ARCH_BCMBCA or ARCH_BCM_IPROC).
3. CONFIG_HNS3_HCLGE and CONFIG_HNS3_ENET are removed, because they are
default=m.
Moving code to modules has positive impact on kernel image size, thus
boot time of all users not using above drivers and ability to flash
fixed-size boot partitions.
Old Image size: 41.2 MiB (Image.gz: 14.8 MiB)
New Image size: 39.1 MiB (Image.gz: 13.8 MiB)
bloat-o-meter of vmlinux:
add/remove: 3/6972 grow/shrink: 6/45 up/down: 66659/-2333659 (-2267000)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20260429-defconfig-v2-5-e4ed4186028b@oss.qualcomm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Make going through `make menuconfig` easier by disabling the unused
Ethernet vendor menu options, where no actual driver for given vendor is
selected.
Impact checked with comparing old and new autoconf.h:
diff ... | grep '^-' | grep -v CONFIG_NET_VENDOR
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20260429-defconfig-v2-4-e4ed4186028b@oss.qualcomm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Drop all options which are either defaults or selected by other drivers:
1. IMX Pinctrl drivers are defaults for this ARCH.
2. RP1 is selected by MISC_RP1.
3. I2C_DESIGNWARE_PLATFORM is default with I2C_DESIGNWARE_CORE.
4. DRM_SAMSUNG_DSIM is selected by DRM_EXYNOS_DSI.
5. SUN6I, SUN8I and Renesas DRM drivers have defaults.
6. SND_SOC_ROCKCHIP does not exist.
7. Several ASoC drivers are selected by other main sound switches.
8. USB_CDNS3_IMX is default with USB_CDNS3.
9. IPQ_APSS_5018 never existed.
No impact on include/generated/autoconf.h.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20260429-defconfig-v2-3-e4ed4186028b@oss.qualcomm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Drop all options which are ineffective now, because they depend on
disabled IP_NF_IPTABLES_LEGACY or IP6_NF_IPTABLES_LEGACY. No impact on
include/generated/autoconf.h.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20260429-defconfig-v2-2-e4ed4186028b@oss.qualcomm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Only re-shuffle entries to match savedefconfig, without removing any
symbols. This helps in reviewing defconfig when comparing with
savedefconfig and looking for obsolete symbols. No impact on
include/generated/autoconf.h.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20260429-defconfig-v2-1-e4ed4186028b@oss.qualcomm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A few old machines have not been converted away from the old-style
gpiolib interfaces. Make these select the new CONFIG_GPIOLIB_LEGACY
symbol so the code still works where it is needed but can be left
out otherwise.
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20260428162757.540823-1-arnd@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
After a GPU reset the HWSP is zeroed, so previously completed
requests appear incomplete. If such a request is picked up during
reset_rewind() and marked guilty, i915_request_set_error_once()
returns early (fence already signaled), leaving fence.error without
a fatal error code. The subsequent __i915_request_skip() then hits:
```
GEM_BUG_ON(!fatal_error(rq->fence.error))
```
Fixes a kernel BUG observed on Sandy Bridge (Gen6) during
heartbeat-triggered engine resets.
```
kernel BUG at drivers/gpu/drm/i915/i915_request.c:556!
RIP: __i915_request_skip+0x15e/0x1d0 [i915]
...
__i915_request_reset+0x212/0xa70 [i915]
reset_rewind+0xe4/0x280 [i915]
intel_gt_reset+0x30d/0x5b0 [i915]
heartbeat+0x516/0x530 [i915]
```
Guard __i915_request_skip() with i915_request_signaled(), if the
fence is already signaled, the ring content is committed and there
is nothing left to skip.
Fixes: 36e191f064 ("drm/i915: Apply i915_request_skip() on submission")
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/13729
Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
Cc: stable@vger.kernel.org # v5.7+
Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/fe76921d35b6ae85aa651822726d0d9815aa5362.1776339012.git.sebastian.brzezinka@intel.com
The Agilex5 SoC provides RGMII TX/RX clock delay compensation through
its integrated I/O hardware. Using phy-mode = "rgmii-id" instructs the
MAC driver to additionally insert internal TX/RX delays, resulting in
double delay being applied and causing Ethernet link timing issues.
Change phy-mode to "rgmii" across all Agilex5 device tree files to
reflect that the clock delay is already handled by the hardware and
no additional software-inserted delay is required. Add an inline comment
to satisfy checkpatch and document the hardware-provided delay.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
The updates fix several robustness issues in the FF-A bus and core driver,
mostly around notification handling, RxTx buffer sizing, firmware-provided
bounds, and cleanup paths.
The notification fixes make per-CPU notification work truly per-CPU, avoid
running per-vCPU notification handling from IPI context, keep RX buffer
release serialized under rx_lock, validate framework notification payload
layout before copying from the shared RX buffer, and avoid dereferencing
notifier entries after they may have been unregistered.
The remaining fixes reject FF-A drivers without an ID table at registration
time, avoid freeing an unallocated RX buffer after allocation failure,
unregister the FF-A v1.0 bus notifier on teardown, bound register-based
PARTITION_INFO_GET descriptor copies, align the stored RxTx buffer size with
the size mapped to firmware, and fix sched-recv callback partition lookup on
the circular partition list.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmn7maMACgkQAEG6vDF+
4pgGAw/+OClw1JVGF0i6nTBGxuQAmZQGtuM4HZEnxloFsxPLWFqoRGsIJ4MMLUnb
xCClPqi7LoNCZKlSD3WxXcuVmAEO9J7gto8NzHzY+Mdn4ByhMfvlu6DZtLYLLwy2
33HCoW++VW1iXomZ3yBnyZmA8U6jMNTs7z5pE420iArxy4HfA2BfrRpBx+L4dA5n
wEj4unrab9GHo43rFAkQsTb2rwGh40H3w41mD7TnHzwwsvTbFgIfNiHo0kneTGBa
P8eXFj3b5tNBv9sOccjqZQKeANDmwmm2ncxtWs6dFgOi3QXI+UyQQvylnG8C96DM
tSjNmwCcw7wWvjpK0wmVHrL0jh9pkpPHNJ6qIxlNKPkd+96L8vWo7uNbel76qLjU
vP1y1RCjdtHeJs9xYW9BYUNoNTDOWKXWGivzIe4P3PevD4q+imqTMBPe6lpF0+50
4bIa//A2cm6iuPGL9ySgwJ9jEoXY5QAZD5TjGg3pcW2UFyL5F1Wg8yFQBHuU8XP2
N7nlmntzLRRNn8pjjAJckQWKUlH+7hiPoQJMiBGuIWLevlkjt2SZCMbG2RL7Ymbd
9+wlb8dUlNTMfdrBLZZMym1cp07gh/myDo0iSaK7WY5tvYJj0O/lI7DXf69adgH2
GFFd30JAo+CMXJuTadOZf5+3aUYzwCl1l4I8axT1gqyNC8A4/Bs=
=iFfw
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmn8gG4ACgkQmmx57+YA
GNnsPQ/+Ij20fAnnPF0eyvYj1vPn4LGWHZneD8DzPcms77QF5oQZnkbC/HIecAsC
6SqSSPtwuYVDQuPtEoALFh5RtZt0UF5lQgd8Xgk9Mi+cVLEVJkb8OJkNKXofC45Z
FaW7apHcgZOMadmWATJHhniLnlYCodDP3LQq8n2CvfmL/RAXdvPrDnba6eiwj9nP
iONVEsyFRHhpZAQvz/JgpsApRj2K6+XT9SR2yVAUQk+CNkA+QbvMI8QAA5YCiR2H
GFFfi1AAzM41m5PQcWqFKUtgr3d8QIlDIvlaoGa7fofmxSSBgxXpC/BGLe+HlUrW
ZGBuicbBg4eZIw2AX0zbBJxH/Zpg1Z7EuDM5EGEmyrMjyi35pDEouoFdTmIT1lr7
MwC2odJlcS1KYYyHQDleVHKrcUwnwa4Pw1lgganhnnADb4Rv1ziqHhoTP1qxNbbu
qqXXD1+go9WYxh9CiLA2HbjiTGzNLm9DMOoIc+/cEwLAD8H3Xa7oK4Yplee6P9d7
utaTR3NwT7B5XQ2mbh7LZjBKz4W1DfMN+XrmI3y19bL30ufmOi8K6uKYrbLxRUAc
gH9nO4BVCUXgCqTimfI0ORsA6ZoCXcNNpc491ANX15S9vmbN4rRKc6hNfriYEycw
k5XIzT5H9v7Qu3OvkM4cTwP4iv0l6UFAB6u1+17I+2kG9/CJJZs=
=wjLn
-----END PGP SIGNATURE-----
Merge tag 'ffa-fixes-7.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
Arm FF-A fixes for v7.1
The updates fix several robustness issues in the FF-A bus and core driver,
mostly around notification handling, RxTx buffer sizing, firmware-provided
bounds, and cleanup paths.
The notification fixes make per-CPU notification work truly per-CPU, avoid
running per-vCPU notification handling from IPI context, keep RX buffer
release serialized under rx_lock, validate framework notification payload
layout before copying from the shared RX buffer, and avoid dereferencing
notifier entries after they may have been unregistered.
The remaining fixes reject FF-A drivers without an ID table at registration
time, avoid freeing an unallocated RX buffer after allocation failure,
unregister the FF-A v1.0 bus notifier on teardown, bound register-based
PARTITION_INFO_GET descriptor copies, align the stored RxTx buffer size with
the size mapped to firmware, and fix sched-recv callback partition lookup on
the circular partition list.
* tag 'ffa-fixes-7.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_ffa: Fix sched-recv callback partition lookup
firmware: arm_ffa: Snapshot notifier callbacks under lock
firmware: arm_ffa: Align RxTx buffer size before mapping
firmware: arm_ffa: Validate framework notification message layout
firmware: arm_ffa: Keep framework RX release under lock
firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies
firmware: arm_ffa: Unregister bus notifier on teardown for FF-A v1.0
firmware: arm_ffa: Fix per-vcpu self notifications handling in workqueue
firmware: arm_ffa: Avoid collapsing NPI work from different CPUs
firmware: arm_ffa: Skip free_pages on RX buffer alloc failure
firmware: arm_ffa: Check for NULL FF-A ID table while driver registration
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
No dedicated maintainers are shown for Realtek SoC pin controllers,
except pinctrl subsystem maintainer, which means reduced review and
impression of abandoned drivers. Pin controller drivers are essential
part of an SoC, so in case of lack of dedicated entry at least cover it
by the SoC platform maintainers.
Acked-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Link: https://lore.kernel.org/r/20260505105838.1014771-2-eleanor.lin@realtek.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Starting with commit bdb249fce9 ("ARM: integrator: read counter using
syscon/regmap"), intcp_init_early calls syscon_regmap_lookup_by_compatible
which in turn calls of_syscon_register. This function allocates memory.
Since the memory management code has not been initialized at that time,
the call always fails. It either returns -ENOMEM or crashes as follows.
Unable to handle kernel NULL pointer dereference at virtual address 0000000c when read
[0000000c] *pgd=00000000
Internal error: Oops: 5 [#1] ARM
Modules linked in:
CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.15.0-rc5-00026-g5fcc9bf84ee5 #1 PREEMPT
Hardware name: ARM Integrator/CP (Device Tree)
PC is at __kmalloc_cache_noprof+0xec/0x39c
LR is at __kmalloc_cache_noprof+0x34/0x39c
...
Call trace:
__kmalloc_cache_noprof from of_syscon_register+0x7c/0x310
of_syscon_register from device_node_get_regmap+0xa4/0xb0
device_node_get_regmap from intcp_init_early+0xc/0x40
intcp_init_early from start_kernel+0x60/0x688
start_kernel from 0x0
The crash is seen due to a dereferenced pointer which is not supposed to be
NULL but is NULL if the memory management subsystem has not been
initialized. The crash is not seen with all versions of gcc. Some versions
such as gcc 9.x apparently do not dereference the pointer, presumably if
tracing is disabled. The problem has been reproduced with gcc 10.x, 11.x,
and 13.x. Either case, if the crash is not seen, the call to
syscon_regmap_lookup_by_compatible returns -ENOMEM, and
sched_clock_register is never called.
Fix the problem by moving the early initialization code into the standard
machine initialization code.
Fixes: bdb249fce9 ("ARM: integrator: read counter using syscon/regmap")
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/20250518164118.3859567-1-linux@roeck-us.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20260505-integrator-fixes-v1-1-56ab9aac59db@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
On Samsung Galaxy Book 5 (SAM0430), the keyboard backlight, microphone
mute, and camera block hotkeys do not generate i8042 scancodes.
Instead they arrive as ACPI notifications 0x7d, 0x6e, and 0x6f
respectively, all of which previously fell through to the default
"unknown" warning in galaxybook_acpi_notify().
Add handling for these three events:
- 0x7d (Fn+F9, keyboard backlight): schedule the existing
kbd_backlight_hotkey_work which cycles brightness.
- 0x6e (Fn+F10, microphone mute): emit KEY_MICMUTE via the driver's
input device.
- 0x6f (Fn+F11, camera block): if block_recording is active use the
existing block_recording_hotkey_work; otherwise emit a toggle of
SW_CAMERA_LENS_COVER via the driver's input device on models where
the block_recording ACPI feature is not supported.
Tested on Samsung Galaxy Book 5 (SAM0430) and Samsung Galaxy Book2 Pro
(SAM0429).
Signed-off-by: Ayaan Mirza Baig <ayaanmirzabaig85@gmail.com>
Co-developed-by: Joshua Grisham <josh@joshuagrisham.com>
Signed-off-by: Joshua Grisham <josh@joshuagrisham.com>
Link: https://patch.msgid.link/20260418004613.93981-3-ayaanmirzabaig85@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Rename the camera_lens_cover_switch input device to a generic input
device which can be used for multiple input events. Move input device
allocation and registration into a dedicated galaxybook_input_init()
helper which is called early in probe so that the device is available
to all features.
No functional change.
Signed-off-by: Ayaan Mirza Baig <ayaanmirzabaig85@gmail.com>
Link: https://patch.msgid.link/20260418004613.93981-2-ayaanmirzabaig85@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The USB MIDI 2.0 endpoint parser has the same descriptor walking
pattern as the legacy MIDI parser. It validates bLength against
bNumGrpTrmBlock before reading baAssoGrpTrmBlkID[], but not against the
remaining bytes in the endpoint-extra scan.
A malformed device can therefore make later baAssoGrpTrmBlkID[] reads
consume bytes past the walked descriptor.
Reject zero-length and overlong descriptors while walking endpoint
extras.
Fixes: ff49d1df79 ("ALSA: usb-audio: USB MIDI 2.0 UMP support")
Cc: stable@vger.kernel.org
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Link: https://patch.msgid.link/20260507-usb-midi-endpoint-scan-bounds-v1-2-329d7348160e@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_usbmidi_get_ms_info() validates the internal MIDIStreaming endpoint
descriptor size before using baAssocJackID[], but the descriptor walker can
still return a class-specific endpoint descriptor whose bLength exceeds the
remaining bytes in the endpoint-extra scan.
That leaves later flexible-array reads bounded by bLength, but not by the
remaining bytes in the endpoint-extra scan.
Stop walking when bLength is zero or
extends past the remaining endpoint-extra scan.
Fixes: 5c6cd7021a ("ALSA: usb-audio: Fix case when USB MIDI interface has more than one extra endpoint descriptor")
Cc: stable@vger.kernel.org
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Link: https://patch.msgid.link/20260507-usb-midi-endpoint-scan-bounds-v1-1-329d7348160e@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent OSS runtime->state locking cleanup converted the OSS I/O
paths to use snd_pcm_get_state(), but a few ioctl-side checks in
pcm_native.c still sample runtime->state directly: the prepare
pre-checks, the early drain open-state check, and the common
snd_pcm_kernel_ioctl() disconnected check.
Use snd_pcm_get_state() for those remaining samples. In
snd_pcm_pre_prepare(), keep a single state snapshot and reuse it for
both the OPEN/DISCONNECTED check and the running-state test.
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
Link: https://patch.msgid.link/20260507011944.2897240-1-zzzccc427@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some Lenovo Yoga Pro 9 16IMH9 units carry codec SSID 17aa:38d5 instead
of 17aa:38d6, which was added in commit 56722cfbb7 ("ALSA: hda/realtek:
Add codec SSID quirk for Lenovo Yoga Pro 9 16IMH9"). The corresponding
firmware blob TAS2XXX38D5.bin already ships in linux-firmware, and the
hardware is otherwise identical: same PCI subsystem ID 17aa:3811 shared
with the Legion S7 15IMH05, same TI TAS2781 amplifiers behind ACPI HID
TIAS2781, same ALC287_FIXUP_TAS2781_I2C requirement.
Add a second HDA_CODEC_QUIRK entry directly above the existing 17aa:38d6
entry so both variants resolve to the correct fixup. Reported and
verified on hardware by GitHub user 0xEthamin.
Link: https://github.com/ramonvanraaij/yoga9-tas2781-hda/issues/1
Signed-off-by: Rámon van Raaij <ramon@vanraaij.eu>
Link: https://patch.msgid.link/20260506183118.patch1-ramon@vanraaij.eu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Both nfc_hci_recv_from_llc() and nci_hci_data_received_cb() read
packet->header from skb->data at function entry without first checking
that the buffer holds at least one byte. A malicious NFC peer can send
a 0-byte HCP frame that passes through the SHDLC layer and reaches
these functions, causing an out-of-bounds heap read of packet->header.
The same 0-byte frame, if queued as a non-final fragment, also causes
the reassembly loop to underflow msg_len to UINT_MAX, triggering
skb_over_panic() when the reassembled skb is written.
Fix this by adding a pskb_may_pull() check at the entry of each
function before packet->header is first accessed. The existing
pskb_may_pull() checks before the reassembled hcp_skb is cast to
struct hcp_packet remain in place to guard the 2-byte HCP message
header.
Fixes: 8b8d2e08bf ("NFC: HCI support")
Fixes: 11f54f2286 ("NFC: nci: Add HCI over NCI protocol support")
Cc: stable@vger.kernel.org
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Ashutosh Desai <ashutoshdesai993@gmail.com>
Link: https://patch.msgid.link/20260505170712.96560-1-ashutoshdesai993@gmail.com
Signed-off-by: David Heidelberg <david@ixit.cz>
Buggy .show hook will get just 1 line of dmesg:
fill_read_buffer: ext4_attr_show+0x0/0x600 returned bad count
It may or may not oops later in some unrelated process.
But buggy .show hook most likely is corrupting random memory past sysfs
buffer therefore deserving more. WARN, make it more visible and let
QA machines panic earlier.
Also, delete useless cast -- "count" is >=0 at this point.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/3cc3e8c6-c6e8-4625-a88f-f5708b935dab@p183
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
