mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-10 20:48:12 +00:00
1,464,947 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
SJ Park
|
1ec0e6b6f7 |
mm/damon: adjust isolated pages stat for DAMOS_MIGRATE_{HOT,COLD}
Callers of migrate_pages() should adjust NR_MIGRATED_{ANON,FILE} for
isolations and putback of the folios. That for migration succeeded folios
is done by migrate_pages(), in migrate_folio_done(). That for MR_DEMOTION
reason is an exception though.
DAMOS_MIGRATE_{HOT,COLD} call migrate_pages() but mistakenly not doing the
stat adjustment. As a result, use of DAMOS_MIGRATE_{HOT,COLD} could
corrupt the stat. It could confuse too_many_isolated(), make compaction
and reclaim to behave in unexpected ways. The stat corruption can be
reproduced and confirmed using DAMON user-space tool [1] on NUMA systems,
like below.
$ numactl --hardware
available: 2 nodes (0-1)
[...]
$ sudo ./damo start --damos_action migrate_hot 1
$ sudo cat /proc/sys/vm/stat_refresh
$ sudo dmesg
[...]
[ 80.215554] vmstat_refresh: nr_isolated_anon -5578
[ 80.216842] vmstat_refresh: nr_isolated_file -34400
This issue was discovered [2] by Sashiko.
Link: https://lore.kernel.org/20260728140404.94476-1-sj@kernel.org
Link: https://github.com/damonitor/damo [1]
Link: https://lore.kernel.org/20260726164356.87940-1-sj@kernel.org [2]
Fixes:
|
||
liyouhong
|
5deb65c34e |
mm/damon/ops-common: putback folios on invalid migrate nid
damon_pa_migrate() and damos_va_migrate() isolate folios into a local list
and then call damon_migrate_pages(). When target_nid is invalid
(including the scheme default NUMA_NO_NODE / -1), damon_migrate_pages()
returns early without putting the folios back to the LRU.
Callers then discard the list head while those folios remain isolated with
an extra reference taken by folio_isolate_lru(). The pages stay off the
LRU for as long as the mapping exists (anon active+inactive counts drop
while RSS does not), and the leftover references can pin the pages after
the mapping is gone.
Put the folios back on the invalid-nid path so ignored migration requests
still return them to the LRU.
Link: https://lore.kernel.org/20260726014815.1280757-1-dayou5941@163.com
Fixes:
|
||
Matt Fleming
|
aca1f2d5de |
mm/huge_memory: initialise workingset state before folio split
xas_try_split() adds __GFP_ACCOUNT for page-cache xa_nodes, but
__folio_split() leaves the xa_state's xa_lru unset. That lets a live,
memcg-charged xa_node exist without being linked into the mapping's
shadow_nodes list_lru; when reclaim later walks the list_lru it trips
VM_WARN_ON(!css_is_dying()).
Use mapping_set_update() to install both the workingset update callback
and the shadow_nodes list_lru on the xa_state.
Link: https://lore.kernel.org/20260725101419.3938406-1-matt@readmodwrite.com
Fixes:
|
||
Zhiling Zou
|
8db4bab826 |
mm/page_table_check: skip special zero mappings
page_table_check_set() and page_table_check_clear() account mappings based
on PageAnon(). Shared zero-page PTEs and huge zero PMDs are special
mappings, but page_table_check can still account them as file-backed
pages.
An unprivileged process can populate enough zero mappings to overflow
file_map_count and hit the existing BUG_ON(). The PTE path can do this
with the shared zero page, and the PMD path can do the same with huge zero
mappings.
Skip special zero mappings in the user page-table accounting paths. Keep
the PTE-side pte_special() check, and identify huge zero PMDs from the
mapped folio instead of pmd_special(). That covers architectures where
pmd_special() is a no-op without adding huge_zero_pfn checks to the
generic counter helpers.
Link: https://lore.kernel.org/cover.1784717203.git.zhilinz@nebusec.ai
Link: https://lore.kernel.org/e94478e4fb7912fb7e8ebebed5ce85d00dc9a69d.1784717203.git.zhilinz@nebusec.ai
Fixes:
|
||
|
SJ Park
|
0f18683103 |
mm/damon/lru_sort: skip damon_call() if ctx has not started
DAMON_LRU_SORT calls damon_call() for commit_inputs parameter user input
if the DAMON context is initialized. The context could be initialized,
but not yet successfully started. In the case, damon_call() could
indefinitely hang. Read the comment on damon_call() for more detail. Fix
the problem by memorizing if the DAMON context has ever successfully
started, and skip damon_call() if it has not.
This issue can easily be reproduced by writing Y to the commit_inputs
parameter file on a system that DAMON_LRU_SORT has not turned on before.
Link: https://lore.kernel.org/20260803134646.16640-3-sj@kernel.org
Fixes:
|
||
|
SJ Park
|
b9b6bad94c |
mm/damon/reclaim: skip damon_call() if ctx has not started
Patch series "mm/damon/{reclaim,lru_sort}: fix commit_inputs infinite
hang".
Writing 'Y' to commit_inputs parameters of DAMON_RECLAIM and
DAMON_LRU_SORT before the modules were ever turned on causes infinite
hang. Fix those.
The issue was discovered [1] by Sashiko.
This patch (of 2):
DAMON_RECLAIM calls damon_call() for commit_inputs parameter user input if
the DAMON context is initialized. The context could be initialized, but
not yet successfully started. In the case, damon_call() could
indefinitely hang. Read the comment on damon_call() for more detail. Fix
the problem by memorizing if the DAMON context has ever successfully
started, and skip damon_call() if it has not.
This issue can easily be reproduced by writing Y to commit_inputs on a
system that DAMON_RECLAIM was not turned on before.
Link: https://lore.kernel.org/20260803134646.16640-1-sj@kernel.org
Link: https://lore.kernel.org/20260803134646.16640-2-sj@kernel.org
Link: https://lore.kernel.org/20260802173021.762-1-sj@kernel.org [1]
Fixes:
|
||
|
SJ Park
|
06befa61c4 |
mm/damon/lru_sort: error out for >10000 active_mem_bp
damos_quota_score() can trigger division by zero if the target value is
zero. DAMON_LRU_SORT lets users set the target value for the hot memory
scheme via active_mem_bp parameter. It avoids setting it as the target
value if the parameter value is zero. However, it also sets the cold
memory scheme with a target value that is calculated as '10000 -
active_mem_bp + 2'. Hence, if a user sets active_mem_bp 10002, the cold
memory scheme's quota goal target value can be zero. As a result,
division by zero can be triggered. Fix by returning an error when the
user tries to start DAMON with >10000 active_mem_bp parameter value.
It makes no sense to set active_mem_bp with 10002. It also requires
module parameters write permission to reproduce the issue. That said, the
consequence is quite bad.
One reliable way to reproduce the issue is like below:
# cd /sys/module/damon_lru_sort/parameters
# echo 1000 > wmarks_high
# echo 995 > wmarks_mid
# echo 0 > wmarks_low
# echo 10002 > active_mem_bp
# echo Y > enabled
# dmesg -w
[...]
[ 597.421247] Oops: divide error: 0000 [#1] SMP NOPTI
[ 597.428848] RIP: 0010:damos_quota_score+0x6f/0x480
This issue was discovered [1] by Sashiko.
Link: https://lore.kernel.org/20260803134034.15217-3-sj@kernel.org
Link: https://lore.kernel.org/20260801213028.5127-1-sj@kernel.org [1]
Fixes:
|
||
|
SJ Park
|
a16fd3ad9d |
samples/damon/mtier: error out for zero quota goal target values
Patch series "mm/damon: avoid division by zero from damos_quota_score()".
DAMON_SAMPLE_MTIER and DAMON_LRU_SORT allow the user to trigger division
by zero in damos_quota_score(). Avoid it by adding parameters validation
checks.
This patch (of 2):
damos_quota_score() can trigger division by zero if the target_value is
zero. DAMON_SAMPLE_MTIER lets users set the target_value via
node0_mem_{used,free}_bp parameters. It doesn't guard zero value case,
though. As a result, users can trigger division by zero. Fix the issue
by returning an error when the user tries to start DAMON with zero
node0_mem_{used,free}_bp parameter values.
DAMON_SAMPLE_MTIER is just a sample module, but the consequence is quite
bad. Also the zero node0_mem_free_bp parameter might look like a
reasonable setup to some users. Hence, the issue might really happen in
the real world.
One reliable way to reproduce the issue is like below:
# cd /sys/module/damon_sample_mtier/parameters
# echo 4096 > node0_start_addr
# echo 8192 > node0_end_addr
# echo 8192 > node1_start_addr
# echo 81920 > node1_end_addr
# echo 0 > node0_mem_free_bp
# echo Y > enabled
# dmesg -w
[...]
[18792.235916] Oops: divide error: 0000 [#1] SMP NOPTI
[...]
[18792.242787] RIP: 0010:damos_quota_score+0x6f/0x480
[...]
This issue was discovered [1] by Sashiko.
Link: https://lore.kernel.org/20260803134034.15217-1-sj@kernel.org
Link: https://lore.kernel.org/20260803134034.15217-2-sj@kernel.org
Link: https://lore.kernel.org/20260801202657.117135-1-sj@kernel.org [1]
Fixes:
|
||
Danila Tikhonov
|
4194140a51 |
mailmap: map old addresses to Danila Tikhonov
Map my old jiaxyga.com and ProtonMail addresses to the current mainlining.org address. Link: https://lore.kernel.org/20260801153333.296218-1-danila@mainlining.org Signed-off-by: Danila Tikhonov <danila@mainlining.org> Cc: Jakub Kacinski <kuba@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
Lorenzo Stoakes (ARM)
|
98bd3af0bb |
mm/huge_memory: separate out CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic
Rather than mixing the refcounted and non-refcounted
CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic, separate the two out cleanly so
it is clear what happens when this configuration option is set and what
happens when it is not.
Introduce HUGE_ZERO_UNSET_PFN to abstract the ~0UL assignment, only
introduce the refcount, lock and shrinker if
!CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, abstract initialisation and teardown,
abstract the huge zero folio allocation from refcounting.
Also change a BUG_ON() to WARN_ON_ONCE() while we're at it.
No functional change intended.
Link: https://lore.kernel.org/20260730-fix-refcounted-huge-zero-v2-2-c5d8a41b317f@kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Fixes:
|
||
|
Lorenzo Stoakes (ARM)
|
33192a26cd |
mm/huge_memory: fix huge_zero_pfn race
Patch series "mm/huge_memory: fix huge_zero_pfn race", v2.
There is a subtle race in the reference-counted huge_zero_folio
implementation.
The fast path atomic logic fails to account for the fact that the shrinker
(which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn
with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a
racing get_huge_zero_folio() installed a valid value there.
This results in huge_zero_folio being correctly set but huge_zero_pfn
being set incorrectly and thus is_huge_zero_pfn() and consequently
is_huge_zero_pmd() will misidentify the huge zero folio as being an
ordinary THP folio.
This can result in the huge zero folio being split and otherwise treated
incorrectly.
The solution to this is very subtle as there is an atomic fast path, and
thus ordering in weakly ordered architectures has to be treated very
carefully.
The first commit fixes the issue by introducing a spinlock around
huge_zero_[pfn, folio, refcount] write, with careful consideration paid to
load/store ordering in the fast path. It is placed first and kept as
small as possible so that it can be backported on its own.
The second commit is a pure cleanup which reworks the
CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent
logic from the dynamically allocated one.
This patch (of 2):
If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted
by huge_zero_refcount and returned by mm_get_huge_zero_folio().
When the caller is done with the huge zero page, its reference count is
decremented. Only a shrinker can set the reference count to zero.
A race can unfortunately occur between a shrinker decrementing the
reference count to zero and a concurrent page fault.
This is because shrink_huge_zero_folio_scan() might, if very unlucky, be
preempted between setting huge_zero_refcount to zero and writing an
invalid value.
During this time get_huge_zero_folio() could write to huge_zero_pfn before
shrink_huge_zero_folio_scan() resumes.
In this event the huge zero folio will be persistently misidentified
causing the THP code path to be entered inappropriately for the huge zero
folio:
CPU 0 CPU 1
=======================================|=================================
shrink_huge_zero_folio_scan() |
atomic_cmpxchg() sets refcount to 0 |
xchg() sets huge_zero_folio to NULL | get_huge_zero_folio()
| | atomic_inc_not_zero() -> zero
preempted for a long time | Allocate new huge zero folio
| | Write valid huge_zero_folio
v | Write valid huge_zero_pfn
Overwrite huge_zero_pfn with ~0UL <--- Invalid overwrite!
This results in is_huge_zero_pfn() and is_huge_zero_pmd() incorrectly
returning false for a huge zero page which could result in issues like the
huge zero folio being incorrectly split.
Note that the issue is with huge_zero_pfn not huge_zero_folio, as
get_huge_zero_folio() uses cmpxchg() gated on huge_zero_folio being NULL
with a retry loop and shrink_huge_zero_folio_scan() uses xchg() to set
huge_zero_folio.
Fix the issue by introducing a spinlock, huge_zero_lock, to prevent
concurrent write of huge_zero_folio, huge_zero_pfn and huge_zero_refcount.
There needs to be significant care taken here to ensure correctness:
The fast path in get_huge_zero_folio() uses atomic_inc_not_zero(), which
is outside of the critical section, and means huge zero allocation is
gated on zero huge_zero_refcount.
The fast path doesn't use huge_zero_lock, so the critical section is
irrelevant to it.
So invariants are required - huge_zero_refcount MUST:
* Only be set in the huge_zero_lock critical section to ensure
serialisation of huge_zero_pfn, huge_zero_folio and huge_zero_refcount
writes.
* Be set non-zero only AFTER huge_zero_[pfn, folio] are set to valid values
so installation of the huge zero folio on read page fault ensures
concurrent is_huge_zero_*() calls correctly identify the huge zero folio.
* Be set zero only BEFORE huge_zero_[pfn, folio] are set to NULL and ~0UL
respectively, and atomically.
Establish these by:
* Only setting huge_zero_refcount to zero or an absolute value in the
huge_zero_lock critical section in get_huge_zero_folio() and
shrink_huge_zero_folio_scan(), and always updating atomically there
and elsewhere.
* Using atomic_set_release(&huge_zero_refcount) in get_huge_zero_folio()
after huge_zero_[pfn, folio] are set. This is paired with
atomic_inc_not_zero() to ensure atomic_inc_not_zero() only observes a
non-zero value if huge_zero_[pfn, folio] are set.
* Using atomic_cmpxchg() in shrink_huge_zero_folio_scan() (as before) to
ensure that it is set zero only when equal to 1 and set atomically.
* atomic_cmpxchg() being fully ordered ensures this is done prior to
huge_zero_[folio, pfn] being set to NULL and ~0UL respectively.
Eliminate the retry loop in get_huge_zero_folio() as the atomic_cmpxchg()
in shrink_huge_zero_folio_scan() is now performed under the lock, and
replace with an equally locked atomic_inc() to set the reference count
should the caller be raced on huge zero folio installation.
folio_put() naturally implies a full memory barrier so its ordering is
maintained correctly.
The huge zero folio also cannot be released except when the shrinker does
so as it is non-LRU and non-rmappable.
Note that only the huge zero shrinker (via shrink_huge_zero_folio_scan())
can actually set huge_zero_refcount to zero, which is the count of mm's
which have at least one huge zero folio installed plus one shrinker pin.
Additionally convert a BUG_ON() to a VM_WARN_ON_ONCE().
Link: https://lore.kernel.org/20260730-fix-refcounted-huge-zero-v2-0-c5d8a41b317f@kernel.org
Link: https://lore.kernel.org/20260730-fix-refcounted-huge-zero-v2-1-c5d8a41b317f@kernel.org
Fixes:
|
||
Brendan Jackman
|
50124648db |
MAINTAINERS: update address for Brendan Jackman
Switch my entry in MAINTAINERS and .mailmap to my @linux.dev email address Link: https://lore.kernel.org/20260729-email-change-v1-1-666ae7c2b7fc@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Signed-off-by: Brendan Jackman <brendan.jackman@linux.dev> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Acked-by: Zi Yan <ziy@nvidia.com> Cc: David Hildenbrand <david@kernel.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> |
||
Hugh Dickins
|
86da3f7e1e |
mm/filemap: __filemap_add_folio() restore index before retrying
In __filemap_add_folio()'s split-a-conflict loop, xas_set_order() is
applied repeatedly: each application modifies xas.xa_index, rounding it
down according to the split_order attempted at that stage: and if all goes
as intended, it eventually (or immediately) converges on an
xas_try_split() to the required folio_order, with xas.xa_index now the
same as index: then xas_store() puts the new folio into the xarray there.
But if a new node was needed, and GFP_NOWAIT allocation did not get one,
the lock is dropped, xas_nomem() used to allocate, and sequence retried.
If (that part of) the xarray is unchanged when the lock is reacquired, no
problem. But what if the conflict was meanwhile resolved by another
thread (perhaps even doing the same thing, inserting a folio at that same
index)? Isn't there a danger of now putting our folio into the xarray at
an intermediate rounded-down index? With !folio_contains() bug to follow,
when CONFIG_DEBUG_VM=y is checking for that.
Fix this with an xas_set_order() to restore the original xas.xa_index at
the bottom of the loop, so the retry does a full re-evaluation after
reacquiring the lock, and cannot reach xas_store() with the wrong index.
Production was suffering from rare SIGILLs and SIGSEGVs, executable text
found a page away from where it belonged, !folio_contains() bug hit when
debug enabled: symptoms not seen since this patch went in.
Link: https://lore.kernel.org/562fbfa6-dd6d-0b6a-2461-ed2ff1173bc8@google.com
Fixes:
|
||
Ramin Moussavi
|
c2689266e5 |
microblaze: restore the page alignment of swapper_pg_dir
microblaze handles TLB misses in software, and the handler builds the address of the L1 entry by ORing the index into the page directory base instead of adding it (hw_exception_handler.S): bsrli r5, r3, PGDIR_SHIFT - 2 andi r5, r5, PAGE_SIZE - 4 /* Assume pgdir aligned on 4K boundary, no need for "andi r4,r4,0xfffff003" */ or r4, r4, r5 lwi r4, r4, 0 /* Get L1 entry */ The index is masked to the low 12 bits, so the OR only works if those bits of the base are zero -- which is exactly the assumption the comment states and the reason the masking of the base can be skipped. swapper_pg_dir had no alignment directive of its own. It was aligned because it followed empty_zero_page in head.S, and that one carried the .align 12: .section .data .global empty_zero_page .align 12 empty_zero_page: .space PAGE_SIZE .global swapper_pg_dir swapper_pg_dir: .space PAGE_SIZE Commit |
||
|
Lorenzo Stoakes (ARM)
|
9d3277b2c0 |
arm64: remove redundant concurrent ptdump UAF mitigation
This partially reverts commit |
||
|
Lorenzo Stoakes (ARM)
|
27c32e5538 |
mm/ptdump: always stabilise against page table freeing using init_mm
Previous commits have established the invariant that kernel page table freeing is performed while an mmap read lock on init_mm is held, which fixes races between ptdump and kernel page table freeing over init_mm. However, x86 and arm64 can perform a ptdump over an mm other than init_mm via ptdump_walk_pgd() and since kernel memory ranges are shared across non-kernel mm's, this means that the race still exists for these cases. Fix this by acquiring a nested mmap write lock for init_mm in ptdump_walk_pgd(). This is safe as we take this after mmap write locking the mm, and nothing acquires the init_mm lock first before locking an arbitrary mm, so no deadlock is possible. Also update walk_page_range_debug() to assert that init_mm is write locked, add a comment explaining why and remove some redundant code, and eliminate the unnecessary and confusing invocation of walk_kernel_page_table_range(). We can safely remove the non-NULL check for walk.mm, as the mmap lock asserts would NULL pointer deref if it was (and of course no callers do this). The first point at which ptdump can race kernel page table freeing is commit |
||
|
Lorenzo Stoakes (ARM)
|
26444eb714 |
mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF
Patch series "mm: fix UAF caused by race between ptdump and vmap pgtable freeing", v6. Kernel page table walkers fall into two broad categories - those ranges where no exclusion is required via walk_kernel_page_table_range_lockless() and those where exclusion is required via walk_kernel_page_table_range() or walk_page_range_debug(). The former category is used only by arm64 arch code operating on ranges it both wholly owns and does not concurrently write. The latter category consists of kernel page table walkers operating on ranges that are wholly owned (but which need exclusion against concurrent writers). The lock used for exclusion is the mmap lock, and for kernel ranges this is the mmap lock on init_mm. ptdump is a special case being both the only user of walk_page_range_debug(), and the only case in which it walks ranges it does not own. This presents a problem, as page tables may be freed under ptdump. And indeed there is a use-after-free bug in the kernel as a result, which this series addresses. vmap promotes page tables to huge leaf entries where possible, freeing the lower page table when it does. It does this with no meaningful locks held against concurrent ptdump walks. As a result, use-after-free can currently occur. This series addresses the issue by having the vmap huge promotion logic acquire the mmap read lock while both setting the huge page table entry and freeing the prior leaf page table. The ptdump code already acquires the mmap write lock, so by doing so we ensure that the ptdump walker only ever observes either the huge page table entry or the existing page table entry, and nothing is freed underneath it. A mitigation for this issue was already applied for arm64 in commit |
||
Jakub Kicinski
|
6183a645aa |
Merge branch 'bnxt_en-bug-fixes'
Michael Chan says: ==================== bnxt_en: Bug fixes This series include 3 bug fixes: 1. queue start bug fix on the VNIC's default ring. 2 refactoring patches preceed the actual bug fix. 2. Bug fix for TPA data corruption seen on some ARM systems. 3. PTP PPS setting bug fix. ==================== Link: https://patch.msgid.link/20260731190937.807270-1-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
Keegan Freyhof
|
80eaf88efe |
bnxt_en: Fix PTP PPS setting bug
The existing driver logic is always turning on PTP_CLK_REQ_PPS
regardless of the "on" parameter passed to bnxt_ptp_enable().
During shutdown, PTP_CLK_REQ_PPS may be turned off and this
bug will do the opposite and may trigger a PCIe PTM request TLP.
On some systems this can trigger a PCIe AER.
Fix it by properly configuring PTP_CLK_REQ_PPS based on the "on"
parameter.
Fixes:
|
||
Michael Chan
|
c3faf548a0 |
bnxt_en: Disable EOP for TPA on all chips to prevent data corruption
EOP (End of frame padding) on the AGG ring may cause overlapping of
zero padding at the end of one segment with the next segment's data.
If Relaxed Ordering (RO) is enabled, the zero padding may overwrite
valid data in the next segment and corrupt the data. Older chips
(P5 and older) do not automatically disable RO when EOP is enabled.
On some ARM systems, data corruption was reported on 57508 (P5)
chips with RO enabled.
Always disable EOP on all chips on the AGG rings when TPA is enabled
to fix the data corruption.
Fixes:
|
||
Shravya KN
|
0b137529a8 |
bnxt_en: Refresh VNIC default ring on queue restart if needed
When a queue is restarted, refresh VNIC_CFG for all VNICs whose
default RX ring is the restarted ring. This will eliminate this
possible FW warning caused by a stale default ring in the VNIC:
FW reported unknown error type 10
Fixes:
|
||
|
Shravya KN
|
53f01cd594 |
bnxt_en: Determine and store default RX ring in vnic structure
Each VNIC has a default RX ring. The purpose of the default RX ring is to provide a destination for any packets that cannot be parsed by the RSS logic. Up until now, the default RX ring is always Ring 0. We neglected to take care of this default RX ring when adding the queue restart feature. If ring 0 (default ring) is re-started, it may now have a new FW ring ID after freeing the old one and allocating a new one. The VNIC now may have a stale default ring and it may generate an internal exception. This exception may appear in dmesg: FW reported unknown error type 10 The best way to resolve this issue is to use a more appropriate ring for the default ring instead of always ring 0. Ring 0 may not even be in the RSS table, especially on a new RSS context. This patch adds the logic to determine and store the proper default RX ring for a VNIC. For an RSS VNIC, the default ring is the lowest ring number in the RSS table. The next patch will add proper logic to update the VNIC if the default ring changes after queue restart. Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Shravya KN <shravya.k-n@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20260731190937.807270-3-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Shravya KN
|
1d0fc6c7ea |
bnxt_en: Move RSS table fill outside __bnxt_hwrm_vnic_set_rss()
This is a refactor patch with no change in behavior. The caller will now fill the RSS table before calling __bnxt_hwrm_vnic_set_rss(). In the next patch, we'll add code to determine the default ring for the VNIC when we fill the RSS table. Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Shravya KN <shravya.k-n@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20260731190937.807270-2-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
Bobby Eshleman
|
e7386770be |
net/mlx5e: fix BQL reset on SQ re-activation
mlx5e_queue_start() deactivates and re-activates all channels but closes
only the queue being restarted. mlx5e_activate_txqsq() then
unconditionally calls netdev_tx_reset_queue(), zeroing the BQL counters
of channels that kept their in-flight TX WQEs. The next completion then
over-charges and trips the BUG_ON() in dql_completed():
kernel BUG at lib/dynamic_queue_limits.c:99!
RIP: 0010:dql_completed+0x23d/0x280
Call Trace:
<IRQ>
mlx5e_poll_tx_cq+0x668/0xa60
mlx5e_napi_poll+0x5b/0x7b0
net_rx_action+0x15a/0x580
Reset BQL only when the SQ has no bytes in flight (sq->cc == sq->pc).
In the case that reset is skipped, the outstanding WQEs will eventually
complete and rebalance the dql. The dql->limit is carried across the
reset.
Fixes:
|
||
|
Zhiling Zou
|
5d1c224dd9 |
net: openvswitch: reallocate update replies for mismatched IDs
ovs_flow_cmd_new() preallocates the optional reply skb before it takes
ovs_mutex and before it knows which existing flow will be updated.
That is normally fine because the skb is sized from the request flow
identifier. That identifier also becomes the inserted flow's identifier.
For updates, however, a request with a UFID may miss the UFID lookup and
then fall back to the flow key lookup. That lookup can legitimately find
an existing key-identified flow. UFIDs are optional and the flow key is
the primary identifier.
For echoed replies, ovs_flow_cmd_fill_info() writes the matched flow's
identifier, not the request identifier used for the preallocation. A short
request UFID can therefore leave too little room for the key identifier.
The fill can then fail with -EMSGSIZE and hit the BUG_ON(error < 0) in the
update path.
Once the update target has been resolved, reallocate the reply skb if the
matched flow needs a larger reply than the request identifier allowed. Do
this before replacing the actions so the request can still fail cleanly if
the rare extra allocation fails.
Fixes:
|
||
Laurent Vivier
|
1505b2cb6a |
usbnet: cap max_mtu for drivers without bind callback
usbnet_probe() initializes max_mtu to ETH_MAX_MTU and only caps it
inside the if (info->bind) block. Drivers without a bind callback
never enter this block, so max_mtu stays at ETH_MAX_MTU.
QEMU's usb-net device (0x0525/0xa4a2) is claimed by the cdc_subset
driver which has no bind callback. The guest accepts any MTU from DHCP
(e.g. 65520 from passt), leading to TCP segments that exceed the
device's 2048-byte receive buffer and are silently dropped.
Initialize max_mtu to net->mtu at probe time and update it inside
the bind block.
Fixes:
|
||
Alok Tiwari
|
2cbd8a4e5e |
bnge: use int for bnge_fix_rings_count() return value
bnge_fix_rings_count() returns 0 on success or a negative errno on failure
However, bnge_adjust_rings() stores its return value in a u16 variable,
causing negative error codes such as -ENOMEM to be converted to a large
positive value.
Use an int for the return code variable so that error values are
preserved and propagated correctly.
Fixes:
|
||
|
Jakub Kicinski
|
6310aaadbf |
Merge branch 'net-atlantic-fix-two-ring-teardown-leaks'
Yangyu Chen says: ==================== net: atlantic: fix two ring teardown leaks These are the two fixes from the page_pool conversion series [1], resent against net as requested in the review of that series. The page_pool conversion itself stays in net-next and is not part of this posting; it depends on these fixes, but they stand on their own. Both patches are unchanged from [1] apart from the collected Reviewed-by tags, and each carries a Fixes tag and a Cc: stable with the affected range (patch 1: v4.11+, patch 2: v5.2+). They apply and were build- and runtime-tested independently of each other and of the conversion. Patch 1: aq_vec_deinit() drains the TX rings with a single aq_ring_tx_clean() call, which is capped at AQ_CFG_TX_CLEAN_BUDGET descriptors and stops at hw_head, frozen once the hardware and NAPI have been stopped. Everything beyond that keeps its skb or xdp_frame when the interface goes down and is lost when the buffer ring is freed. Patch 2: aq_ring_rx_deinit() only walks [sw_head, sw_tail). Since the page reuse strategy was added, a cleaned RX buffer keeps its page for reuse and refill is batched, so consumed but not yet reposted slots accumulate in the [sw_tail, sw_head) gap and their pages and DMA mappings are never released. Reproduction logs for both leaks (as page_pool stalled shutdowns, which is how they become visible) are in the notes of the respective patches. [1] https://lore.kernel.org/lkml/tencent_1F173E0FC1606D2AC704DC9C98AF10984607@qq.com/ ==================== Link: https://patch.msgid.link/tencent_29B860317921D68DE77C718242DA418EB608@qq.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
Yangyu Chen
|
e8e7471ef6 |
net: atlantic: free RX pages of consumed but not refilled buffers
aq_ring_rx_deinit() only walks [sw_head, sw_tail), the region posted to
hardware. Since the page reuse strategy was added, a cleaned RX buffer
keeps its page (and its DMA mapping) in the ring for reuse, and refill
is batched: aq_ring_rx_fill() returns early until AQ_CFG_RX_REFILL_THRES
slots are free. Slots that were consumed but not yet reposted therefore
sit in the complementary [sw_tail, sw_head) gap with a live page, and
the deinit walk never visits them: up to a refill batch worth of pages
and DMA mappings leak on every interface down.
Walk the whole ring instead and release whatever is still there. Also
bail out if the buffer ring is already gone: a partial
aq_ptp_ring_alloc() failure frees the ring but leaves aq_nic set, so
aq_ptp_ring_deinit() still gets here on the unwind path.
Cc: stable@vger.kernel.org # v5.2+
Fixes:
|
||
|
Yangyu Chen
|
452636ea54 |
net: atlantic: free stranded TX buffers on ring deinit
aq_vec_deinit() drains the TX rings with a single aq_ring_tx_clean()
call, which frees at most AQ_CFG_TX_CLEAN_BUDGET (256) descriptors and
stops at hw_head, which no longer moves once aq_vec_stop() has stopped
the hardware and NAPI. Completed descriptors beyond the budget and
everything still posted in [hw_head, sw_tail) keep their skb or
xdp_frame when the interface goes down: aq_vec_ring_free() then frees
the buffer ring and the references are lost for good.
Today this is a silent memory leak on every interface down under
TX/XDP_TX load. With the conversion of the RX path to page_pool posted
for net-next it becomes much more visible: XDP_TX frames carry fragment
references on the RX ring's page_pool, so a single stranded frame keeps
the pool's inflight count above zero forever. page_pool_destroy() then
never completes, the pool is leaked together with its pages, and
"page_pool_release_retry() stalled pool shutdown" is warned every 60
seconds from that point on, on every ifdown, XDP detach or ring resize
under XDP_TX load.
Bring back aq_ring_tx_deinit() as it was before the removal and use it
for teardown again, with one extension: TX rings can hold xdp_frames
nowadays, so release those too. They are returned with
xdp_return_frame() since this runs in process context.
Fixes:
|
||
Stefan Agner
|
06232cb44b |
net: stmmac: resume PHY before hardware setup when opening the interface
Since the referenced commit, changing the MTU on a running interface no
longer disconnects and reconnects the PHY; __stmmac_release() merely
stops phylink, which also suspends the PHY (BMCR power-down) when WoL
is not enabled. __stmmac_open() then performs the DMA software reset in
stmmac_hw_setup() before phylink_start() resumes the PHY again.
IEEE 802.3 22.2.4.1.5 allows a PHY to stop its receive clock while
powered down, and stmmac requires a running receive clock for the DMA
software reset to complete (the phylink config sets mac_requires_rxc).
On such setups, e.g. the RK3566-based Home Assistant Green with an
RTL8211F-VD PHY in RGMII mode, any runtime MTU change now times out and
leaves the interface dead:
rk_gmac-dwmac fe010000.ethernet end0: Failed to reset the dma
rk_gmac-dwmac fe010000.ethernet end0: stmmac_hw_setup: DMA engine initialization failed
rk_gmac-dwmac fe010000.ethernet end0: __stmmac_open: Hw setup failed
rk_gmac-dwmac fe010000.ethernet end0: failed reopening the interface after MTU change
In the field this is triggered by NetworkManager applying an MTU while
activating the connection, breaking networking entirely. The same
regression has also been reported on i.MX8MP and reproduced on SoCFPGA
based systems.
Resume the PHY in __stmmac_open() before the hardware setup, making it
the counterpart of the phylink_stop() in __stmmac_release(), like
stmmac_resume() already does for the same reason. phylink_start() also
resumes the PHY, but only after stmmac_hw_setup(), and it cannot be
moved before the hardware setup since it may bring the link up
immediately from a workqueue, racing with the initialization (see the
comment in stmmac_resume()). For the regular ndo_open path the PHY has
just been attached and is not suspended, in which case
phylink_prepare_resume() does nothing.
Fixes:
|
||
|
Jakub Kicinski
|
e31420642d |
Included fixes:
* use rcu_dereference_bh() instead of rcu_access_pointer() where the pointer is actually dereferenced * ensure TCP global variables are initialized before they can be accessed via netlink (e.g. when attaching a TCP socket) * actually disable IPv4 redirects on multipeer interfaces (the previous attempt was a no-op and did not survive netns moves) * hash a floated peer by its transport identity only, consistently with the add and lookup paths * zero the sockaddr padding before learning a floated endpoint so it does not leak into the by_transp_addr hash key * ensure the socket is owned by ovpn before dereferencing sk_user_data * rehash a peer in the by_transp_addr table when its remote endpoint is updated via CMD_PEER_SET * avoid re-adding to the hashtables a peer that was concurrently removed (use-after-free) * limit keepalive values to one day to avoid overflowing the delayed-work delay on 32-bit systems * add the missing rtnl_link_ops->get_size callback so link messages account for the nested mode attribute -----BEGIN PGP SIGNATURE----- iJEEABYIADkWIQQr0db7q+Rc7Zog28Fc8QQzwdnOtwUCamsZiRsUgAAAAAAEAA5t YW51MiwyLjUrMS4xMiwyLDIACgkQXPEEM8HZzrdjhQD/SJjvWsxHurn7vQJ8VFw9 wb8Q06TpSjdHkd5xXpQzohoA/joMlAYnVhSlYDcDaF3DCzmCAW6fG/bpPoI4bpFj i8UD =Oppi -----END PGP SIGNATURE----- Merge tag 'ovpn-net-20260730' of https://github.com/OpenVPN/ovpn-net-next Antonio Quartulli says: ==================== Included fixes: * use rcu_dereference_bh() instead of rcu_access_pointer() where the pointer is actually dereferenced * ensure TCP global variables are initialized before they can be accessed via netlink (e.g. when attaching a TCP socket) * actually disable IPv4 redirects on multipeer interfaces (the previous attempt was a no-op and did not survive netns moves) * hash a floated peer by its transport identity only, consistently with the add and lookup paths * zero the sockaddr padding before learning a floated endpoint so it does not leak into the by_transp_addr hash key * ensure the socket is owned by ovpn before dereferencing sk_user_data * rehash a peer in the by_transp_addr table when its remote endpoint is updated via CMD_PEER_SET * avoid re-adding to the hashtables a peer that was concurrently removed (use-after-free) * limit keepalive values to one day to avoid overflowing the delayed-work delay on 32-bit systems * add the missing rtnl_link_ops->get_size callback so link messages account for the nested mode attribute * tag 'ovpn-net-20260730' of https://github.com/OpenVPN/ovpn-net-next: ovpn: fix incorrect use of rcu_access_pointer() ovpn: ensure TCP vars are initialized first ovpn: disable IPv4 redirects on MP interfaces ovpn: hash floated peer by transport identity only ovpn: zero-initialize sockaddr before learning a floated endpoint ovpn: ensure socket is owned by ovpn before deref sk_user_data ovpn: rehash peer in by_transp_addr table on CMD_PEER_SET ovpn: skip rehash for peers already removed from by_id ovpn: limit keepalive values to one day ovpn: add missing rtnl_link_ops->get_size callback ==================== Link: https://patch.msgid.link/20260730094624.4102963-1-antonio@openvpn.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
Martin Kaiser
|
6e3abef2a2 |
selftests/ftrace: refactor eprobes test to fix argument checks
The add/remove eprobe test installs an eprobe for the openat syscall and runs ls. It checks the filenames that were opened by ls against a whitelist and a blacklist. Commit |
||
Frank Sorenson
|
26fa4d17c0 |
smb: client: fix SMB1 TRANS2 multi-response truncation in SendReceive()
When a TRANS2 response is split across multiple secondary packets,
coalesce_t2() assembles the payload into the large response buffer.
Two bugs cause SendReceive() to copy only a small fraction of the
assembled buffer into the caller's output buffer.
This manifests when listing a large directory on an SMB1 share
(observed against Windows XP); the first getdents returns only
partial results, and subsequent getdents returns EINVAL.
Bug 1: coalesce_t2() computes the coalesced size as:
*pdu_len += total_in_src;
cifs_demultiplex_thread() resets *pdu_len to each secondary's own
pdu_length before calling coalesce_t2(), so this accumulates from
the wrong baseline on every secondary after the first.
Bug 2: after reassembly, cifs_demultiplex_thread() sets
mid->resp_buf_size to the final secondary's raw packet size. This
value is later used as the memcpy length, so only a portion of the
coalesced response is copied.
Fix both by replacing the stale *pdu_len arithmetic with
smbCalcSize(), which reads the BCC field that coalesce_t2()
maintains correctly throughout reassembly.
Fixes:
|
||
Guenter Roeck
|
0dabe8a56f |
hwmon: (pmbus/lm25066) Fix PMBus coefficient calculations
In lm25066_probe(), the PMBus coefficients for current and power are
scaled based on the shunt resistor value. The calculation evaluates the
multiplication using 32-bit arithmetic because info->m is an int and
shunt is a u32:
static int lm25066_probe(struct i2c_client *client) {
...
info->m[PSC_CURRENT_IN] = info->m[PSC_CURRENT_IN] * shunt / 1000;
info->m[PSC_POWER] = info->m[PSC_POWER] * shunt / 1000;
...
}
For large coefficients like 26882 (LM25056) or 15076 (LM5066i), a device
tree shunt-resistor-micro-ohms value exceeding approximately 159,000
(159 mOhm, which is physically valid for low-current applications) causes
the intermediate product to exceed UINT_MAX (4,294,967,295). This results
in a silent wraparound before the division by 1000.
Furthermore, if the wrapped value has the most significant bit set,
converting it back to the signed int info->m results in negative
coefficients. This logic error leads to drastically corrupted current and
power readings, which can cause erratic thermal or power management
behavior in the system.
Fix the problem by using 64-bit operations for the multiply/divide
operations. This can still overflow, but only for unreasonably large
shunt resistor values.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes:
|
||
Breno Leitao
|
a213dfaa25 |
x86/mce: Set up the polling timer before CMCI discovery
I hit the following on one of my machines:
mce: CPU0 BANK15 CMCI inherited storm
------------[ cut here ]------------
ODEBUG: assert_init not available (active state 0) object: (____ptrval____) object type: timer_list hint: 0x0
WARNING: lib/debugobjects.c:632 at debug_object_assert_init+0x178/0x230, CPU#0: swapper/0/0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc5 #3 PREEMPTLAZY
RIP: 0010:debug_object_assert_init+0x18f/0x230
Call Trace:
<TASK>
__mod_timer
mce_timer_kick
cmci_discover
intel_init_cmci
mce_intel_feature_init
mcheck_cpu_init
identify_cpu
identify_boot_cpu
arch_cpu_finalize_init
start_kernel
A second splat follows right after, from timer_setup() finding that same
timer already queued:
ODEBUG: init active (active state 0) object: (____ptrval____) object type: timer_list hint: stub_timer+0x0/0x10
This is happening because CMCI storm detection is trying to modify the timer
before latter was properly set up.
Set up the timer first. __mcheck_cpu_setup_timer() only calls timer_setup(),
and depends on neither the generic nor the vendor init.
[ bp: Massage commit message. ]
Fixes:
|
||
Kyle Zeng
|
0e243671bc |
ipv6: prevent in6_dev_get() from resurrecting inet6_dev
in6_dev_get() reads dev->ip6_ptr under RCU and then unconditionally increments its refcount. Device teardown can clear the pointer and drop the last reference between these operations. The increment then resurrects an object whose RCU free has already been queued, so callers can use it after it is freed. Use refcount_inc_not_zero() and return NULL when the object has already reached zero. RCU keeps the memory accessible through the attempted reference acquisition, and a successful increment pins the object for the caller. An independent run on the exact unpatched |
||
Linus Torvalds
|
c21bb41938 |
vhost,vdpa: last minute fixes
A small number of fixes that seem too important to wait until the next release. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> -----BEGIN PGP SIGNATURE----- iQFDBAABCgAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmpxXrUPHG1zdEByZWRo YXQuY29tAAoJECgfDbjSjVRpX5IIAJhVIR6djPQ/Hf24pHD+wHPAvKbV4+CCrtlv S/Frw7R8bTn0byvr3iuAHcuWLKSMXPYxfGKQRI1E7E4vbbKD81N0p+vYiO41pyV6 d7BKUxSIEOEExJ8c198ajo+S2n5OdLjayLfYagzqbClwb2Snz+mdGjBIcSLJttSb i53LebWHDXV8/uZLkyd0H8YlHXHmxroIOq16UpwwvO+lgafxZPs6ZinBS5fwEJxk fyKKf1rdoPbqQhrDU5IaHlQdqS+ZjL+3ab3rT49wCSnn+FKpzzikhxELNylZZMof StC/Y3HAbC8rY54ZMjxGcDt1KfntRchZySuOmhZ/Av+sCXaegm0= =EMjO -----END PGP SIGNATURE----- Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost Pull vhost/vdpa fixes from Michael Tsirkin: "A small number of fixes that seem too important to wait until the next release" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: vhost-scsi: reject feature changes after endpoint vhost-scsi: flush backend after device ioctls vhost: reset the vring metadata cache on vring reconfiguration vhost-scsi: Validate T10 PI scatterlist counts vdpa/mlx5: Fix buffer length in create_direct_keys() vhost/vdpa: reject overflowing PA map page counts on 32-bit vhost_iotlb: bound map allocation in add_range |
||
Qingshuang Fu
|
d533882ce1 |
hwmon: (nzxt-smart2) Check return value of init_device() in probe
The init_device() call in nzxt_smart2_hid_probe() can fail because it sends HID output reports to the hardware to detect fans and set the update interval. If the hardware is not responding or the HID reports fail, init_device() returns a negative error code. However, the return value was ignored, causing the probe to continue and register an hwmon device even though the device was never properly initialized. This leads to an inconsistent state where the driver reports stale data or blocks on wait queues that will never be woken. The same function's return value is already checked in the reset_resume() handler, confirming the author's intent that errors should be propagated. Note that this fix was not possible before commit |
||
Arnd Bergmann
|
c7a127371c |
aspeed: Update MAINTAINERS for 7.3
Add Ryan and Billy as reviewers for ASPEED SoC patches. I asked both to add themselves to increase ASPEED's visibility of upstream changes. -----BEGIN PGP SIGNATURE----- iJIEABYKADoWIQSoUT1x3bOSX/nAa8ajM9GZTrjhpgUCanGGJhwcYW5kcmV3QGNv ZGVjb25zdHJ1Y3QuY29tLmF1AAoJEKMz0ZlOuOGmDFoA+wVan8QYBaVyH4ESK0nz 73koP4V+NcoMRFeH7WHlKi3yAQDkXhq553bJXUlEhM8Gmy8A+29bjc1YsbwqQ1k9 DBw6DA== =IW7p -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmpyPqcACgkQmmx57+YA GNka7RAAgSHmYtLxG557sn7Esdovym8DDG53hUGimyzXbGm2DorV51kNzDyN9tUt S4Qys/V9NjqAGl7Lpk91uEFvfY5Box6hE9nq6kxzKpOmqhEvAaqhEEsFp27qv7Ce Qtiofw8705H1XbR7l7oaHvuUVjgRHdG5PYsHZU+6PADkVWGPIoeETUiToANfnjz6 b0JzNtyqPZFvjolt19p6LDENWEqwmONlR4CDqBWEHvZQxt5tizq1iq+cFb7mO+gg 4xvYVd4s0m8cL6l6ycJx3pXEk6wQL4CyZKnVS+kuVoA5wJzUtq4oPtIVdC+2LXZA j66GdUxVo2YKqcV7m6kT2xFo8NBAOQrcVTFfe7qFh2qmgcFDm415j7a5I5xN2YsX KJh3XefNQjP5y8JrA6K+o3BaoDrLRqPk4f6P9I1yLIjZV/3YjXoh/Ey6ew3DfZi0 FURUTrLEKNLI+PKaBFxFM3oLBn/K6twkBrobRKoDa5OQHkE0h4nS3Qz4esFRARK6 PyA3oqAdbx6fFVV1rdiJQk3KM+ctkvoIYAu+n6Gb4ahgTeZhxUHkrVRX7tUdKrqI wlTpd3N1km4aGkJD62HjLgdCPORUWLU9GcDicu93XvmtSQcajYERIKgM89sK1Lqr XAVA3YoRjU3xtdrSEQqF74vrXJXzykH13SPDGdf1sT8mZKDCO4Y= =qDYR -----END PGP SIGNATURE----- Merge tag 'aspeed-7.3-maintainers-0' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux into arm/fixes aspeed: Update MAINTAINERS for 7.3 Add Ryan and Billy as reviewers for ASPEED SoC patches. I asked both to add themselves to increase ASPEED's visibility of upstream changes. * tag 'aspeed-7.3-maintainers-0' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux: MAINTAINERS: add Ryan Chen and Billy Tsai as reviewer for ARM/ASPEED Signed-off-by: Arnd Bergmann <arnd@arndb.de> |
||
|
Arnd Bergmann
|
c73d40a1e7 |
nuvoton: First batch of ARM arch fixes for 7.2
Again a one-off change, fixing OF resource leaks in the SMP-bringup code for the NPCM7xx SoCs. -----BEGIN PGP SIGNATURE----- iJEEABYKADoWIQSoUT1x3bOSX/nAa8ajM9GZTrjhpgUCanGNzhwcYW5kcmV3QGNv ZGVjb25zdHJ1Y3QuY29tLmF1AAoJEKMz0ZlOuOGm7q0BALVNMCCpkq7EUdoXlLXQ kKLaa/eHSsRjlVkWysp8KMNhAPitU483DtqvcGiPeLD/ljIc4SC6CubwoE0YcNdg SCkL =jyvO -----END PGP SIGNATURE----- gpgsig -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmpyPKcACgkQmmx57+YA GNnK7Q//QYOANi8ZC4dUSgypONH8evH/heNwCKIzHM836KIdHVM3DnsFLBCaK+n/ dk0L1qs+Ko/PbcwZ0RSD0S6D8MGRpd1sV2FzHtTgnB0Z8r4aRJ0YPB2V3YbBsYf3 q5QZfbfAgvFA4hCtXTkhK0rzjiHKaJHUBHFeKtQKzISiQ5FNzw3IODV8uy8ZTxQS kpfbwVAepwpJ71/EEhRlXySrbr4q5Tk9DVat6rPXVUPzyAmb0lVCa0QQd4JaWKF8 OwYJjjNjJZvR6/8Xkr2z8+rio4/5Y7z0O5O7QzXHcB8f7098Tyq3We5s2wjKPjiW rAITG2uuesbQq3voIWQRtppRFFENZlCTmtUkkYJbuH23lERdbnGzJWeel0q/H0kR weeTUpGcVYocCh43OIhMZ+n5/vQuI8Xd7Yf7phHrXrx4y+UOVHCWA+4+N02u1qZj ufviSp4VZdepjBQxBytrd0LWYIvzsQOOzWHMCoUiWCz1uAI3b9LISupz0dXPLPtv xj5TbEm9UFCeQzFav6bvzvO/Wwy/XLKsm65V/T2ixeYsUtaKLDw8dqwgByx3TjNv 3BUeVtXAn0m7WBM1EP+1AKuKG+9FcU+TcnvBKF8LgVh7q4zZYuKBAWZAHuuEvLZv eDtMpWL04b/IDt98xMipOWrfnOEb3Vgwr40o3RWxP3ZBOEXi8+k= =g+dz -----END PGP SIGNATURE----- Merge tag 'nuvoton-7.2-arm-fixes-0' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux into arm/fixes nuvoton: First batch of ARM arch fixes for 7.2 Again a one-off change, fixing OF resource leaks in the SMP-bringup code for the NPCM7xx SoCs. * tag 'nuvoton-7.2-arm-fixes-0' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux: ARM: npcm: Fix OF node refcount leaks in SMP setup Signed-off-by: Arnd Bergmann <arnd@arndb.de> |
||
|
Linus Torvalds
|
31996e14bd |
- Fix a robust futexes exit race (Keno Fischer)
Signed-off-by: Ingo Molnar <mingo@kernel.org> -----BEGIN PGP SIGNATURE----- iQJFBAABCgAvFiEEBpT5eoXrXCwVQwEKEnMQ0APhK1gFAmpyKL8RHG1pbmdvQGtl cm5lbC5vcmcACgkQEnMQ0APhK1hHZA/+MuV0q1TjWfNot/8wX0o3dXMxFW041gg9 CNZK086nI1rdhiFwmu4a6QQ/CgKe8tHFa3SET+PJcwNBtxX8AoMma8hw+3E6FeLL DV/HM04S3CZahVrvbMwPl+ewPW/Nxjy0e8xO6qJzBQetUALAElzf3u9PofVbL8tI fQLzL616SzSZNk5NbUvP5EuJxM24ZfZET9fkHvF3ybq90gT2jM3EHw9hau+clXHz JqIKvhclRw3xqfEh1kbpYd2Q49v+0jvr2qYUbc9lDGarn/a/xBiOIS3rX9RbEyvA BgMmbu4NOyoFAiVZ3pRt+hJh/T55Zbyg5Yaveov7PfXXk9IwdXVtVkrcJTJNQkOW Qi5HiBx0bfLl1B5CeEUx4idpWo2uuNantlid9U+tVV1YfkUmshS8NMECvVT17kqQ Ck4ZbwMpoHhqei3e1wBIWFGOP9VgyvRTm44DykV8elbJ3w4/YOkFl9f4XF95mgm9 JaTGxQOe4r4hetKRddPouvtzbWrCbdxsQY9WLhBJq09nbJEubW8F4nhGZbaY618d OMY7RfaXXCaV0rvaESpNLSiy4WrzJ3D0shmirL8jZBrW4gckJiYnfI7QpXFZ6CyS XeJgWPCuV5L2CLTehE2t8R6zGCTNadebpKZ9M78xxGuQ+pCtaElZ+4t4Esw8Jmqb beFBOYmimjE= =IPYC -----END PGP SIGNATURE----- Merge tag 'locking-urgent-2026-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull futex fix from Ingo Molnar: - Fix a robust futexes exit race (Keno Fischer) * tag 'locking-urgent-2026-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: futex: Prevent robust futex exit race some more |
||
|
Linus Torvalds
|
562bfb501c |
integrity-v7.2-rc7
-----BEGIN PGP SIGNATURE----- iIoEABYKADIWIQQdXVVFGN5XqKr1Hj7LwZzRsCrn5QUCanIVbBQcem9oYXJAbGlu dXguaWJtLmNvbQAKCRDLwZzRsCrn5ZZJAPoCMJOvZSkj5EZVUr/fsO6MiC8rQDu6 OhNe4lripeVOowD/RapG1/PcGuYNlqtOxjFaB/Y0FYRH2hnGHpgqW/If0ws= =2zQ5 -----END PGP SIGNATURE----- Merge tag 'integrity-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity Pull integrity fixes from Mimi Zohar: "Two IMA bug fixes: one addresses a potential integer underflow, the other instantiates two LSM hooks" * tag 'integrity-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity: ima: Instantiate file_truncate and path_truncate hooks ima: fix out-of-bounds read in xattr_verify() |
||
Marcin Bernatowicz
|
d1643db3b0 |
drm/xe/uc: Apply RCS/CCS yield policy to SR-IOV VFs
VFs were missing the call to apply the global scheduling policy. Call xe_guc_submit_enable() during vf_uc_load_hw() to ensure VFs get the same policy enforcement as PF. Fixes: |
||
Michał Winiarski
|
c5f5001617 |
drm/xe: Fix memory leak in exec_queue_set_hang_replay_state()
The q->replay_state is blindly overwritten, which can potentially leak memory that was previously allocated by vmemdup_user(). Return an error if q->replay_state is not empty. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: |
||
|
Linus Torvalds
|
7c350d079e |
More NFS Client Bugfixes for Linux 7.2-rc
Bugfixes: * NFS: Pin the 'struct nfs_server' during a FREE_STATEID call * NFS: Decrement refcounts if allocating nfs_free_stateid_data fails * NFSv4.2: fix nfs4_listxattr size accounting -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEnZ5MQTpR7cLU7KEp18tUv7ClQOsFAmpyFAUACgkQ18tUv7Cl QOv7BRAAkxQD75eXSHScM4KJKmpkRGG0NFhUFg8bSUxpCD+KUmeoFV5jlpqLMeUh nsE+Pzpt+eqbsxOkQh/Ds3IibEcXSKKzbgGAP8vSJhzM3FtSpFAmH4N0rw8XvkNY YNA10JPuJORrFHRFRtT9orliIb5JHofx2ia/OPmLMOS43cpEjN01n8lOAtoTexYS NuTskTce4wyyPEJFre9Pl6IgKJTaA5hNt8R2UUEnQrtCzXPtlYh9r8cF3axj/FtV pmzVKRrsEMYV7AJFz18sSbi31GM/n/Usvj9z1znmNGgZeyFYqxhYXbe3L9mEwH7I u7Ecrg8o8sLfLlP/MTm3prXHgcAwus0EavjhyuAG4teRfSQ7MOmTAHHXc3hlwGg/ iFOWdYZIOXSlcGOKIwuAuQTXwgf337lG93QhHhZWtimSVip44tebyLDLZWB3T8Uw 93D0rzXuk8YPogRPtquKtpxglpM64MGF8Z37J5U67D2PRwWJyfPetolED5nkc5Gz 831h4vt4mKxeti0paOc91ruxuU5YYB0umMox6QJ1G35G+8b23BcszHtc/Cwehbvj qFTC0E4OT8VVmScbP+yu9YkM8yLPTnHur9cjh5ocvk18MpqpDWctiQD4WsOWxLIH zplTZNhj5QH6rq8KTzv09OIgp+jtLHkymtL0grU9N4jzuIr0RQM= =ZJe2 -----END PGP SIGNATURE----- Merge tag 'nfs-for-7.2-3' of git://git.linux-nfs.org/projects/anna/linux-nfs Pull NFS client fixes from Anna Schumaker: - Pin the 'struct nfs_server' during a FREE_STATEID call - Decrement refcounts if allocating nfs_free_stateid_data fails - Fix nfs4_listxattr size accounting for * tag 'nfs-for-7.2-3' of git://git.linux-nfs.org/projects/anna/linux-nfs: NFSv4.2: fix nfs4_listxattr size accounting NFS: Decrement refcounts if allocating nfs_free_stateid_data fails NFS: Pin the 'struct nfs_server' during a FREE_STATEID call |
||
Mimi Zohar
|
b80bed5c87 |
ima: Instantiate file_truncate and path_truncate hooks
Instantiate the file_truncate and path_truncate LSM hooks to reset the action cache flags (IMA_DONE_MASK) as soon as truncation is requested, so the file, based on policy, is re-collected, re-measured, re-audited, and re-appraised on next access. Tested-by: Frederick Lawler <fred@cloudflare.com> Cc: stable@vger.kernel.org Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> |
||
Lincoln Wallace
|
5ff232d311 |
ima: fix out-of-bounds read in xattr_verify()
The digest-length check in xattr_verify() mixes int and size_t:
if (xattr_len - sizeof(xattr_value->type) - hash_start >=
iint->ima_hash->length)
sizeof() yields size_t, so the usual arithmetic conversions promote
the whole left-hand side to unsigned 64-bit before the subtraction
runs. For a truncated xattr this underflows instead of going negative:
a 1-byte IMA_XATTR_DIGEST_NG xattr (xattr_len == 1, hash_start == 1)
turns "1 - 1 - 1" into SIZE_MAX, which is trivially >= ima_hash->length.
The check then passes and the following memcmp() reads
iint->ima_hash->length bytes starting past the end of the buffer
vfs_getxattr_alloc() allocated for it.
Nothing upstream clamps xattr_len back into a safe range first:
ima_get_hash_algo() only special-cases xattr_len < 2 to pick a default
algorithm, and evm_verifyxattr() returns INTEGRITY_UNKNOWN rather than
failing when no HMAC key is loaded, so a truncated security.ima value
reaches the length check as-is.
Rewrite the comparison so every operand stays a signed int and no
implicit conversion to size_t can occur.
Fixes:
|
||
Baul Lee
|
2615f0fb90 |
ALSA: us144mkii: re-anchor capture URBs on resubmission
capture_urb_complete() resubmits each capture URB without anchoring it:
usb_get_urb(urb);
ret = usb_submit_urb(urb, GFP_ATOMIC);
Anchoring is a property of a submission, not of the URB. The giveback
path calls usb_unanchor_urb() before urb->complete(), so an URB
resubmitted from its own completion handler is off the anchor. The
capture URBs are anchored once, at stream start, so from the first
completion onward tascam->capture_anchor is empty.
tascam_free_urbs(), tascam_disconnect(), tascam_suspend() and the
stop-work path all call usb_kill_anchored_urbs(&tascam->capture_anchor)
to reap the capture URBs before anything is freed. With the anchor empty
those calls return immediately and the URBs stay queued on the host
controller.
tascam_free_urbs() then returns the capture transfer buffers with
usb_free_coherent(), and snd_card_free() releases the snd_card
allocation that embeds tascam (card->private_data). The controller
completes the queued URBs afterwards, writing device-supplied data into
the freed transfer buffer, and capture_urb_complete() dereferences the
freed driver object.
KASAN on 7.2.0-rc5 (arm64):
BUG: KASAN: slab-use-after-free in dummy_timer
Write of size 512 at addr ffff000015b62000
__asan_memcpy
dummy_timer
hrtimer_run_softirq
Allocated by task 64:
usb_alloc_coherent
tascam_alloc_urbs
tascam_probe
Freed by task 170:
usb_free_coherent
tascam_free_urbs
tascam_disconnect
usb_unbind_interface
BUG: KASAN: slab-use-after-free in capture_urb_complete
Read of size 4 at addr ffff0000170ee878
Freed by task 170:
release_card_device
snd_card_free
tascam_disconnect
Restore the usb_anchor_urb() between the reference count bump and the
resubmission. That also makes the handler's usb_unanchor_urb() failure
arm meaningful again and restores usb_kill_anchored_urbs() as a barrier
on the disconnect, suspend and stop-work paths.
The anchoring was removed on the premise that the URB is already anchored
from the initial submission, which does not hold once the first giveback
has run.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
Fixes:
|
||
|
Baul Lee
|
620f1e52a4 |
ALSA: FCP: fix OOB write in fcp_meter_ctl_get()
fcp_ioctl_set_meter_map() bounds the user-supplied Level Meter map size
by the driver's own limit of 255
if (map.map_size < 1 || map.map_size > 255 ||
map.meter_slots < 1 || map.meter_slots > 255)
return -EINVAL;
and passes it to fcp_add_new_ctl() as the control's channel count, where
it is stored as elem->channels.
Every control read writes into struct snd_ctl_elem_value, whose integer
array is declared long value[128], so the limit is 128, not 255.
fcp_meter_ctl_get() stores one 64-bit word per channel into that array
with no bound of its own:
for (i = 0; i < elem->channels; i++) {
int idx = private->meter_level_map[i];
int value = idx < 0 ? 0 : le32_to_cpu(resp[idx]);
ucontrol->value.integer.value[i] = value;
}
snd_ctl_elem_read_user() serves that object from
memdup_user(_control, sizeof(*control)), 1224 bytes on LP64 out of
kmalloc-2048. offsetof(struct snd_ctl_elem_value, value) is 72, so
element i is written at byte 72 + 8 * i and element 144 already lands
past the allocation. At map_size 255 the last store ends at byte 2112,
888 bytes past the object and 64 bytes into the adjacent slab object.
The stored words come from the device and meter_level_map[] selects
which word lands in which slot, so extent and contents are both
controlled.
The core does not catch this. snd_ctl_check_elem_info() is reached only
from __snd_ctl_elem_info(), which snd_ctl_elem_read() calls under
CONFIG_SND_CTL_DEBUG; without that option snd_ctl_skip_validation() is a
compile-time true. __snd_ctl_add_replace() validates kcontrol->count and
never inspects elem->channels.
Installing an oversized map needs CAP_SYS_RAWIO, but the control outlives
the hwdep descriptor that created it, so the out-of-bounds stores are
issued by any process able to read controls on /dev/snd/controlC0.
KASAN on 7.2.0-rc5 (arm64), triggered by an unprivileged control read:
BUG: KASAN: slab-out-of-bounds in fcp_meter_ctl_get
Write of size 8 at addr ffff000017af04c8 by task fcp_trigger/185
__asan_store8
fcp_meter_ctl_get
snd_ctl_elem_read
snd_ctl_ioctl
Allocated by task 185:
memdup_user
snd_ctl_ioctl
The buggy address is located 0 bytes to the right of
allocated 1224-byte region [ffff000017af0000, ffff000017af04c8)
Bound the map size by the ABI limit rather than by 255, and bound the
store loop at the sink so it cannot run past the value array whatever
elem->channels holds.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
Fixes:
|