In iwl_mvm_wowlan_store_wake_pkt(), packet_len was initialized from
notif->wake_packet_length before the explicit check that len >=
sizeof(*notif).
Move the assignment of packet_len to after the size check so that
notif->wake_packet_length is only accessed once the payload length
has been validated.
Fixes: 219ed58fed ("wifi: iwlwifi: mvm: Add support for wowlan wake packet notification")
Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.99d5cf85a528.Ic4aa736011d4fe88e0cd19723d1d48bb24642198@changeid
iwl_pnvm_complete_fn() casts pkt->data directly to
struct iwl_pnvm_init_complete_ntfy and reads the status field
without first verifying that the firmware notification payload
is large enough to contain that structure.
Add a WARN_ON_ONCE check against sizeof(*pnvm_ntf) and return
early without reading uninitialised memory if the payload is too
short.
Fixes: b3e4c0f34c ("iwlwifi: move PNVM implementation to common code")
Assisted-by: GitHubCopilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.7f2a669e5c75.I00465dcfcbccb250ae9af2d9bb305e24de1ba394@changeid
The expression list[*size++] increments the pointer 'size'
rather than the u8 value it points to (operator precedence: ++
binds to the pointer before the dereference). As a result the
block-list entry is written at the correct index but *size is
never incremented, so the caller's count stays at zero and
subsequent calls overwrite slot 0 every time.
Change to list[(*size)++] so that the value pointed to by size
is incremented after use as the array index.
Fixes: 5f4656610e ("wifi: iwlwifi: extend TAS_CONFIG cmd support for v5")
Assisted-by: GitHubCopilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.d2cd92242582.Ife4140a4e27be2a1cd9f886c5a9b376ce182a019@changeid
The SMEM parsers cast firmware response payloads directly to shared
memory configuration structures. A short response can leave fields
outside the received payload while the driver still dereferences them.
Check the response payload length before reading the base fields in
both parser variants. Require the full legacy extended layout before
reading internal TX FIFO data. Valid responses keep the same parsed
values.
Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.fbdb0016a91d.I5f6c6e04589a24a233559191170ccb43372dee63@changeid
The SAR GEO command response is cast to
iwl_geo_tx_power_profiles_resp without verifying the payload length.
A malformed or unexpected firmware response can lead to reading an
invalid structure layout.
Add an explicit size check before accessing the response data and
return -EIO when the payload size is wrong.
Fixes: f604324eef ("iwlwifi: remove iwl_validate_sar_geo_profile() export")
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.7e749b7d374a.I4ef54548bff6c6e7c7a57bee771ac12508aad677@changeid
TX_CMD parsing uses frame_count to walk status entries and then
read the trailing SCD SSN. Make the minimum-length check follow
that exact runtime layout calculation before parsing the payload.
For new TX API, reject TX_CMD responses with frame_count != 1 and
warn/return in the aggregation handler to document that aggregated
accounting is expected via BA notifications.
Assisted-by: GitHubCopilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.0474ee89bab9.I84f151aabecb8921b587da092f29f78c47128f0f@changeid
We need to expect more channels on devices that support UNII-9.
Since iwl_ext_nvm_channels and iwl_uhb_nvm_channels are just a prefix
of iwl_unii9_nvm_channels just use iwl_unii9_nvm_channels and modify the
number of channels if the device does not support UNII-9 channels.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.473f48e6135d.I0e93cda753558aa4d9e3efcdd52cbc2eb9302c4a@changeid
Validate txq_id from TX response notification before passing to
iwl_trans_reclaim(). Other reclaim paths in this file perform this
check to prevent out-of-bounds access on malformed notifications.
Assisted-by: GitHubCopilot:claude-haiku-4.5
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715215523.b938c2dcf08d.I8a88ec359e229f1c41ac9c49fd9ce28a2b62b274@changeid
When a channel context is unassigned, there is a path to cleanup the FW
state in case of NON MLO connection: remove the link and add it again.
However, when the transport is dead, e.g., during device removal etc.,
this flow will fail and as a result the mld_vif->link[0] would be set to
NULL. Later, when the interface is removed, iwl_mld_remove_link() would
warn as the link is NULL.
Fix this by not doing the cleanup when the device is dead.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715220243.89a0c44a72a3.I45cca8b84a25943d5771199af6b0155dbac77b58@changeid
Make sure we don't end-up with a num_frags = 0 situation.
For that, check that the required size is not 0 and put a checker on
num_frags as well.
Fixes: 14124b2578 ("iwlwifi: dbg_ini: implement monitor allocation flow")
Assisted-by: GitHubCopilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715220243.60121deecf2c.Iebc891c95a7bd1b2a093b0bb88532db446a758ee@changeid
When calculating the SAP data length, the code subtracts
sizeof(*ethhdr) from len. If the SAP data header indicates a length
that is shorter than ethernet header length, this will result in an
unsigned underflow which will lead to a kernel panic when trying to
put the data into the SKB. Fix it by skipping a message if the
indicated length is too short.
In addition, if the message type is not SAP_MSG_DATA_PACKET or skb
allocation fails, the loop skips to the next message but without
reading the message payload. This may result in reading the payload
as the next message header, which will lead to errors in parsing the
next messages. Fix it by skipping the message payload as well.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715220243.f66b10736047.I4a1dde517c36561d41358dd82a5cec8b6c886c14@changeid
In iwl_mld_handle_wake_pkt_notif(), expected_size was initialized from
notif->wake_packet_length before the IWL_FW_CHECK that validates the
payload covers sizeof(*notif).
Move the assignment of expected_size to after the size check so that
notif->wake_packet_length is only accessed once the payload length has
been validated.
Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715220243.94c526d2c66e.I065a19a9dcc7f45a7457667c0f625fcd2c7bf6b6@changeid
There is a new UHB extension bitmap that is part of the LARI
configuration, which needs to be sent to the FW - also frozen ones.
But in frozen FWs we cannot increase the version of an API, since the
driver assumes a specific version, depending on the core number.
In case of a (new) FW that expects the new version and a (old) driver
that doesn't support that new version, the driver will send a default
old version, causing a fw assert about its bad size.
To mitigate this, there is a special command which will be supported
only on those frozen FWs. Old drivers will simply not support/send it,
and new driver will send it if supported by fw.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715220243.551f40ee2de3.I3e32a5d5c9aa13cbb0e599bef630cdb8e3b031c4@changeid
New MCC response versions expose puncturing support directly in the
regulatory capability flags. Propagate that information from NVM MCC
parsing to MLD MCC handling and fall back to legacy FM/WH MCC-specific
policy when puncturing status is unknown.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715220243.47d1389fa134.I5c7921d6e3c065e3962c5927991498c2d277fd8f@changeid
iwl_mvm_frob_txf_key_iter() tracks the last matched byte position
in loop variable 'i'. When a full key match is found (match ==
keylen), 'i' points at the last byte of the matched key. The
memset start offset should therefore be i + 1 - keylen, not
i - keylen; the current code zeroes one byte before the match
and leaves the final key byte un-sanitised.
Fixes: 12d60c1efc ("iwlwifi: mvm: scrub key material in firmware dumps")
Assisted-by: GitHubCopilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715220243.355998ec4fbe.I40f3427657b897e911bdf4ebf8e494745508d126@changeid
When a firmware notification version is not in the handler's
size table, iwl_mld_notif_is_valid() falls back to comparing
against the last known structure size but the comparison is
wrong: 'return size < last_known_size' returns true (accept)
for undersized payloads and false (reject) for payloads that
are large enough.
Instead of trying to accept notifications that are large enough,
just refuse the notification. We shouldn't ever get a
notification that is longer than what we expect.
Assisted-by: GitHubCopilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715220243.e0b91efe689d.I7d7604be6819da263e9091370892e6b6f4c57913@changeid
The loop counter 'count' was declared as u8 while num_pc is u32.
If firmware advertises more than 255 PC entries the counter wraps
back to zero and the loop never terminates potentially causing an
infinite loop or reading past the allocated pc_data array.
Change the declaration to u32 to match num_pc.
Fixes: 2b69d242e2 ("wifi: iwlwifi: fw: print PC register value instead of address")
Assisted-by: GitHubCopilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715220243.a61c65f34e87.Ie5f1a7ca43e0cc5a0ddc8305b0448ddffc09cd18@changeid
The loop should print all bandwidths, the extra * results in
calculating the wrong ARRAY_SIZE() here (of the array inside
the per-bandwidth, not the per-bandwidth array.) Fix that,
and also clarify the array variable assignment.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260715220243.5e1d3448bfca.I6919627382d46605b41b0c6a6f34deedfd45523c@changeid
The bfd_boolean type was gone and converted to the standard bool type
but we have some old code that uses the type. It caused a failure in
the build test.
util/libbfd.c: In function 'slurp_symtab':
util/libbfd.c:94:9: error: unknown type name 'bfd_boolean'
94 | bfd_boolean dynamic = FALSE;
| ^~~~~~~~~~~
util/libbfd.c:94:31: error: 'FALSE' undeclared (first use in this function)
94 | bfd_boolean dynamic = FALSE;
| ^~~~~
util/libbfd.c:94:31: note: each undeclared identifier is reported only once for each function it appears in
util/libbfd.c:102:27: error: 'TRUE' undeclared (first use in this function)
102 | dynamic = TRUE;
| ^~~~
Fix it with standard bool type and constants.
Reviewed-by: Ian Rogers <irogers@google.com>
Link: https://sourceware.org/pipermail/binutils-cvs/2021-March/056231.html
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
The loop for processing syscall args in augment_raw_syscalls has a
history of breaking with Clang updates, see e.g. commit 013eb043f3
("perf trace: Fix BPF loading failure (-E2BIG)") from Clang 15 to 16.
Now, a similar thing happened between Clang 21 and 22. While the issue
is mitigated on the main line by a recent verifier update, it remains
broken on the 6.12 and 6.18 stable branches:
[linux-6.18.y]# sudo perf trace true
libbpf: prog 'sys_enter': BPF program load failed: -E2BIG
libbpf: prog 'sys_enter': -- BEGIN PROG LOAD LOG --
[...]
BPF program is too large. Processed 1000001 insn
processed 1000001 insns (limit 1000000) max_states_per_insn 40 total_states 37941 peak_states 232 mark_read 0
-- END PROG LOAD LOG --
libbpf: prog 'sys_enter': failed to load: -E2BIG
libbpf: failed to load object 'augmented_raw_syscalls_bpf'
libbpf: failed to load BPF skeleton 'augmented_raw_syscalls_bpf': -E2BIG
Error: failed to get syscall or beauty map fd
[...]
The reason is that the loop is quite complex and the BPF verifier often
struggles to prove that it terminates.
Fix the issue by replacing the standard for loop with the bpf_for macro,
which uses a numeric BPF iterator. This should prevent future breakages
of this kind since the verifier has a much easier job proving that the
loop terminates.
Small adjustments were necessary for the loop to make it work. The main
problem is that the verifier sometimes has problems with bpf_for loops
that use a carry-over state, such as the `payload_offset` and `output`
vars here, since the verifier tries to track their values too precisely
and cannot prove loop convergence. To resolve the issue, we (1)
explicitly recompute `payload_offset` in every iteration and (2) use a
trick with adding a global zero to `output` to help the verifier forget
its precise state and use a range instead.
Finally, to keep backwards compatibility with older kernel versions that
don't have bpf_for (i.e. numeric iterators), fall back to standard loop.
Signed-off-by: Viktor Malik <vmalik@redhat.com>
Cc: stable@vger.kernel.org
Suggested-by: Andrii Nakryiko <andrii@kernel.org>
Fixes: a68fd6a6cd ("perf trace: Collect augmented data using BPF")
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
The BPF program in augmented_raw_syscalls uses a for loop to iterate all
syscall arguments. The loop body is quite complex and often poses
problems for the BPF verifier. As a preparation step for addressing this
issue, factor out the loop body into a separate function.
Signed-off-by: Viktor Malik <vmalik@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Add a wrapper for getting a reference to the NS head.
This would be used in scenarios when we know that getting a reference
would not fail.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
Signed-off-by: John Garry <john.g.garry@oracle.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
To simply check the number of output lines with and without the option.
Before this series, it failed like below:
$ perf test -v 125
125: perf stat --bpf-counters --for-each-cgroup test:
---- start ----
test child forked, pid 1941516
Normal output has 22 lines, but it now has 54
---- end(-1) ----
125: perf stat --bpf-counters --for-each-cgroup test : FAILED!
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
In the evsel, there's an internal struct to put fields need copy when
the evsel is cloned. This is purely to make it easier track those
fields even if it sometimes failed to do so. :)
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
IIUC bpf_fd and bpf_obj fields are not used anymore. It seems like
leftover from 3d6dfae889 ("perf parse-events: Remove BPF event
support").
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
The --bpf-counters and --for-each-cgroup options use a set of shared
events among the given cgroups rather than adding events for each cgroup
respectively. It only uses cgroup-ID to compare and calculate the
result. So no need to open and keep FDs for cgroups in BPF mode.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
If the realloc for fda->entries succeeds but the realloc for fda->priv
fails, the error path frees the newly allocated entries.
However, fda->entries is neither updated to point to the new entries block
nor cleared to NULL. If realloc moved the allocation to a new block, the
old fda->entries pointer is now freed memory.
When fdarray__exit() is later called to clean up, it executes
free(fda->entries), which would trigger a double-free on that old pointer.
Reported-by: Sashiko Review <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-perf-users/20260710200150.11FE71F00A3A@smtp.kernel.org
Reviewed-by: Ian Rogers <irogers@google.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
starfive_pcie_host_init() acquires the PHY, clocks/resets, and an
optional regulator in sequence, but does not correctly unwind these
resources when a later step fails.
If starfive_pcie_clk_rst_init() fails after the PHY has already been
successfully enabled, the function returns directly without disabling
the PHY, leaking it and leaving it powered.
If regulator_enable() fails for the optional vpcie3v3 regulator, the
failure is only logged; the function falls through and returns
success, leaving the driver believing the regulator is enabled while
continuing to configure PCIe hardware that may be unpowered. This
also leaves the clocks and PHY enabled with nothing to clean them up.
Disable the PHY on the clk/reset failure path, and disable the
clocks/resets and PHY, then return the error, if the regulator fails
to enable.
Build-tested and boot-tested on StarFive VisionFive 2 v1.2A
Fixes: 05a75df418 ("PCI: starfive: Use regulator APIs to control the 3v3 power supply of PCIe slots")
Fixes: 39b91eb40c ("PCI: starfive: Add JH7110 PCIe controller")
Signed-off-by: Ali Tariq <alitariq45892@gmail.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260716102053.185276-1-alitariq45892@gmail.com
Signed-off-by: Carlos Maiolino <cem@kernel.org>
-----BEGIN PGP SIGNATURE-----
iJUEABMJAB0WIQSmtYVZ/MfVMGUq1GNcsMJ8RxYuYwUCalj/DwAKCRBcsMJ8RxYu
Y3UMAYCrPzc41SGZdOkoxvO5g3BwGISXYCiCCIFFvnnDXztuiJytgZ+VPH+C7X4J
tlGjRXUBfi8PcoePIbDfPXxay+T/g5Pz29ADyl2UAkxPYRRWeYYxKTyCTBvBdUXS
lMCnv0pSPg==
=Hcay
-----END PGP SIGNATURE-----
Merge tag 'xfs-fixes-7.2-rc4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
Pull xfs fixes from Carlos Maiolino:
"This contains mostly a series of bug fixes found by different LLM
models"
* tag 'xfs-fixes-7.2-rc4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: (21 commits)
xfs: don't zap bmbt forks if they are MAXLEVELS tall
xfs: clamp timestamp nanoseconds correctly
xfs: fully check the parent handle when it points to the rootdir
xfs: handle non-inode owners for rtrmap record checking
xfs: fix off-by-one error when calling xchk_xref_has_rt_owner
xfs: set xfarray killable sort correctly
xfs: grab rtrmap btree when checking rgsuper
xfs: write the rg superblock when fixing it
xfs: use the rt version of the cow staging checker
xfs: use rtrefcount btree cursor in xchk_xref_is_rt_cow_staging
xfs: don't wrap around quota ids in dqiterate
xfs: move cow_replace_mapping to xfs_bmap_util.c
xfs: make cow repair somewhat flaky when debugging knob enabled
xfs: don't replace the wrong part of the cow fork
xfs: resample the data fork mapping after cycling ILOCK
xfs: fix null pointer dereference in tracepoint
xfs: use xfs_csn_t for xlog_cil_push_now() push_seq parameter
xfs: tie zoned sysfs lifetime to zone info
xfs: fail recovery on a committed log item with no regions
xfs: splice unsorted log items back to the transaction after the loop
...
- Fix sanity checks for ztailpacking tail pclusters to avoid
false corruption reports
- Use more informative s_id for file-backed mounts
- Hide the meaningless "cache_strategy=" mount option on plain
(uncompressed) filesystems
- Remove the unneeded erofs_is_ishare_inode() helper
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEQ0A6bDUS9Y+83NPFUXZn5Zlu5qoFAmpY47QRHHhpYW5nQGtl
cm5lbC5vcmcACgkQUXZn5Zlu5qoPzQ//Rjcp/c9wAegDZG+Y5qwquAqIVtiO582a
DlimqGXP/+XIOx8IqhIzqXx9R1GpIjIT6xpWrqhXr+Xcics2W48CE6G/0xg+Mh0h
GDtf836rolHeeqJNG6gmEaWik3C91MDbZY3hwYJIQmS+gTVUBx1hwWvi22hauPZI
qGJ9wVEKlv6yAOC5KORx5hQidMeNblAI+z9MWWV/lm5Zf4w1Ve2wp0298utBzcnR
xVk6r+sEarqnHZ6O/ncM72S0OmyD/PrdfJkHUqF3RPjMVI4PSnlfQD+1IOGAmmy+
m0JnBUUylWI7c3Lg3e7RjgVT7Qbytn3iBp9UeMUNXsWHy6bG3zbuTmYTuWXckL79
YMOHdRpZ33scOts7+7D0hsp63dDErs1ALyNv9a8Mw2pO1ITxCs9D+omhzjwwL2Y/
XchOFuLMCBqfgigwGOvKOX5IBwdLpQxCMJVZsBGfpWNXcE0YqGJ77XaatoUt5gdu
FdUP7zwFTjTiMhXlBSPCYm1fID/e0+rqcEeztSsvIGlu0DClrXItCYTlhThSU3nr
eu/YmMZw/6vsXI8cPSX1Elkr52Q6bp2jlL2mCfvSEKgRTmNXrxgGWHLVsEb9i1aa
lON+F5B/lDMt9hV7RL7eINRG1Ov7ADm1wyt14oVSBSgh2dx2PzAUL2YpWsmpVsCz
K8HBfmru4lg=
=3hh+
-----END PGP SIGNATURE-----
Merge tag 'erofs-for-7.2-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs
Pull erofs fixes from Gao Xiang:
- Fix sanity checks for ztailpacking tail pclusters to avoid
false corruption reports
- Use more informative s_id for file-backed mounts
- Hide the meaningless "cache_strategy=" mount option on plain
(uncompressed) filesystems
- Remove the unneeded erofs_is_ishare_inode() helper
* tag 'erofs-for-7.2-rc4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs:
erofs: hide "cache_strategy=" for plain filesystems
erofs: get rid of erofs_is_ishare_inode() helper
erofs: relax sanity check for tail pclusters due to ztailpacking
erofs: use more informative s_id for file-backed mounts
- Make cpufreq_update_pressure() use cpuinfo.max_freq as the default
reference frequency when arch_scale_freq_ref() returns 0 to allow
the scheduler to still take CPU frequency caps into account in those
cases (Rafael Wysocki)
- Use the HWP guaranteed performance level as the full capacity
performance in intel_pstate on hybrid systems when turbo frequencies
are not allowed to be used to make scale-invariance work as expected
in those cases (Rafael Wysocki)
-----BEGIN PGP SIGNATURE-----
iQFGBAABCAAwFiEEcM8Aw/RY0dgsiRUR7l+9nS/U47UFAmpY4CcSHHJqd0Byand5
c29ja2kubmV0AAoJEO5fvZ0v1OO1nTgH+QHXf2KIXDZBVn3iroiZbdPF9h6iBfnh
XKn1wahWy/d41leF1g19yQL5UD+dztKRnn4Ek5ihMT7doAgqpCYAR//s/e5IDHai
FVoFhyiNoxlbm1A7qbq4F1X4tlnU1mfIj676W+SKa7Hn1KMnRL9kerJGsS6oq6cH
L56snK9LOxSYDXDjYqBZQtg7W3GVoqw0pjWdKMVU3faTHTl4SuTAfoHFNHSd2dMh
oZd9xKPWxGPOwKctmrWb4MpwW2eMJNrclWnpixPhAfXRPWm5qvZm/jtroSZ2y5pN
nHrd2jTHiINnaiqMzZgvydVIy5XgXx9Ero7+/Syw2NBEcHQ1KcocQTg=
=dMjb
-----END PGP SIGNATURE-----
Merge tag 'pm-7.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael Wysocki:
"These fix two cpufreq issues, one in the intel_pstate driver and one
in the core:
- Make cpufreq_update_pressure() use cpuinfo.max_freq as the default
reference frequency when arch_scale_freq_ref() returns 0 to allow
the scheduler to still take CPU frequency caps into account in
those cases (Rafael Wysocki)
- Use the HWP guaranteed performance level as the full capacity
performance in intel_pstate on hybrid systems when turbo
frequencies are not allowed to be used to make scale-invariance
work as expected in those cases (Rafael Wysocki)"
* tag 'pm-7.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq
cpufreq: intel_pstate: Set non-turbo capacity to HWP_GUARANTEED_PERF()
spi_geni_init() reuses 'ret' after it has already been set by the
runtime PM acquire check earlier in the function. When an invalid
protocol is later detected, the function returns this stale 'ret'
value instead of a proper error code, so it can end up returning 0
(or some other non-error value) even though the protocol check
failed.
Fix this by returning -EINVAL directly on both invalid-proto paths.
Fixes: d8e9ea989a ("spi: qcom-geni: Fix missing error check on pm_runtime_get_sync()")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <error27@gmail.com>
Closes: https://lore.kernel.org/r/202607122241.qzP3QAXF-lkp@intel.com/
Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Acked-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>
Link: https://patch.msgid.link/20260716-fix_return_error_code-v1-1-3295003aacd5@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
- imx: Assign child domains for imx93 to prevent power off when in use
- imx: Fix i.MX8MP power up sequences
- mediatek: Fix possible nullptr in HWV cleanup/on-check
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAmpY0fEQHHVsZmhAa2Vy
bmVsLm9yZwAKCRD+JoQlc1iMKZtVD/9E1rSTcAK/tHKIt2Ng8hLPZgWib8z8JjDj
OU8i5kmMJHnymEcnWYllMFkAjJicVauo3kbNyMZqtU+TxDTqrZgUjWzO9Pu7OGMy
ZA4YBBGnDQP7faRrfTDB31EVuwxziTq9kcctpqkYEiSWnN1+ZOpAF2vqfHvOEek0
v82Wu6fSorZXeXYjH49sEEAW8qiel8u3gA6ctHv2MFXD7fqK6POTTWpHdvnBI0rp
CRP4imWH6tTKC2FVMw5rLel+JzHU6y658Qg/gd2AVtG+8nQH/LX7gu0M2tg0E/Sq
TTMbRSnS93+rlTyWSkJgIyQnlSGkYddHJEGDFxaUxfln2LiLCNeXgbPcJvAQIEji
GH5AeJEoz6XtkVBsv4Aga+EG1O154YKQ8/jnGGM2q+cFrBItfeiNcSwhexHoNMnw
hIcKW7lvmEUM/N/GS3wsBBJBftAz8bmeSITEqrVzscIZRVjWlElYrtAuG+cmKagc
jamfwQDJ2WfzJz9lolSMbKobo6bJEzmxqvP6cN1iVgHkdm22BxE29q2/XACilzH4
ASMHbkxd3gAR2P4HrzhxX6jn0SI7YxJCfrI1aYD6yKKp7MA2sdWBm3IVTREHZhP2
5FiArPQced3tjdtlDfbXLan1AmEiZ49o31fEUssylA4D7Z1G8qKB7RXXphDayRM/
ATNSav1EzQ==
=tWH8
-----END PGP SIGNATURE-----
Merge tag 'pmdomain-v7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm
Pull pmdomain fixes from Ulf Hansson:
"imx:
- Assign child domains for imx93 to prevent power off when in use
- Fix i.MX8MP power up sequences
mediatek:
- Fix possible nullptr in HWV cleanup/on-check"
* tag 'pmdomain-v7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm:
pmdomain: mediatek: Fix possible nullptr KP in HWV cleanup/on-check
pmdomain: imx: Fix i.MX8MP VC8000E power up sequence
pmdomain: imx: Fix i.MX8MP power notifier
pmdomain: imx93-blk-ctrl: Extract PHY as shared domain for DSI/CSI
dt-bindings: power: imx93: Add MIPI PHY power domain
Compare the sampled clock values instead of their addresses. Comparing
addresses leaves the samples unsorted, preventing the code from discarding
the minimum and maximum samples.
Fixes: 1a53924792 ("drm/i915/selftests: Measure CS_TIMESTAMP")
Signed-off-by: Emre Cecanpunar <emreleno@gmail.com>
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
Link: https://lore.kernel.org/r/20260714220430.238433-1-emreleno@gmail.com
(cherry picked from commit 682ea2d28d)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The UV/Y plane DDB entriess are never cleared on
sk_wm_plane_disable_noatomic() and can leave stale DDB state
for NV12 planes on pre-Gen11 devices
Fixes: d34b59d5ba ("drm/i915: Add skl_wm_plane_disable_noatomic()")
Assisted-by: Copilot:claude-sonnet-4.6
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260615203355.218578-2-vinod.govindapillai@intel.com
(cherry picked from commit 60f68a6ba2)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The LTC3676_IRQSTAT_* bit definitions do not match the IRQSTAT
(Interrupt Request Status) register layout documented in Table 15
of the LTC3676/LTC3676-1 datasheet:
bit 0 - Pushbutton Status Active
bit 1 - Hard Reset Occurred
bit 2 - PGOOD Timeout Occurred
bit 3 - Undervoltage Warning
bit 4 - Undervoltage Standby (Fault) Occurred
bit 5 - Overtemperature Warning
bit 6 - Overtemperature Standby (Fault) Occurred
bit 7 - Reserved
The driver instead defines these starting at bit 3, one bit higher
than the datasheet specifies, which causes ltc3676_regulator_isr()
to check the wrong status bits and misreport (or miss) PGOOD
timeout, undervoltage and thermal warning/fault conditions.
Fix the bit offsets to match the datasheet.
Fixes: 37b918a034 ("regulator: Add LTC3676 support")
Cc: stable@vger.kernel.org
Signed-off-by: Abhishek Ojha <Abhishek.ojha@savoirfairelinux.com>
Link: https://patch.msgid.link/20260715170408.295552-1-Abhishek.ojha@savoirfairelinux.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When ksmbd validates a compound (chained) SMB2 request,
ksmbd_smb2_check_message() reads pdu->StructureSize2 without first
checking that the compound element is large enough to contain it.
StructureSize2 is a 2-byte field at offset 64
(__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element.
The compound-walking logic only guarantees that a full 64-byte SMB2
header is present for the trailing element: when NextCommand is 0, len is
reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A
remote client can craft a compound request whose last element has exactly
64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte
past the receive buffer, producing a slab-out-of-bounds read.
BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402)
Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14
The buggy address is located 172 bytes inside of allocated 173-byte region
Workqueue: ksmbd-io handle_ksmbd_work
Call Trace:
...
kasan_report (mm/kasan/report.c:595)
ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402)
handle_ksmbd_work (fs/smb/server/server.c:119)
process_one_work (kernel/workqueue.c:3314)
worker_thread (kernel/workqueue.c:3397)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
Reject any compound element that is too small to hold StructureSize2
before dereferencing it.
Fixes: e2f34481b2 ("cifsd: add server-side procedures for SMB3")
Reported-by: AutonomousCodeSecurity@microsoft.com
Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
smb3_preauth_hash_rsp() computes the SMB3.1.1 preauth integrity hash on
the response path. For a binding SESSION_SETUP it looks up the
per-connection preauth_session and reads its Preauth_HashValue.
smb2_sess_setup() frees that preauth_session under ksmbd_conn_lock().
Two SMB2 requests on one connection can run concurrently, so an unlocked
lookup and hash can use a preauth_session after another worker frees it.
Take ksmbd_conn_lock() before selecting conn->binding and hold it across
the selected preauth hash lookup and update. This preserves the existing
hash selection while preventing the lookup-to-use lifetime race.
Fixes: 1c5daa2ea9 ("ksmbd: handle channel binding with a different user")
Signed-off-by: Gil Portnoy <dddhkts1@gmail.com>
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
ksmbd_sessions_deregister() removes a connection's channels from other
sessions' channel lists only while conn->binding is still set:
if (conn->binding) {
hash_for_each_safe(sessions_table, ...)
ksmbd_chann_del(conn, sess);
}
conn->binding is a transient flag: it is cleared once a binding
SESSION_SETUP completes, and also by a subsequent non-binding
SESSION_SETUP on the same connection (a reauthentication on a bound
channel, or a new SessionId==0 setup). A connection that has bound a
channel into another session's ksmbd_chann_list and then clears
conn->binding leaves that channel behind when it disconnects: the
channel, whose chann->conn points at the now freed struct ksmbd_conn,
stays on the owner session's list.
When the owning connection later tears down, the second loop
dereferences the stale channel:
xa_for_each(&sess->ksmbd_chann_list, chann_id, chann)
if (chann->conn != conn)
ksmbd_conn_set_exiting(chann->conn); /* freed */
which is a use-after-free write into the freed ksmbd_conn (the same
stale channel is also walked by show_proc_session() through /proc). The
session is leaked as well, because its channel list never empties.
Remove the conn->binding gate so a connection always removes its
channels from every session on teardown.
Fixes: faf8578c77 ("ksmbd: find bound sessions during reauthentication")
Signed-off-by: Gil Portnoy <dddhkts1@gmail.com>
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Commit 4b706360ff ("ksmbd: fix multichannel binding and enforce channel
limit") moved the binding-path session key out of the session-wide
sess->sess_key (CIFS_KEY_SIZE = 40) into a new per-channel buffer, and
sized both that buffer and the on-stack copy used during binding with
SMB2_NTLMV2_SESSKEY_SIZE (16):
struct channel {
char sess_key[SMB2_NTLMV2_SESSKEY_SIZE]; /* 16 */
...
};
ntlm_authenticate() / krb5_authenticate():
char channel_key[SMB2_NTLMV2_SESSKEY_SIZE] = {}; /* 16 */
char *auth_key = conn->binding ? channel_key : sess->sess_key;
The two writers that fill this destination still bound the copy length
against CIFS_KEY_SIZE (40), not against the 16-byte buffer:
ksmbd_decode_ntlmssp_auth_blob() (NTLM key exchange):
if (sess_key_len > CIFS_KEY_SIZE) /* 40 */
return -EINVAL;
arc4_crypt(ctx_arc4, sess_key,
(char *)authblob + sess_key_off, sess_key_len);
ksmbd_krb5_authenticate():
if (resp->session_key_len > sizeof(sess->sess_key)) /* 40 */
...
memcpy(sess_key, resp->payload, resp->session_key_len);
On a binding SESSION_SETUP, auth_key points at the 16-byte channel_key,
so a client that supplies an NTLM EncryptedRandomSessionKey of up to 40
bytes (with NTLMSSP_NEGOTIATE_KEY_EXCH), or a Kerberos ticket whose
session key is longer than 16 bytes (a normal AES256 key is 32), writes
past the 16-byte stack buffer -- up to a 24-byte kernel stack overflow.
KASAN reports it as a stack-out-of-bounds write in arc4_crypt() called
from ksmbd_decode_ntlmssp_auth_blob().
The destinations must be able to hold the full session key the length
checks already permit. Size the per-channel key buffer and the two
on-stack channel_key buffers with CIFS_KEY_SIZE, matching sess->sess_key.
Fixes: 4b706360ff ("ksmbd: fix multichannel binding and enforce channel limit")
Signed-off-by: Gil Portnoy <dddhkts1@gmail.com>
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
On an SMB2 SET_INFO(FileRenameInformation) whose target names an alternate
data stream, smb2_rename() obtains a formatted stream-name string from
ksmbd_vfs_xattr_stream_name(), which allocates it with kasprintf() and
returns it through an out-param:
rc = ksmbd_vfs_xattr_stream_name(stream_name, &xattr_stream_name, ...);
if (rc)
goto out;
rc = ksmbd_vfs_setxattr(..., xattr_stream_name, ...);
if (rc < 0) {
...
goto out;
}
goto out;
xattr_stream_name is declared inside the alternate-data-stream block, but
the out: label is outside that block and frees only new_name, so it cannot
release xattr_stream_name. ksmbd_vfs_setxattr() takes a const char * and
only reads the name, so it does not take ownership either. Both the
setxattr-failure and the success path therefore leak the kasprintf()'d
string. An authenticated client with a writable share can leak kernel
memory on every stream rename, exhausting kernel memory over time.
Free xattr_stream_name after its use, before the block's goto out. The
two earlier goto out paths never assign the variable, so there is no
double-free.
Signed-off-by: Gil Portnoy <dddhkts1@gmail.com>
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Commit 6b9a2e09d4 ("ksmbd: avoid zeroing the read buffer in smb2_read()")
switched the SMB2 READ payload buffer from kvzalloc() to kvmalloc(), on the
premise that only the nbytes actually read are ever transmitted, so the
ALIGN(length, 8) tail need not be initialized.
That premise does not hold for a compound response. ksmbd_vfs_read() fills
only nbytes, leaving [nbytes, ALIGN(length, 8)) uninitialized. The aux
payload is pinned as the last response iov with iov_len == nbytes, but when
the READ is a member of a compound, init_chained_smb2_rsp() 8-byte-aligns
the previous member by extending that same iov:
new_len = ALIGN(len, 8);
work->iov[work->iov_idx].iov_len += (new_len - len);
inc_rfc1001_len(work->response_buf, new_len - len);
so up to 7 uninitialized bytes of the kvmalloc()'d slab tail are sent
to the client. When the read length is small the buffer is served from
a general kmalloc slab, so those bytes can be stale kernel-heap
contents, including pointer values -- an information leak usable to
defeat KASLR.
An authenticated client triggers it with a compound request containing a
READ whose returned nbytes is not 8-aligned (for example [READ, CLOSE] with
a 1-byte read).
Zero only the alignment tail after the read, preserving the bulk
no-zeroing optimization of 6b9a2e09d4.
Fixes: 6b9a2e09d4 ("ksmbd: avoid zeroing the read buffer in smb2_read()")
Cc: stable@vger.kernel.org
Signed-off-by: Gil Portnoy <dddhkts1@gmail.com>
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
