| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
[ Upstream commit 840738eae94864993a735ab677b9795bb8f3b961 ]
Commit 8bd25b61c5a5 ("smb: client: set correct d_type for reparse DFS/DFSR
and mount point") deduplicated assignment of fattr->cf_dtype member from
all places to end of the function cifs_reparse_point_to_fattr(). The only
one missing place which was not deduplicated is wsl_to_fattr(). Fix it.
Fixes: 8bd25b61c5a5 ("smb: client: set correct d_type for reparse DFS/DFSR and mount point")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit bbf10cd686835d5a4b8566dc73a3b00b4cd7932a ]
Commit c3be50f7547c ("PCI: pciehp: Ignore Presence Detect Changed caused by
DPC") sought to ignore Presence Detect Changed events occurring as a side
effect of Downstream Port Containment.
The commit awaits recovery from DPC and then clears events which occurred
in the meantime. However if the first event seen after DPC is Data Link
Layer State Changed, only that event is cleared and not Presence Detect
Changed. The object of the commit is thus defeated.
That's because pciehp_ist() computes the events to clear based on the local
"events" variable instead of "ctrl->pending_events". The former contains
the events that had occurred when pciehp_ist() was entered, whereas the
latter also contains events that have accumulated while awaiting DPC
recovery.
In practice, the order of PDC and DLLSC events is arbitrary and the delay
in-between can be several milliseconds.
So change the logic to always clear PDC events, even if they come after an
initial DLLSC event.
Fixes: c3be50f7547c ("PCI: pciehp: Ignore Presence Detect Changed caused by DPC")
Reported-by: Lương Việt Hoàng <tcm4095@gmail.com>
Reported-by: Joel Mathew Thomas <proxy0@tutamail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219765#c165
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Lương Việt Hoàng <tcm4095@gmail.com>
Tested-by: Joel Mathew Thomas <proxy0@tutamail.com>
Link: https://patch.msgid.link/d9c4286a16253af7e93eaf12e076e3ef3546367a.1750257164.git.lukas@wunner.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 10af0273a35ab4513ca1546644b8c853044da134 ]
The gpio-mlxbf3 driver interfaces with two GPIO controllers,
device instance 0 and 1. There is a single IRQ resource shared
between the two controllers, and it is found in the ACPI table for
device instance 0. The driver should not attempt to get an IRQ
resource when probing device instance 1, otherwise the following
error is logged:
mlxbf3_gpio MLNXBF33:01: error -ENXIO: IRQ index 0 not found
Signed-off-by: David Thompson <davthompson@nvidia.com>
Reviewed-by: Shravan Kumar Ramani <shravankr@nvidia.com>
Fixes: cd33f216d241 ("gpio: mlxbf3: Add gpio driver support")
Link: https://lore.kernel.org/r/20250613163443.1065217-1-davthompson@nvidia.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit dba90f5a79c13936de4273a19e67908a0c296afe ]
Dual and quad capable chips natively support dual and quad I/O variants
at up to 104MHz (1-2-2 and 1-4-4 operations). Reaching the maximum speed
of 166MHz is theoretically possible (while still unsupported in the
field) by adding a few more dummy cycles. Let's be accurate and clearly
state this limit.
Setting a maximum frequency implies adding the frequency parameter to
the macro, which is done using a variadic argument to avoid impacting
all the other drivers which already make use of this macro.
Fixes: 1ea808b4d15b ("mtd: spinand: winbond: Update the *JW chip definitions")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 9c6911072c6e8b128ccdb7dd00efa13c47513074 ]
SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supporting dual and
quad I/O transfers have been added on top, generally inspired by vendor
naming, followed by DTR operations. Soon we might see octal
and even octal DTR operations as well (including the opcode byte).
Let's clarify what the macro really mean by describing the expected bus
topology in the (quad IO) read from cache macro names.
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 1deae734cc1c7e976d588e7d8f46af2bb9ef5656 ]
SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supporting dual and
quad I/O transfers have been added on top, generally inspired by vendor
naming, followed by DTR operations. Soon we might see octal
and even octal DTR operations as well (including the opcode byte).
Let's clarify what the macro really mean by describing the expected bus
topology in the (quad output) read from cache macro names.
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit d9de177996d74c0cc44220003953ba2d2bece0ac ]
SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supporting dual and
quad I/O transfers have been added on top, generally inspired by vendor
naming, followed by DTR operations. Soon we might see octal
and even octal DTR operations as well (including the opcode byte).
Let's clarify what the macro really mean by describing the expected bus
topology in the (dual IO) read from cache macro names. While at
modifying them, better reordering the macros to group them all by bus
topology which now feels more intuitive.
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 684f7105e8534f6500de389c089ba204cb1c8058 ]
SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supporting dual and
quad I/O transfers have been added on top, generally inspired by vendor
naming, followed by DTR operations. Soon we might see octal
and even octal DTR operations as well (including the opcode byte).
Let's clarify what the macro really mean by describing the expected bus
topology in the (dual output) read from cache macro names.
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit ea2087d4e66d0b927918cc9048576aca6a0446ad ]
SPI operations have been initially described through macros implicitly
implying the use of a single SPI SDR bus. Macros for supporting dual and
quad I/O transfers have been added on top, generally inspired by vendor
naming, followed by DTR operations. Soon we might see octal
and even octal DTR operations as well (including the opcode byte).
Let's clarify what the macro really mean by describing the expected bus
topology in the (single) read from cache macro names.
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Stable-dep-of: dba90f5a79c1 ("mtd: spinand: winbond: Prevent unsupported frequencies on dual/quad I/O variants")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit cb6075bc62dc6a9cd7ab3572758685fdf78e3e20 ]
The INVLPGB instruction has limits on how many pages it can invalidate
at once. That limit is enumerated in CPUID, read by the kernel, and
stored in 'invpgb_count_max'. Ranged invalidation, like
invlpgb_kernel_range_flush() break up their invalidations so
that they do not exceed the limit.
However, early boot code currently attempts to do ranged
invalidation before populating 'invlpgb_count_max'. There is a
for loop which is basically:
for (...; addr < end; addr += invlpgb_count_max*PAGE_SIZE)
If invlpgb_kernel_range_flush is called before the kernel has read
the value of invlpgb_count_max from the hardware, the normally
bounded loop can become an infinite loop if invlpgb_count_max is
initialized to zero.
Fix that issue by initializing invlpgb_count_max to 1.
This way INVPLGB at early boot time will be a little bit slower
than normal (with initialized invplgb_count_max), and not an
instant hang at bootup time.
Fixes: b7aa05cbdc52 ("x86/mm: Add INVLPGB support code")
Signed-off-by: Rik van Riel <riel@surriel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Link: https://lore.kernel.org/all/20250606171112.4013261-3-riel%40surriel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 19f4422d485b2d0a935117a1a16015328f99be25 ]
Add missed close when iterating over the script directories.
Fixes: f3295f5b067d3c26 ("perf tests: Use scandirat for shell script finding")
Signed-off-by: Ian Rogers <irogers@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
Link: https://lore.kernel.org/r/20250614004108.1650988-1-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit ebec62bc7ec435b475722a5467d67c720a1ad79f ]
Add missing close() to avoid leaking perf events.
In past perfs this mattered little as the function was just used by 'perf
list'.
As the function is now used to detect hybrid PMUs leaking the perf event
is somewhat more painful.
Fixes: b41f1cec91c37eee ("perf list: Skip unsupported events")
Signed-off-by: Ian Rogers <irogers@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
Link: https://lore.kernel.org/r/20250614004108.1650988-2-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 0a1db19f66c0960eb00e1f2ccd40708b6747f5b1 ]
The second argument to dev_err_probe() is the error value. Pass the
return value of devm_request_threaded_irq() there instead of the irq
number.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Fixes: c47f7ff0fe61 ("gpio: pca953x: Utilise dev_err_probe() where it makes sense")
Link: https://lore.kernel.org/r/20250616134503.1201138-1-s.hauer@pengutronix.de
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 2e7be162996640bbe3b6da694cc064c511b8a5d9 ]
The SBI specification clearly states that SBI HFENCE calls should
return SBI_ERR_NOT_SUPPORTED when one of the target hart doesn’t
support hypervisor extension (aka nested virtualization in-case
of KVM RISC-V).
Fixes: c7fa3c48de86 ("RISC-V: KVM: Treat SBI HFENCE calls as NOPs")
Reviewed-by: Atish Patra <atishp@rivosinc.com>
Signed-off-by: Anup Patel <apatel@ventanamicro.com>
Link: https://lore.kernel.org/r/20250605061458.196003-3-apatel@ventanamicro.com
Signed-off-by: Anup Patel <anup@brainfault.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 6aba0cb5bba6141158d5449f2cf53187b7f755f9 ]
As-per the SBI specification, an SBI remote fence operation applies
to the entire address space if either:
1) start_addr and size are both 0
2) size is equal to 2^XLEN-1
>From the above, only #1 is checked by SBI SFENCE calls so fix the
size parameter check in SBI SFENCE calls to cover #2 as well.
Fixes: 13acfec2dbcc ("RISC-V: KVM: Add remote HFENCE functions based on VCPU requests")
Reviewed-by: Atish Patra <atishp@rivosinc.com>
Signed-off-by: Anup Patel <apatel@ventanamicro.com>
Link: https://lore.kernel.org/r/20250605061458.196003-2-apatel@ventanamicro.com
Signed-off-by: Anup Patel <anup@brainfault.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 2a8a5a5dd06eef580f9818567773fd75057cb875 ]
strsep() modifies the address of the pointer passed to it so that it no
longer points to the original address. This means kfree() gets the wrong
pointer.
Fix this by passing unmodified pointer returned from kstrdup() to
kfree().
Found by Linux Verification Center (linuxtesting.org) with Svace.
Fixes: 4df84e846624 ("scsi: elx: efct: Driver initialization routines")
Signed-off-by: Vitaliy Shevtsov <v.shevtsov@mt-integration.ru>
Link: https://lore.kernel.org/r/20250612163616.24298-1-v.shevtsov@mt-integration.ru
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 39dfc971e42d886e7df01371cd1bef505076d84c ]
KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth().
Call Trace:
[ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8
[ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550
[ 97.285732]
[ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11
[ 97.287032] Hardware name: linux,dummy-virt (DT)
[ 97.287815] Call trace:
[ 97.288279] dump_backtrace+0xa0/0x128
[ 97.288946] show_stack+0x20/0x38
[ 97.289551] dump_stack_lvl+0x78/0xc8
[ 97.290203] print_address_description.constprop.0+0x84/0x3c8
[ 97.291159] print_report+0xb0/0x280
[ 97.291792] kasan_report+0x84/0xd0
[ 97.292421] __asan_load8+0x9c/0xc0
[ 97.293042] regs_get_kernel_stack_nth+0xa8/0xc8
[ 97.293835] process_fetch_insn+0x770/0xa30
[ 97.294562] kprobe_trace_func+0x254/0x3b0
[ 97.295271] kprobe_dispatcher+0x98/0xe0
[ 97.295955] kprobe_breakpoint_handler+0x1b0/0x210
[ 97.296774] call_break_hook+0xc4/0x100
[ 97.297451] brk_handler+0x24/0x78
[ 97.298073] do_debug_exception+0xac/0x178
[ 97.298785] el1_dbg+0x70/0x90
[ 97.299344] el1h_64_sync_handler+0xcc/0xe8
[ 97.300066] el1h_64_sync+0x78/0x80
[ 97.300699] kernel_clone+0x0/0x500
[ 97.301331] __arm64_sys_clone+0x70/0x90
[ 97.302084] invoke_syscall+0x68/0x198
[ 97.302746] el0_svc_common.constprop.0+0x11c/0x150
[ 97.303569] do_el0_svc+0x38/0x50
[ 97.304164] el0_svc+0x44/0x1d8
[ 97.304749] el0t_64_sync_handler+0x100/0x130
[ 97.305500] el0t_64_sync+0x188/0x190
[ 97.306151]
[ 97.306475] The buggy address belongs to stack of task 1.sh/2550
[ 97.307461] and is located at offset 0 in frame:
[ 97.308257] __se_sys_clone+0x0/0x138
[ 97.308910]
[ 97.309241] This frame has 1 object:
[ 97.309873] [48, 184) 'args'
[ 97.309876]
[ 97.310749] The buggy address belongs to the virtual mapping at
[ 97.310749] [ffff800089270000, ffff800089279000) created by:
[ 97.310749] dup_task_struct+0xc0/0x2e8
[ 97.313347]
[ 97.313674] The buggy address belongs to the physical page:
[ 97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a
[ 97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff)
[ 97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000
[ 97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
[ 97.319445] page dumped because: kasan: bad access detected
[ 97.320371]
[ 97.320694] Memory state around the buggy address:
[ 97.321511] ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 97.322681] ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 97.323846] >ffff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00
[ 97.325023] ^
[ 97.325683] ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3
[ 97.326856] ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
This issue seems to be related to the behavior of some gcc compilers and
was also fixed on the s390 architecture before:
commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()")
As described in that commit, regs_get_kernel_stack_nth() has confirmed that
`addr` is on the stack, so reading the value at `*addr` should be allowed.
Use READ_ONCE_NOCHECK() helper to silence the KASAN check for this case.
Fixes: 0a8ea52c3eb1 ("arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature")
Signed-off-by: Tengda Wu <wutengda@huaweicloud.com>
Link: https://lore.kernel.org/r/20250604005533.1278992-1-wutengda@huaweicloud.com
[will: Use '*addr' as the argument to READ_ONCE_NOCHECK()]
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 3172fb986666dfb71bf483b6d3539e1e587fa197 ]
There may be concurrency between perf_cgroup_switch and
perf_cgroup_event_disable. Consider the following scenario: after a new
perf cgroup event is created on CPU0, the new event may not trigger
a reprogramming, causing ctx->is_active to be 0. In this case, when CPU1
disables this perf event, it executes __perf_remove_from_context->
list _del_event->perf_cgroup_event_disable on CPU1, which causes a race
with perf_cgroup_switch running on CPU0.
The following describes the details of this concurrency scenario:
CPU0 CPU1
perf_cgroup_switch:
...
# cpuctx->cgrp is not NULL here
if (READ_ONCE(cpuctx->cgrp) == NULL)
return;
perf_remove_from_context:
...
raw_spin_lock_irq(&ctx->lock);
...
# ctx->is_active == 0 because reprogramm is not
# tigger, so CPU1 can do __perf_remove_from_context
# for CPU0
__perf_remove_from_context:
perf_cgroup_event_disable:
...
if (--ctx->nr_cgroups)
...
# this warning will happened because CPU1 changed
# ctx.nr_cgroups to 0.
WARN_ON_ONCE(cpuctx->ctx.nr_cgroups == 0);
[peterz: use guard instead of goto unlock]
Fixes: db4a835601b7 ("perf/core: Set cgroup in CPU contexts for new cgroup events")
Signed-off-by: Luo Gengkun <luogengkun@huaweicloud.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20250604033924.3914647-3-luogengkun@huaweicloud.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 61988e36dc5457cdff7ae7927e8d9ad1419ee998 ]
While chasing down a missing perf_cgroup_event_disable() elsewhere,
Leo Yan found that both perf_put_aux_event() and
perf_remove_sibling_event() were also missing one.
Specifically, the rule is that events that switch to OFF,ERROR need to
call perf_cgroup_event_disable().
Unify the disable paths to ensure this.
Fixes: ab43762ef010 ("perf: Allow normal events to output AUX data")
Fixes: 9f0c4fa111dc ("perf/core: Add a new PERF_EV_CAP_SIBLING event capability")
Reported-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20250605123343.GD35970@noisy.programming.kicks-ass.net
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 4f6fc782128355931527cefe3eb45338abd8ab39 ]
Baisheng Gao reported an ARM64 crash, which Mark decoded as being a
synchronous external abort -- most likely due to trying to access
MMIO in bad ways.
The crash further shows perf trying to do a user stack sample while in
exit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the address
space it is trying to access.
It turns out that we stop perf after we tear down the userspace mm; a
receipie for disaster, since perf likes to access userspace for
various reasons.
Flip this order by moving up where we stop perf in do_exit().
Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USER
to abort when the current task does not have an mm (exit_mm() makes
sure to set current->mm = NULL; before commencing with the actual
teardown). Such that CPU wide events don't trip on this same problem.
Fixes: c5ebcedb566e ("perf: Add ability to attach user stack dump to sample")
Reported-by: Baisheng Gao <baisheng.gao@unisoc.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20250605110815.GQ39944@noisy.programming.kicks-ass.net
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 553ab30a181043f01b99a493ba13f9c011eb75ae upstream.
GSP message queue docs has been moved following RPC handling split in
commit 8a8b1ec5261f20 ("drm/nouveau/gsp: split rpc handling out on its
own"), before GSP-RM implementation is versioned in commit c472d828348caf
("drm/nouveau/gsp: move subdev/engine impls to subdev/gsp/rm/r535/").
However, the kernel-doc reference in nouveau docs is left behind, which
triggers htmldocs warnings:
ERROR: Cannot find file ./drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
WARNING: No kernel-doc for file ./drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c
Update the reference.
Fixes: c472d828348c ("drm/nouveau/gsp: move subdev/engine impls to subdev/gsp/rm/r535/")
Fixes: 8a8b1ec5261f ("drm/nouveau/gsp: split rpc handling out on its own")
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20250611020805.22418-2-bagasdotme@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8a157d8a00e815cab4432653cb50c9cedbbb4931 upstream.
The variable "head" is allocated and initialized as a list before
allocating the first "item" for the list. If the allocation of "item"
fails, it frees "head" and then jumps to the label "free_now" which will
process head and free it.
This will cause a UAF of "head", and it doesn't need to free it before
jumping to the "free_now" label as that code will free it.
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Link: https://lore.kernel.org/20250610093348.33c5643a@gandalf.local.home
Fixes: a9d0aab5eb33 ("tracing: Fix regression of filter waiting a long time on RCU synchronization")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/202506070424.lCiNreTI-lkp@intel.com/
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 85f6d5b729eaace1549f1dcc284d9865f2c3ec02 upstream.
dm_set_device_limits() should check q->limits.features for
BLK_FEAT_ATOMIC_WRITES while holding q->limits_lock, like it does for
the rest of the queue limits.
Fixes: b7c18b17a173 ("dm-table: Set BLK_FEAT_ATOMIC_WRITES for target queue limits")
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3c902383f2da91cba3821b73aa6edd49f4db6023 upstream.
Commit a82b26451de1 ("x86/its: explicitly manage permissions for ITS
pages") reworks its_alloc() and introduces a typo in an ifdef
conditional, referring to CONFIG_MODULE instead of CONFIG_MODULES.
Fix this typo in its_alloc().
Fixes: a82b26451de1 ("x86/its: explicitly manage permissions for ITS pages")
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Link: https://lore.kernel.org/all/20250616100432.22941-1-lukas.bulwahn%40redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 88efa0de3285be66969b71ec137d9dab1ee19e52 upstream.
A kernel panic was reported with the following kernel log:
EDAC igen6: Expected 2 mcs, but only 1 detected.
BUG: unable to handle page fault for address: 000000000000d570
...
Hardware name: Notebook V54x_6x_TU/V54x_6x_TU, BIOS Dasharo (coreboot+UEFI) v0.9.0 07/17/2024
RIP: e030:ecclog_handler+0x7e/0xf0 [igen6_edac]
...
igen6_probe+0x2a0/0x343 [igen6_edac]
...
igen6_init+0xc5/0xff0 [igen6_edac]
...
This issue occurred because one memory controller was disabled by
the BIOS but the igen6_edac driver still checked all the memory
controllers, including this absent one, to identify the source of
the error. Accessing the null MMIO for the absent memory controller
resulted in the oops above.
Fix this issue by reverting the configuration structure to non-const
and updating the field 'res_cfg->num_imc' to reflect the number of
detected memory controllers.
Fixes: 20e190b1c1fd ("EDAC/igen6: Skip absent memory controllers")
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Closes: https://lore.kernel.org/all/aFFN7RlXkaK_loQb@mail-itl/
Suggested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Link: https://lore.kernel.org/r/20250618162307.1523736-1-qiuxu.zhuo@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a379a8a2a0032e12e7ef397197c9c2ad011588d6 upstream.
This fixes the following problem:
[ 749.901015] [ T8673] run fstests cifs/001 at 2025-06-17 09:40:30
[ 750.346409] [ T9870] ==================================================================
[ 750.346814] [ T9870] BUG: KASAN: slab-out-of-bounds in smb_set_sge+0x2cc/0x3b0 [cifs]
[ 750.347330] [ T9870] Write of size 8 at addr ffff888011082890 by task xfs_io/9870
[ 750.347705] [ T9870]
[ 750.348077] [ T9870] CPU: 0 UID: 0 PID: 9870 Comm: xfs_io Kdump: loaded Not tainted 6.16.0-rc2-metze.02+ #1 PREEMPT(voluntary)
[ 750.348082] [ T9870] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 750.348085] [ T9870] Call Trace:
[ 750.348086] [ T9870] <TASK>
[ 750.348088] [ T9870] dump_stack_lvl+0x76/0xa0
[ 750.348106] [ T9870] print_report+0xd1/0x640
[ 750.348116] [ T9870] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 750.348120] [ T9870] ? kasan_complete_mode_report_info+0x26/0x210
[ 750.348124] [ T9870] kasan_report+0xe7/0x130
[ 750.348128] [ T9870] ? smb_set_sge+0x2cc/0x3b0 [cifs]
[ 750.348262] [ T9870] ? smb_set_sge+0x2cc/0x3b0 [cifs]
[ 750.348377] [ T9870] __asan_report_store8_noabort+0x17/0x30
[ 750.348381] [ T9870] smb_set_sge+0x2cc/0x3b0 [cifs]
[ 750.348496] [ T9870] smbd_post_send_iter+0x1990/0x3070 [cifs]
[ 750.348625] [ T9870] ? __pfx_smbd_post_send_iter+0x10/0x10 [cifs]
[ 750.348741] [ T9870] ? update_stack_state+0x2a0/0x670
[ 750.348749] [ T9870] ? cifs_flush+0x153/0x320 [cifs]
[ 750.348870] [ T9870] ? cifs_flush+0x153/0x320 [cifs]
[ 750.348990] [ T9870] ? update_stack_state+0x2a0/0x670
[ 750.348995] [ T9870] smbd_send+0x58c/0x9c0 [cifs]
[ 750.349117] [ T9870] ? __pfx_smbd_send+0x10/0x10 [cifs]
[ 750.349231] [ T9870] ? unwind_get_return_address+0x65/0xb0
[ 750.349235] [ T9870] ? __pfx_stack_trace_consume_entry+0x10/0x10
[ 750.349242] [ T9870] ? arch_stack_walk+0xa7/0x100
[ 750.349250] [ T9870] ? stack_trace_save+0x92/0xd0
[ 750.349254] [ T9870] __smb_send_rqst+0x931/0xec0 [cifs]
[ 750.349374] [ T9870] ? kernel_text_address+0x173/0x190
[ 750.349379] [ T9870] ? kasan_save_stack+0x39/0x70
[ 750.349382] [ T9870] ? kasan_save_track+0x18/0x70
[ 750.349385] [ T9870] ? __kasan_slab_alloc+0x9d/0xa0
[ 750.349389] [ T9870] ? __pfx___smb_send_rqst+0x10/0x10 [cifs]
[ 750.349508] [ T9870] ? smb2_mid_entry_alloc+0xb4/0x7e0 [cifs]
[ 750.349626] [ T9870] ? cifs_call_async+0x277/0xb00 [cifs]
[ 750.349746] [ T9870] ? cifs_issue_write+0x256/0x610 [cifs]
[ 750.349867] [ T9870] ? netfs_do_issue_write+0xc2/0x340 [netfs]
[ 750.349900] [ T9870] ? netfs_advance_write+0x45b/0x1270 [netfs]
[ 750.349929] [ T9870] ? netfs_write_folio+0xd6c/0x1be0 [netfs]
[ 750.349958] [ T9870] ? netfs_writepages+0x2e9/0xa80 [netfs]
[ 750.349987] [ T9870] ? do_writepages+0x21f/0x590
[ 750.349993] [ T9870] ? filemap_fdatawrite_wbc+0xe1/0x140
[ 750.349997] [ T9870] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 750.350002] [ T9870] smb_send_rqst+0x22e/0x2f0 [cifs]
[ 750.350131] [ T9870] ? __pfx_smb_send_rqst+0x10/0x10 [cifs]
[ 750.350255] [ T9870] ? local_clock_noinstr+0xe/0xd0
[ 750.350261] [ T9870] ? kasan_save_alloc_info+0x37/0x60
[ 750.350268] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.350271] [ T9870] ? _raw_spin_lock+0x81/0xf0
[ 750.350275] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10
[ 750.350278] [ T9870] ? smb2_setup_async_request+0x293/0x580 [cifs]
[ 750.350398] [ T9870] cifs_call_async+0x477/0xb00 [cifs]
[ 750.350518] [ T9870] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]
[ 750.350636] [ T9870] ? __pfx_cifs_call_async+0x10/0x10 [cifs]
[ 750.350756] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10
[ 750.350760] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.350763] [ T9870] ? __smb2_plain_req_init+0x933/0x1090 [cifs]
[ 750.350891] [ T9870] smb2_async_writev+0x15ff/0x2460 [cifs]
[ 750.351008] [ T9870] ? sched_clock_noinstr+0x9/0x10
[ 750.351012] [ T9870] ? local_clock_noinstr+0xe/0xd0
[ 750.351018] [ T9870] ? __pfx_smb2_async_writev+0x10/0x10 [cifs]
[ 750.351144] [ T9870] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 750.351150] [ T9870] ? _raw_spin_unlock+0xe/0x40
[ 750.351154] [ T9870] ? cifs_pick_channel+0x242/0x370 [cifs]
[ 750.351275] [ T9870] cifs_issue_write+0x256/0x610 [cifs]
[ 750.351554] [ T9870] ? cifs_issue_write+0x256/0x610 [cifs]
[ 750.351677] [ T9870] netfs_do_issue_write+0xc2/0x340 [netfs]
[ 750.351710] [ T9870] netfs_advance_write+0x45b/0x1270 [netfs]
[ 750.351740] [ T9870] ? rolling_buffer_append+0x12d/0x440 [netfs]
[ 750.351769] [ T9870] netfs_write_folio+0xd6c/0x1be0 [netfs]
[ 750.351798] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.351804] [ T9870] netfs_writepages+0x2e9/0xa80 [netfs]
[ 750.351835] [ T9870] ? __pfx_netfs_writepages+0x10/0x10 [netfs]
[ 750.351864] [ T9870] ? exit_files+0xab/0xe0
[ 750.351867] [ T9870] ? do_exit+0x148f/0x2980
[ 750.351871] [ T9870] ? do_group_exit+0xb5/0x250
[ 750.351874] [ T9870] ? arch_do_signal_or_restart+0x92/0x630
[ 750.351879] [ T9870] ? exit_to_user_mode_loop+0x98/0x170
[ 750.351882] [ T9870] ? do_syscall_64+0x2cf/0xd80
[ 750.351886] [ T9870] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 750.351890] [ T9870] do_writepages+0x21f/0x590
[ 750.351894] [ T9870] ? __pfx_do_writepages+0x10/0x10
[ 750.351897] [ T9870] filemap_fdatawrite_wbc+0xe1/0x140
[ 750.351901] [ T9870] __filemap_fdatawrite_range+0xba/0x100
[ 750.351904] [ T9870] ? __pfx___filemap_fdatawrite_range+0x10/0x10
[ 750.351912] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.351916] [ T9870] filemap_write_and_wait_range+0x7d/0xf0
[ 750.351920] [ T9870] cifs_flush+0x153/0x320 [cifs]
[ 750.352042] [ T9870] filp_flush+0x107/0x1a0
[ 750.352046] [ T9870] filp_close+0x14/0x30
[ 750.352049] [ T9870] put_files_struct.part.0+0x126/0x2a0
[ 750.352053] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10
[ 750.352058] [ T9870] exit_files+0xab/0xe0
[ 750.352061] [ T9870] do_exit+0x148f/0x2980
[ 750.352065] [ T9870] ? __pfx_do_exit+0x10/0x10
[ 750.352069] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.352072] [ T9870] ? _raw_spin_lock_irq+0x8a/0xf0
[ 750.352076] [ T9870] do_group_exit+0xb5/0x250
[ 750.352080] [ T9870] get_signal+0x22d3/0x22e0
[ 750.352086] [ T9870] ? __pfx_get_signal+0x10/0x10
[ 750.352089] [ T9870] ? fpregs_assert_state_consistent+0x68/0x100
[ 750.352101] [ T9870] ? folio_add_lru+0xda/0x120
[ 750.352105] [ T9870] arch_do_signal_or_restart+0x92/0x630
[ 750.352109] [ T9870] ? __pfx_arch_do_signal_or_restart+0x10/0x10
[ 750.352115] [ T9870] exit_to_user_mode_loop+0x98/0x170
[ 750.352118] [ T9870] do_syscall_64+0x2cf/0xd80
[ 750.352123] [ T9870] ? __kasan_check_read+0x11/0x20
[ 750.352126] [ T9870] ? count_memcg_events+0x1b4/0x420
[ 750.352132] [ T9870] ? handle_mm_fault+0x148/0x690
[ 750.352136] [ T9870] ? _raw_spin_lock_irq+0x8a/0xf0
[ 750.352140] [ T9870] ? __kasan_check_read+0x11/0x20
[ 750.352143] [ T9870] ? fpregs_assert_state_consistent+0x68/0x100
[ 750.352146] [ T9870] ? irqentry_exit_to_user_mode+0x2e/0x250
[ 750.352151] [ T9870] ? irqentry_exit+0x43/0x50
[ 750.352154] [ T9870] ? exc_page_fault+0x75/0xe0
[ 750.352160] [ T9870] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 750.352163] [ T9870] RIP: 0033:0x7858c94ab6e2
[ 750.352167] [ T9870] Code: Unable to access opcode bytes at 0x7858c94ab6b8.
[ 750.352175] [ T9870] RSP: 002b:00007858c9248ce8 EFLAGS: 00000246 ORIG_RAX: 0000000000000022
[ 750.352179] [ T9870] RAX: fffffffffffffdfe RBX: 00007858c92496c0 RCX: 00007858c94ab6e2
[ 750.352182] [ T9870] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 750.352184] [ T9870] RBP: 00007858c9248d10 R08: 0000000000000000 R09: 0000000000000000
[ 750.352185] [ T9870] R10: 0000000000000000 R11: 0000000000000246 R12: fffffffffffffde0
[ 750.352187] [ T9870] R13: 0000000000000020 R14: 0000000000000002 R15: 00007ffc072d2230
[ 750.352191] [ T9870] </TASK>
[ 750.352195] [ T9870]
[ 750.395206] [ T9870] Allocated by task 9870 on cpu 0 at 750.346406s:
[ 750.395523] [ T9870] kasan_save_stack+0x39/0x70
[ 750.395532] [ T9870] kasan_save_track+0x18/0x70
[ 750.395536] [ T9870] kasan_save_alloc_info+0x37/0x60
[ 750.395539] [ T9870] __kasan_slab_alloc+0x9d/0xa0
[ 750.395543] [ T9870] kmem_cache_alloc_noprof+0x13c/0x3f0
[ 750.395548] [ T9870] mempool_alloc_slab+0x15/0x20
[ 750.395553] [ T9870] mempool_alloc_noprof+0x135/0x340
[ 750.395557] [ T9870] smbd_post_send_iter+0x63e/0x3070 [cifs]
[ 750.395694] [ T9870] smbd_send+0x58c/0x9c0 [cifs]
[ 750.395819] [ T9870] __smb_send_rqst+0x931/0xec0 [cifs]
[ 750.395950] [ T9870] smb_send_rqst+0x22e/0x2f0 [cifs]
[ 750.396081] [ T9870] cifs_call_async+0x477/0xb00 [cifs]
[ 750.396232] [ T9870] smb2_async_writev+0x15ff/0x2460 [cifs]
[ 750.396359] [ T9870] cifs_issue_write+0x256/0x610 [cifs]
[ 750.396492] [ T9870] netfs_do_issue_write+0xc2/0x340 [netfs]
[ 750.396544] [ T9870] netfs_advance_write+0x45b/0x1270 [netfs]
[ 750.396576] [ T9870] netfs_write_folio+0xd6c/0x1be0 [netfs]
[ 750.396608] [ T9870] netfs_writepages+0x2e9/0xa80 [netfs]
[ 750.396639] [ T9870] do_writepages+0x21f/0x590
[ 750.396643] [ T9870] filemap_fdatawrite_wbc+0xe1/0x140
[ 750.396647] [ T9870] __filemap_fdatawrite_range+0xba/0x100
[ 750.396651] [ T9870] filemap_write_and_wait_range+0x7d/0xf0
[ 750.396656] [ T9870] cifs_flush+0x153/0x320 [cifs]
[ 750.396787] [ T9870] filp_flush+0x107/0x1a0
[ 750.396791] [ T9870] filp_close+0x14/0x30
[ 750.396795] [ T9870] put_files_struct.part.0+0x126/0x2a0
[ 750.396800] [ T9870] exit_files+0xab/0xe0
[ 750.396803] [ T9870] do_exit+0x148f/0x2980
[ 750.396808] [ T9870] do_group_exit+0xb5/0x250
[ 750.396813] [ T9870] get_signal+0x22d3/0x22e0
[ 750.396817] [ T9870] arch_do_signal_or_restart+0x92/0x630
[ 750.396822] [ T9870] exit_to_user_mode_loop+0x98/0x170
[ 750.396827] [ T9870] do_syscall_64+0x2cf/0xd80
[ 750.396832] [ T9870] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 750.396836] [ T9870]
[ 750.397150] [ T9870] The buggy address belongs to the object at ffff888011082800
which belongs to the cache smbd_request_0000000008f3bd7b of size 144
[ 750.397798] [ T9870] The buggy address is located 0 bytes to the right of
allocated 144-byte region [ffff888011082800, ffff888011082890)
[ 750.398469] [ T9870]
[ 750.398800] [ T9870] The buggy address belongs to the physical page:
[ 750.399141] [ T9870] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11082
[ 750.399148] [ T9870] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)
[ 750.399155] [ T9870] page_type: f5(slab)
[ 750.399161] [ T9870] raw: 000fffffc0000000 ffff888022d65640 dead000000000122 0000000000000000
[ 750.399165] [ T9870] raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
[ 750.399169] [ T9870] page dumped because: kasan: bad access detected
[ 750.399172] [ T9870]
[ 750.399505] [ T9870] Memory state around the buggy address:
[ 750.399863] [ T9870] ffff888011082780: fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 750.400247] [ T9870] ffff888011082800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 750.400618] [ T9870] >ffff888011082880: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 750.400982] [ T9870] ^
[ 750.401370] [ T9870] ffff888011082900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 750.401774] [ T9870] ffff888011082980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 750.402171] [ T9870] ==================================================================
[ 750.402696] [ T9870] Disabling lock debugging due to kernel taint
[ 750.403202] [ T9870] BUG: unable to handle page fault for address: ffff8880110a2000
[ 750.403797] [ T9870] #PF: supervisor write access in kernel mode
[ 750.404204] [ T9870] #PF: error_code(0x0003) - permissions violation
[ 750.404581] [ T9870] PGD 5ce01067 P4D 5ce01067 PUD 5ce02067 PMD 78aa063 PTE 80000000110a2021
[ 750.404969] [ T9870] Oops: Oops: 0003 [#1] SMP KASAN PTI
[ 750.405394] [ T9870] CPU: 0 UID: 0 PID: 9870 Comm: xfs_io Kdump: loaded Tainted: G B 6.16.0-rc2-metze.02+ #1 PREEMPT(voluntary)
[ 750.406510] [ T9870] Tainted: [B]=BAD_PAGE
[ 750.406967] [ T9870] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 750.407440] [ T9870] RIP: 0010:smb_set_sge+0x15c/0x3b0 [cifs]
[ 750.408065] [ T9870] Code: 48 83 f8 ff 0f 84 b0 00 00 00 48 ba 00 00 00 00 00 fc ff df 4c 89 e1 48 c1 e9 03 80 3c 11 00 0f 85 69 01 00 00 49 8d 7c 24 08 <49> 89 04 24 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 0f
[ 750.409283] [ T9870] RSP: 0018:ffffc90005e2e758 EFLAGS: 00010246
[ 750.409803] [ T9870] RAX: ffff888036c53400 RBX: ffffc90005e2e878 RCX: 1ffff11002214400
[ 750.410323] [ T9870] RDX: dffffc0000000000 RSI: dffffc0000000000 RDI: ffff8880110a2008
[ 750.411217] [ T9870] RBP: ffffc90005e2e798 R08: 0000000000000001 R09: 0000000000000400
[ 750.411770] [ T9870] R10: ffff888011082800 R11: 0000000000000000 R12: ffff8880110a2000
[ 750.412325] [ T9870] R13: 0000000000000000 R14: ffffc90005e2e888 R15: ffff88801a4b6000
[ 750.412901] [ T9870] FS: 0000000000000000(0000) GS:ffff88812bc68000(0000) knlGS:0000000000000000
[ 750.413477] [ T9870] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 750.414077] [ T9870] CR2: ffff8880110a2000 CR3: 000000005b0a6005 CR4: 00000000000726f0
[ 750.414654] [ T9870] Call Trace:
[ 750.415211] [ T9870] <TASK>
[ 750.415748] [ T9870] smbd_post_send_iter+0x1990/0x3070 [cifs]
[ 750.416449] [ T9870] ? __pfx_smbd_post_send_iter+0x10/0x10 [cifs]
[ 750.417128] [ T9870] ? update_stack_state+0x2a0/0x670
[ 750.417685] [ T9870] ? cifs_flush+0x153/0x320 [cifs]
[ 750.418380] [ T9870] ? cifs_flush+0x153/0x320 [cifs]
[ 750.419055] [ T9870] ? update_stack_state+0x2a0/0x670
[ 750.419624] [ T9870] smbd_send+0x58c/0x9c0 [cifs]
[ 750.420297] [ T9870] ? __pfx_smbd_send+0x10/0x10 [cifs]
[ 750.420936] [ T9870] ? unwind_get_return_address+0x65/0xb0
[ 750.421456] [ T9870] ? __pfx_stack_trace_consume_entry+0x10/0x10
[ 750.421954] [ T9870] ? arch_stack_walk+0xa7/0x100
[ 750.422460] [ T9870] ? stack_trace_save+0x92/0xd0
[ 750.422948] [ T9870] __smb_send_rqst+0x931/0xec0 [cifs]
[ 750.423579] [ T9870] ? kernel_text_address+0x173/0x190
[ 750.424056] [ T9870] ? kasan_save_stack+0x39/0x70
[ 750.424813] [ T9870] ? kasan_save_track+0x18/0x70
[ 750.425323] [ T9870] ? __kasan_slab_alloc+0x9d/0xa0
[ 750.425831] [ T9870] ? __pfx___smb_send_rqst+0x10/0x10 [cifs]
[ 750.426548] [ T9870] ? smb2_mid_entry_alloc+0xb4/0x7e0 [cifs]
[ 750.427231] [ T9870] ? cifs_call_async+0x277/0xb00 [cifs]
[ 750.427882] [ T9870] ? cifs_issue_write+0x256/0x610 [cifs]
[ 750.428909] [ T9870] ? netfs_do_issue_write+0xc2/0x340 [netfs]
[ 750.429425] [ T9870] ? netfs_advance_write+0x45b/0x1270 [netfs]
[ 750.429882] [ T9870] ? netfs_write_folio+0xd6c/0x1be0 [netfs]
[ 750.430345] [ T9870] ? netfs_writepages+0x2e9/0xa80 [netfs]
[ 750.430809] [ T9870] ? do_writepages+0x21f/0x590
[ 750.431239] [ T9870] ? filemap_fdatawrite_wbc+0xe1/0x140
[ 750.431652] [ T9870] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 750.432041] [ T9870] smb_send_rqst+0x22e/0x2f0 [cifs]
[ 750.432586] [ T9870] ? __pfx_smb_send_rqst+0x10/0x10 [cifs]
[ 750.433108] [ T9870] ? local_clock_noinstr+0xe/0xd0
[ 750.433482] [ T9870] ? kasan_save_alloc_info+0x37/0x60
[ 750.433855] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.434214] [ T9870] ? _raw_spin_lock+0x81/0xf0
[ 750.434561] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10
[ 750.434903] [ T9870] ? smb2_setup_async_request+0x293/0x580 [cifs]
[ 750.435394] [ T9870] cifs_call_async+0x477/0xb00 [cifs]
[ 750.435892] [ T9870] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]
[ 750.436388] [ T9870] ? __pfx_cifs_call_async+0x10/0x10 [cifs]
[ 750.436881] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10
[ 750.437237] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.437579] [ T9870] ? __smb2_plain_req_init+0x933/0x1090 [cifs]
[ 750.438062] [ T9870] smb2_async_writev+0x15ff/0x2460 [cifs]
[ 750.438557] [ T9870] ? sched_clock_noinstr+0x9/0x10
[ 750.438906] [ T9870] ? local_clock_noinstr+0xe/0xd0
[ 750.439293] [ T9870] ? __pfx_smb2_async_writev+0x10/0x10 [cifs]
[ 750.439786] [ T9870] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 750.440143] [ T9870] ? _raw_spin_unlock+0xe/0x40
[ 750.440495] [ T9870] ? cifs_pick_channel+0x242/0x370 [cifs]
[ 750.440989] [ T9870] cifs_issue_write+0x256/0x610 [cifs]
[ 750.441492] [ T9870] ? cifs_issue_write+0x256/0x610 [cifs]
[ 750.441987] [ T9870] netfs_do_issue_write+0xc2/0x340 [netfs]
[ 750.442387] [ T9870] netfs_advance_write+0x45b/0x1270 [netfs]
[ 750.442969] [ T9870] ? rolling_buffer_append+0x12d/0x440 [netfs]
[ 750.443376] [ T9870] netfs_write_folio+0xd6c/0x1be0 [netfs]
[ 750.443768] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.444145] [ T9870] netfs_writepages+0x2e9/0xa80 [netfs]
[ 750.444541] [ T9870] ? __pfx_netfs_writepages+0x10/0x10 [netfs]
[ 750.444936] [ T9870] ? exit_files+0xab/0xe0
[ 750.445312] [ T9870] ? do_exit+0x148f/0x2980
[ 750.445672] [ T9870] ? do_group_exit+0xb5/0x250
[ 750.446028] [ T9870] ? arch_do_signal_or_restart+0x92/0x630
[ 750.446402] [ T9870] ? exit_to_user_mode_loop+0x98/0x170
[ 750.446762] [ T9870] ? do_syscall_64+0x2cf/0xd80
[ 750.447132] [ T9870] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 750.447499] [ T9870] do_writepages+0x21f/0x590
[ 750.447859] [ T9870] ? __pfx_do_writepages+0x10/0x10
[ 750.448236] [ T9870] filemap_fdatawrite_wbc+0xe1/0x140
[ 750.448595] [ T9870] __filemap_fdatawrite_range+0xba/0x100
[ 750.448953] [ T9870] ? __pfx___filemap_fdatawrite_range+0x10/0x10
[ 750.449336] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.449697] [ T9870] filemap_write_and_wait_range+0x7d/0xf0
[ 750.450062] [ T9870] cifs_flush+0x153/0x320 [cifs]
[ 750.450592] [ T9870] filp_flush+0x107/0x1a0
[ 750.450952] [ T9870] filp_close+0x14/0x30
[ 750.451322] [ T9870] put_files_struct.part.0+0x126/0x2a0
[ 750.451678] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10
[ 750.452033] [ T9870] exit_files+0xab/0xe0
[ 750.452401] [ T9870] do_exit+0x148f/0x2980
[ 750.452751] [ T9870] ? __pfx_do_exit+0x10/0x10
[ 750.453109] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.453459] [ T9870] ? _raw_spin_lock_irq+0x8a/0xf0
[ 750.453787] [ T9870] do_group_exit+0xb5/0x250
[ 750.454082] [ T9870] get_signal+0x22d3/0x22e0
[ 750.454406] [ T9870] ? __pfx_get_signal+0x10/0x10
[ 750.454709] [ T9870] ? fpregs_assert_state_consistent+0x68/0x100
[ 750.455031] [ T9870] ? folio_add_lru+0xda/0x120
[ 750.455347] [ T9870] arch_do_signal_or_restart+0x92/0x630
[ 750.455656] [ T9870] ? __pfx_arch_do_signal_or_restart+0x10/0x10
[ 750.455967] [ T9870] exit_to_user_mode_loop+0x98/0x170
[ 750.456282] [ T9870] do_syscall_64+0x2cf/0xd80
[ 750.456591] [ T9870] ? __kasan_check_read+0x11/0x20
[ 750.456897] [ T9870] ? count_memcg_events+0x1b4/0x420
[ 750.457280] [ T9870] ? handle_mm_fault+0x148/0x690
[ 750.457616] [ T9870] ? _raw_spin_lock_irq+0x8a/0xf0
[ 750.457925] [ T9870] ? __kasan_check_read+0x11/0x20
[ 750.458297] [ T9870] ? fpregs_assert_state_consistent+0x68/0x100
[ 750.458672] [ T9870] ? irqentry_exit_to_user_mode+0x2e/0x250
[ 750.459191] [ T9870] ? irqentry_exit+0x43/0x50
[ 750.459600] [ T9870] ? exc_page_fault+0x75/0xe0
[ 750.460130] [ T9870] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 750.460570] [ T9870] RIP: 0033:0x7858c94ab6e2
[ 750.461206] [ T9870] Code: Unable to access opcode bytes at 0x7858c94ab6b8.
[ 750.461780] [ T9870] RSP: 002b:00007858c9248ce8 EFLAGS: 00000246 ORIG_RAX: 0000000000000022
[ 750.462327] [ T9870] RAX: fffffffffffffdfe RBX: 00007858c92496c0 RCX: 00007858c94ab6e2
[ 750.462653] [ T9870] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 750.462969] [ T9870] RBP: 00007858c9248d10 R08: 0000000000000000 R09: 0000000000000000
[ 750.463290] [ T9870] R10: 0000000000000000 R11: 0000000000000246 R12: fffffffffffffde0
[ 750.463640] [ T9870] R13: 0000000000000020 R14: 0000000000000002 R15: 00007ffc072d2230
[ 750.463965] [ T9870] </TASK>
[ 750.464285] [ T9870] Modules linked in: siw ib_uverbs ccm cmac nls_utf8 cifs cifs_arc4 nls_ucs2_utils rdma_cm iw_cm ib_cm ib_core cifs_md4 netfs softdog vboxsf vboxguest cpuid intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_class intel_pmc_ssram_telemetry intel_vsec polyval_clmulni ghash_clmulni_intel sha1_ssse3 aesni_intel rapl i2c_piix4 i2c_smbus joydev input_leds mac_hid sunrpc binfmt_misc kvm_intel kvm irqbypass sch_fq_codel efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock vmw_vmci dmi_sysfs ip_tables x_tables autofs4 hid_generic vboxvideo usbhid drm_vram_helper psmouse vga16fb vgastate drm_ttm_helper serio_raw hid ahci libahci ttm pata_acpi video wmi [last unloaded: vboxguest]
[ 750.467127] [ T9870] CR2: ffff8880110a2000
cc: Tom Talpey <tom@talpey.com>
cc: linux-cifs@vger.kernel.org
Reviewed-by: David Howells <dhowells@redhat.com>
Reviewed-by: Tom Talpey <tom@talpey.com>
Fixes: c45ebd636c32 ("cifs: Provide the capability to extract from ITER_FOLIOQ to RDMA SGEs")
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 34331d7beed7576acfc98e991c39738b96162499 upstream.
after fabc4ed200f9, server_unresponsive add a condition to check whether client
need to reconnect depending on server->lstrp. When client failed to reconnect
for some time and abort connection, server->lstrp is updated for the last time.
In the following scene, server->lstrp is too old. This cause next command
failure in re-negotiation rather than waiting for re-negotiation done.
1. mount -t cifs -o username=Everyone,echo_internal=10 //$server_ip/export /mnt
2. ssh $server_ip "echo b > /proc/sysrq-trigger &"
3. ls /mnt
4. sleep 21s
5. ssh $server_ip "service firewalld stop"
6. ls # return EHOSTDOWN
If the interval between 5 and 6 is too small, 6 may trigger sending negotiation
request. Before backgrounding cifsd thread try to receive negotiation response
from server in cifs_readv_from_socket, server_unresponsive may trigger
cifs_reconnect which cause 6 to be failed:
ls thread
----------------
smb2_negotiate
server->tcpStatus = CifsInNegotiate
compound_send_recv
wait_for_compound_request
cifsd thread
----------------
cifs_readv_from_socket
server_unresponsive
server->tcpStatus == CifsInNegotiate && jiffies > server->lstrp + 20s
cifs_reconnect
cifs_abort_connection: mid_state = MID_RETRY_NEEDED
ls thread
----------------
cifs_sync_mid_result return EAGAIN
smb2_negotiate return EHOSTDOWN
Though server->lstrp means last server response time, it is updated in
cifs_abort_connection and cifs_get_tcp_session. We can also update server->lstrp
before switching into CifsInNegotiate state to avoid failure in 6.
Fixes: 7ccc1465465d ("smb: client: fix hang in wait_for_response() for negproto")
Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
Acked-by: Meetakshi Setiya <msetiya@microsoft.com>
Signed-off-by: zhangjian <zhangjian496@huawei.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a6c23dac756b9541b33aa3bcd30f464df2879209 upstream.
If spacemit_i2c_xfer_msg() times out waiting for a message transfer to
complete, or if the hardware reports an error, it returns a negative
error code (-ETIMEDOUT, -EAGAIN, -ENXIO. or -EIO).
The sole caller of spacemit_i2c_xfer_msg() is spacemit_i2c_xfer(),
which is the i2c_algorithm->xfer callback function. It currently
does not save the value returned by spacemit_i2c_xfer_msg().
The result is that transfer errors go unreported, and a caller
has no indication anything is wrong.
When this code was out for review, the return value *was* checked
in early versions. But for some reason, that assignment got dropped
between versions 5 and 6 of the series, perhaps related to reworking
the code to merge spacemit_i2c_xfer_core() into spacemit_i2c_xfer().
Simply assigning the value returned to "ret" fixes the problem.
Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC")
Signed-off-by: Alex Elder <elder@riscstar.com>
Cc: <stable@vger.kernel.org> # v6.15+
Reviewed-by: Troy Mitchell <troymitchell988@gmail.com>
Link: https://lore.kernel.org/r/20250616125137.1555453-1-elder@riscstar.com
Signed-off-by: Andi Shyti <andi@smida.it>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a2182743a8b4969481f64aec4908ff162e8a206c upstream.
Under low-memory conditions, close_all_cached_dirs() can't move the
dentries to a separate list to dput() them once the locks are dropped.
This will result in a "Dentry still in use" error, so add an error
message that makes it clear this is what happened:
[ 495.281119] CIFS: VFS: \\otters.example.com\share Out of memory while dropping dentries
[ 495.281595] ------------[ cut here ]------------
[ 495.281887] BUG: Dentry ffff888115531138{i=78,n=/} still in use (2) [unmount of cifs cifs]
[ 495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0
Also, bail out of looping through all tcons as soon as a single
allocation fails, since we're already in trouble, and kmalloc() attempts
for subseqeuent tcons are likely to fail just like the first one did.
Signed-off-by: Paul Aurich <paul@darkrain42.org>
Acked-by: Bharath SM <bharathsm@microsoft.com>
Suggested-by: Ruben Devos <rdevos@oxya.com>
Cc: stable@vger.kernel.org
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b0823d5fbacb1c551d793cbfe7af24e0d1fa45ed upstream.
The perf_fuzzer found a hard-lockup crash on a RaptorLake machine:
Oops: general protection fault, maybe for address 0xffff89aeceab400: 0000
CPU: 23 UID: 0 PID: 0 Comm: swapper/23
Tainted: [W]=WARN
Hardware name: Dell Inc. Precision 9660/0VJ762
RIP: 0010:native_read_pmc+0x7/0x40
Code: cc e8 8d a9 01 00 48 89 03 5b cd cc cc cc cc 0f 1f ...
RSP: 000:fffb03100273de8 EFLAGS: 00010046
....
Call Trace:
<TASK>
icl_update_topdown_event+0x165/0x190
? ktime_get+0x38/0xd0
intel_pmu_read_event+0xf9/0x210
__perf_event_read+0xf9/0x210
CPUs 16-23 are E-core CPUs that don't support the perf metrics feature.
The icl_update_topdown_event() should not be invoked on these CPUs.
It's a regression of commit:
f9bdf1f95339 ("perf/x86/intel: Avoid disable PMU if !cpuc->enabled in sample read")
The bug introduced by that commit is that the is_topdown_event() function
is mistakenly used to replace the is_topdown_count() call to check if the
topdown functions for the perf metrics feature should be invoked.
Fix it.
Fixes: f9bdf1f95339 ("perf/x86/intel: Avoid disable PMU if !cpuc->enabled in sample read")
Closes: https://lore.kernel.org/lkml/352f0709-f026-cd45-e60c-60dfd97f73f3@maine.edu/
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Vince Weaver <vincent.weaver@maine.edu>
Cc: stable@vger.kernel.org # v6.15+
Link: https://lore.kernel.org/r/20250612143818.2889040-1-kan.liang@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 903cc7096db22f889d48e2cee8840709ce04fdac upstream.
Specify the properties which are essential and which are not for the
Tegra I2C driver to function correctly. This was not added correctly when
the TXT binding was converted to yaml. All the existing DT nodes have
these properties already and hence this does not break the ABI.
dmas and dma-names which were specified as a must in the TXT binding
is now made optional since the driver can work in PIO mode if dmas are
missing.
Fixes: f10a9b722f80 ("dt-bindings: i2c: tegra: Convert to json-schema”)
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Cc: <stable@vger.kernel.org> # v5.17+
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Andi Shyti <andi@smida.it>
Link: https://lore.kernel.org/r/20250603153022.39434-1-akhilrajeev@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b2e673ae53ef4b943f68585207a5f21cfc9a0714 upstream.
AMD's Family 19h-based Models 70h-7fh support 4 unified memory controllers
(UMC) per processor die.
The amd64_edac driver, however, assumes only 2 UMCs are supported since
max_mcs variable for the models has not been explicitly set to 4. The same
results in incomplete or incorrect memory information being logged to dmesg by
the module during initialization in some instances.
Fixes: 6c79e42169fe ("EDAC/amd64: Add support for ECC on family 19h model 60h-7Fh")
Closes: https://lore.kernel.org/all/27dc093f-ce27-4c71-9e81-786150a040b6@reox.at/
Reported-by: reox <mailinglist@reox.at>
Signed-off-by: Avadhut Naik <avadhut.naik@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@kernel.org
Link: https://lore.kernel.org/20250613005233.2330627-1-avadhut.naik@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 94a17f2dc90bc7eae36c0f478515d4bd1c23e877 upstream.
PTI uses separate ASIDs (aka. PCIDs) for kernel and user address
spaces. When the kernel needs to flush the user address space, it
just sets a bit in a bitmap and then flushes the entire PCID on
the next switch to userspace.
This bitmap is a single 'unsigned long' which is plenty for all 6
dynamic ASIDs. But, unfortunately, the INVLPGB support brings along a
bunch more user ASIDs, as many as ~2k more. The bitmap can't address
that many.
Fortunately, the bitmap is only needed for PTI and all the CPUs
with INVLPGB are AMD CPUs that aren't vulnerable to Meltdown and
don't need PTI. The only way someone can run into an issue in
practice is by booting with pti=on on a newer AMD CPU.
Disable INVLPGB if PTI is enabled. Avoid overrunning the small
bitmap.
Note: this will be fixed up properly by making the bitmap bigger.
For now, just avoid the mostly theoretical bug.
Fixes: 4afeb0ed1753 ("x86/mm: Enable broadcast TLB invalidation for multi-threaded processes")
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Rik van Riel <riel@surriel.com>
Cc:stable@vger.kernel.org
Link: https://lore.kernel.org/all/20250610222420.E8CBF472%40davehans-spike.ostc.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit cade3d57e456e69f67aa9894bf89dc8678796bb7 upstream.
When KVM runs in non-protected VHE mode, there's no context
synchronization event between __debug_switch_to_host() restoring the
host debug registers and __kvm_vcpu_run() unmasking debug exceptions.
Due to this, it's theoretically possible for the host to take an
unexpected debug exception due to the stale guest configuration.
This cannot happen in NVHE/HVHE mode as debug exceptions are masked in
the hyp code, and the exception return to the host will provide the
necessary context synchronization before debug exceptions can be taken.
For now, avoid the problem by adding an ISB after VHE hyp code restores
the host debug registers.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Fuad Tabba <tabba@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>
Cc: Will Deacon <will@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250617133718.4014181-2-mark.rutland@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 9738280aae592b579a25b5b1b6584c894827d3c7 ]
The multi message support loosened the connection between the request
and response handling, as we can now submit multiple requests before
we start processing responses. Passing the attr set to NlMsgs decoding
no longer makes sense (if it ever did), attr set may differ message
by messsage. Isolate the part of decoding responsible for attr-set
specific interpretation and call it once we identified the correct op.
Without this fix performing SET operation on an ethtool socket, while
being subscribed to notifications causes:
# File "tools/net/ynl/pyynl/lib/ynl.py", line 1096, in _op
# Exception| return self._ops(ops)[0]
# Exception| ~~~~~~~~~^^^^^
# File "tools/net/ynl/pyynl/lib/ynl.py", line 1040, in _ops
# Exception| nms = NlMsgs(reply, attr_space=op.attr_set)
# Exception| ^^^^^^^^^^^
The value of op we use on line 1040 is stale, it comes form the previous
loop. If a notification comes before a response we will update op to None
and the next iteration thru the loop will break with the trace above.
Fixes: 6fda63c45fe8 ("tools/net/ynl: fix cli.py --subscribe feature")
Fixes: ba8be00f68f5 ("tools/net/ynl: Add multi message support to ynl")
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Link: https://patch.msgid.link/20250618171746.1201403-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 09d7ff0694ea133c50ad905fd6e548c13f8af458 ]
Extend the Python YNL extack decoding to handle sub-messages in the same
way that YNL C does. This involves retaining the input values so that
they are available during extack decoding.
./tools/net/ynl/pyynl/cli.py --family rt-link --do newlink --create \
--json '{
"linkinfo": {"kind": "netkit", "data": {"policy": 10} }
}'
Netlink error: Invalid argument
nl_len = 92 (76) nl_flags = 0x300 nl_type = 2
error: -22
extack: {'msg': 'Provided default xmit policy not supported', 'bad-attr': '.linkinfo.data(netkit).policy'}
Signed-off-by: Donald Hunter <donald.hunter@gmail.com>
Link: https://patch.msgid.link/20250523103031.80236-1-donald.hunter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Stable-dep-of: 9738280aae59 ("tools: ynl: fix mixing ops and notifications on one socket")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit d03b79f459c7935cff830d98373474f440bd03ae ]
/proc/net/atm/lec must ensure safety against dev_lec[] changes.
It appears it had dev_put() calls without prior dev_hold(),
leading to imbalance and UAF.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com> # Minor atm contributor
Link: https://patch.msgid.link/20250618140844.1686882-3-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit d13a3824bfd2b4774b671a75cf766a16637a0e67 ]
syzbot found its way in net/atm/lec.c, and found an error path
in lecd_attach() could leave a dangling pointer in dev_lec[].
Add a mutex to protect dev_lecp[] uses from lecd_attach(),
lec_vcc_attach() and lec_mcast_attach().
Following patch will use this mutex for /proc/net/atm/lec.
BUG: KASAN: slab-use-after-free in lecd_attach net/atm/lec.c:751 [inline]
BUG: KASAN: slab-use-after-free in lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008
Read of size 8 at addr ffff88807c7b8e68 by task syz.1.17/6142
CPU: 1 UID: 0 PID: 6142 Comm: syz.1.17 Not tainted 6.16.0-rc1-syzkaller-00239-g08215f5486ec #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:408 [inline]
print_report+0xcd/0x680 mm/kasan/report.c:521
kasan_report+0xe0/0x110 mm/kasan/report.c:634
lecd_attach net/atm/lec.c:751 [inline]
lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008
do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159
sock_do_ioctl+0x118/0x280 net/socket.c:1190
sock_ioctl+0x227/0x6b0 net/socket.c:1311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl fs/ioctl.c:893 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
Allocated by task 6132:
kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394
kasan_kmalloc include/linux/kasan.h:260 [inline]
__do_kmalloc_node mm/slub.c:4328 [inline]
__kvmalloc_node_noprof+0x27b/0x620 mm/slub.c:5015
alloc_netdev_mqs+0xd2/0x1570 net/core/dev.c:11711
lecd_attach net/atm/lec.c:737 [inline]
lane_ioctl+0x17db/0x23e0 net/atm/lec.c:1008
do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159
sock_do_ioctl+0x118/0x280 net/socket.c:1190
sock_ioctl+0x227/0x6b0 net/socket.c:1311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl fs/ioctl.c:893 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 6132:
kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:576
poison_slab_object mm/kasan/common.c:247 [inline]
__kasan_slab_free+0x51/0x70 mm/kasan/common.c:264
kasan_slab_free include/linux/kasan.h:233 [inline]
slab_free_hook mm/slub.c:2381 [inline]
slab_free mm/slub.c:4643 [inline]
kfree+0x2b4/0x4d0 mm/slub.c:4842
free_netdev+0x6c5/0x910 net/core/dev.c:11892
lecd_attach net/atm/lec.c:744 [inline]
lane_ioctl+0x1ce8/0x23e0 net/atm/lec.c:1008
do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159
sock_do_ioctl+0x118/0x280 net/socket.c:1190
sock_ioctl+0x227/0x6b0 net/socket.c:1311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl fs/ioctl.c:893 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+8b64dec3affaed7b3af5@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6852c6f6.050a0220.216029.0018.GAE@google.com/T/#u
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20250618140844.1686882-2-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit e7ea5f5b1858ddb96b152584d5fe06e6fc623e89 ]
The message "Error getting PHY irq. Use polling instead"
is emitted when the mlxbf_gige driver is loaded by the
kernel before the associated gpio-mlxbf driver, and thus
the call to get the PHY IRQ fails since it is not yet
available. The driver probe() must return -EPROBE_DEFER
if acpi_dev_gpio_irq_get_by() returns the same.
Fixes: 6c2a6ddca763 ("net: mellanox: mlxbf_gige: Replace non-standard interrupt handling")
Signed-off-by: David Thompson <davthompson@nvidia.com>
Reviewed-by: Asmaa Mnebhi <asmaa@nvidia.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250618135902.346-1-davthompson@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 10876da918fa1aec0227fb4c67647513447f53a9 ]
syzkaller reported a null-ptr-deref in sock_omalloc() while allocating
a CALIPSO option. [0]
The NULL is of struct sock, which was fetched by sk_to_full_sk() in
calipso_req_setattr().
Since commit a1a5344ddbe8 ("tcp: avoid two atomic ops for syncookies"),
reqsk->rsk_listener could be NULL when SYN Cookie is returned to its
client, as hinted by the leading SYN Cookie log.
Here are 3 options to fix the bug:
1) Return 0 in calipso_req_setattr()
2) Return an error in calipso_req_setattr()
3) Alaways set rsk_listener
1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookie
for CALIPSO. 3) is also no go as there have been many efforts to reduce
atomic ops and make TCP robust against DDoS. See also commit 3b24d854cb35
("tcp/dccp: do not touch listener sk_refcnt under synflood").
As of the blamed commit, SYN Cookie already did not need refcounting,
and no one has stumbled on the bug for 9 years, so no CALIPSO user will
care about SYN Cookie.
Let's return an error in calipso_req_setattr() and calipso_req_delattr()
in the SYN Cookie case.
This can be reproduced by [1] on Fedora and now connect() of nc times out.
[0]:
TCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies.
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
RIP: 0010:read_pnet include/net/net_namespace.h:406 [inline]
RIP: 0010:sock_net include/net/sock.h:655 [inline]
RIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806
Code: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b
RSP: 0018:ffff88811af89038 EFLAGS: 00010216
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400
RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030
RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640e
R10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000
R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050
FS: 00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0
PKRU: 80000000
Call Trace:
<IRQ>
ipv6_renew_options+0x279/0x950 net/ipv6/exthdrs.c:1288
calipso_req_setattr+0x181/0x340 net/ipv6/calipso.c:1204
calipso_req_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:597
netlbl_req_setattr+0x18a/0x440 net/netlabel/netlabel_kapi.c:1249
selinux_netlbl_inet_conn_request+0x1fb/0x320 security/selinux/netlabel.c:342
selinux_inet_conn_request+0x1eb/0x2c0 security/selinux/hooks.c:5551
security_inet_conn_request+0x50/0xa0 security/security.c:4945
tcp_v6_route_req+0x22c/0x550 net/ipv6/tcp_ipv6.c:825
tcp_conn_request+0xec8/0x2b70 net/ipv4/tcp_input.c:7275
tcp_v6_conn_request+0x1e3/0x440 net/ipv6/tcp_ipv6.c:1328
tcp_rcv_state_process+0xafa/0x52b0 net/ipv4/tcp_input.c:6781
tcp_v6_do_rcv+0x8a6/0x1a40 net/ipv6/tcp_ipv6.c:1667
tcp_v6_rcv+0x505e/0x5b50 net/ipv6/tcp_ipv6.c:1904
ip6_protocol_deliver_rcu+0x17c/0x1da0 net/ipv6/ip6_input.c:436
ip6_input_finish+0x103/0x180 net/ipv6/ip6_input.c:480
NF_HOOK include/linux/netfilter.h:314 [inline]
NF_HOOK include/linux/netfilter.h:308 [inline]
ip6_input+0x13c/0x6b0 net/ipv6/ip6_input.c:491
dst_input include/net/dst.h:469 [inline]
ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline]
ip6_rcv_finish+0xb6/0x490 net/ipv6/ip6_input.c:69
NF_HOOK include/linux/netfilter.h:314 [inline]
NF_HOOK include/linux/netfilter.h:308 [inline]
ipv6_rcv+0xf9/0x490 net/ipv6/ip6_input.c:309
__netif_receive_skb_one_core+0x12e/0x1f0 net/core/dev.c:5896
__netif_receive_skb+0x1d/0x170 net/core/dev.c:6009
process_backlog+0x41e/0x13b0 net/core/dev.c:6357
__napi_poll+0xbd/0x710 net/core/dev.c:7191
napi_poll net/core/dev.c:7260 [inline]
net_rx_action+0x9de/0xde0 net/core/dev.c:7382
handle_softirqs+0x19a/0x770 kernel/softirq.c:561
do_softirq.part.0+0x36/0x70 kernel/softirq.c:462
</IRQ>
<TASK>
do_softirq arch/x86/include/asm/preempt.h:26 [inline]
__local_bh_enable_ip+0xf1/0x110 kernel/softirq.c:389
local_bh_enable include/linux/bottom_half.h:33 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]
__dev_queue_xmit+0xc2a/0x3c40 net/core/dev.c:4679
dev_queue_xmit include/linux/netdevice.h:3313 [inline]
neigh_hh_output include/net/neighbour.h:523 [inline]
neigh_output include/net/neighbour.h:537 [inline]
ip6_finish_output2+0xd69/0x1f80 net/ipv6/ip6_output.c:141
__ip6_finish_output net/ipv6/ip6_output.c:215 [inline]
ip6_finish_output+0x5dc/0xd60 net/ipv6/ip6_output.c:226
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
ip6_output+0x24b/0x8d0 net/ipv6/ip6_output.c:247
dst_output include/net/dst.h:459 [inline]
NF_HOOK include/linux/netfilter.h:314 [inline]
NF_HOOK include/linux/netfilter.h:308 [inline]
ip6_xmit+0xbbc/0x20d0 net/ipv6/ip6_output.c:366
inet6_csk_xmit+0x39a/0x720 net/ipv6/inet6_connection_sock.c:135
__tcp_transmit_skb+0x1a7b/0x3b40 net/ipv4/tcp_output.c:1471
tcp_transmit_skb net/ipv4/tcp_output.c:1489 [inline]
tcp_send_syn_data net/ipv4/tcp_output.c:4059 [inline]
tcp_connect+0x1c0c/0x4510 net/ipv4/tcp_output.c:4148
tcp_v6_connect+0x156c/0x2080 net/ipv6/tcp_ipv6.c:333
__inet_stream_connect+0x3a7/0xed0 net/ipv4/af_inet.c:677
tcp_sendmsg_fastopen+0x3e2/0x710 net/ipv4/tcp.c:1039
tcp_sendmsg_locked+0x1e82/0x3570 net/ipv4/tcp.c:1091
tcp_sendmsg+0x2f/0x50 net/ipv4/tcp.c:1358
inet6_sendmsg+0xb9/0x150 net/ipv6/af_inet6.c:659
sock_sendmsg_nosec net/socket.c:718 [inline]
__sock_sendmsg+0xf4/0x2a0 net/socket.c:733
__sys_sendto+0x29a/0x390 net/socket.c:2187
__do_sys_sendto net/socket.c:2194 [inline]
__se_sys_sendto net/socket.c:2190 [inline]
__x64_sys_sendto+0xe1/0x1c0 net/socket.c:2190
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xc3/0x1d0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f06553c47ed
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f0653a06fc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00007f0655605fa0 RCX: 00007f06553c47ed
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000000000b
RBP: 00007f065545db38 R08: 0000200000000140 R09: 000000000000001c
R10: f7384d4ea84b01bd R11: 0000000000000246 R12: 0000000000000000
R13: 00007f0655605fac R14: 00007f0655606038 R15: 00007f06539e7000
</TASK>
Modules linked in:
[1]:
dnf install -y selinux-policy-targeted policycoreutils netlabel_tools procps-ng nmap-ncat
mount -t selinuxfs none /sys/fs/selinux
load_policy
netlabelctl calipso add pass doi:1
netlabelctl map del default
netlabelctl map add default address:::1 protocol:calipso,1
sysctl net.ipv4.tcp_syncookies=2
nc -l ::1 80 &
nc ::1 80
Fixes: e1adea927080 ("calipso: Allow request sockets to be relabelled by the lsm.")
Reported-by: syzkaller <syzkaller@googlegroups.com>
Reported-by: John Cheung <john.cs.hey@gmail.com>
Closes: https://lore.kernel.org/netdev/CAP=Rh=MvfhrGADy+-WJiftV2_WzMH4VEhEFmeT28qY+4yxNu4w@mail.gmail.com/
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Acked-by: Paul Moore <paul@paul-moore.com>
Link: https://patch.msgid.link/20250617224125.17299-1-kuni1840@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 16c1241b08751a67cd7a0221ea9f82b0b02806f4 ]
This allows for additional L2 caching modes.
Fixes: 01570b446939 ("drm/xe/bmg: implement Wa_16023588340")
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Link: https://lore.kernel.org/r/20250612-wa-14022085890-v4-2-94ba5dcc1e30@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
(cherry picked from commit 6ab42fa03d4c88a0ddf5e56e62794853b198e7bf)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 8c8472855884355caf3d8e0c50adf825f83454b2 ]
Sanity check the values for queue depth and number of queues
we get from userspace when adding a device.
Signed-off-by: Ronnie Sahlberg <rsahlberg@whamcloud.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver")
Fixes: 62fe99cef94a ("ublk: add read()/write() support for ublk char device")
Link: https://lore.kernel.org/r/20250619021031.181340-1-ronniesahlberg@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
lan743x_ptp_io_event_clock_get()
[ Upstream commit e353b0854d3a1a31cb061df8d022fbfea53a0f24 ]
Before calling lan743x_ptp_io_event_clock_get(), the 'channel' value
is checked against the maximum value of PCI11X1X_PTP_IO_MAX_CHANNELS(8).
This seems correct and aligns with the PTP interrupt status register
(PTP_INT_STS) specifications.
However, lan743x_ptp_io_event_clock_get() writes to ptp->extts[] with
only LAN743X_PTP_N_EXTTS(4) elements, using channel as an index:
lan743x_ptp_io_event_clock_get(..., u8 channel,...)
{
...
/* Update Local timestamp */
extts = &ptp->extts[channel];
extts->ts.tv_sec = sec;
...
}
To avoid an out-of-bounds write and utilize all the supported GPIO
inputs, set LAN743X_PTP_N_EXTTS to 8.
Detected using the static analysis tool - Svace.
Fixes: 60942c397af6 ("net: lan743x: Add support for PTP-IO Event Input External Timestamp (extts)")
Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Rengarajan S <rengarajan.s@microchip.com>
Link: https://patch.msgid.link/20250616113743.36284-1-aleksei.kodanev@bell-sw.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 5bd1bafd4474ee26f504b41aba11f3e2a1175b88 ]
The semantics are that caller of fbnic_mbx_map_msg() retains
the ownership of the message on error. All existing callers
dutifully free the page.
Fixes: da3cde08209e ("eth: fbnic: Add FW communication mechanism")
Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20250616195510.225819-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit dbe0ca8da1f62b6252e7be6337209f4d86d4a914 ]
There is a bug with passive TFO sockets returning an invalid NAPI ID 0
from SO_INCOMING_NAPI_ID. Normally this is not an issue, but zero copy
receive relies on a correct NAPI ID to process sockets on the right
queue.
Fix by adding a sk_mark_napi_id_set().
Fixes: e5907459ce7e ("tcp: Record Rx hash and NAPI ID in tcp_child_process")
Signed-off-by: David Wei <dw@davidwei.uk>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20250617212102.175711-5-dw@davidwei.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit f82727adcf2992822e12198792af450a76ebd5ef ]
The reproduction steps:
1. create a tun interface
2. enable l2 bearer
3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun
tipc: Started in network mode
tipc: Node identity 8af312d38a21, cluster identity 4711
tipc: Enabled bearer <eth:syz_tun>, priority 1
Oops: general protection fault
KASAN: null-ptr-deref in range
CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT
Hardware name: QEMU Ubuntu 24.04 PC
RIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0
the ub was in fact a struct dev.
when bid != 0 && skip_cnt != 0, bearer_list[bid] may be NULL or
other media when other thread changes it.
fix this by checking media_id.
Fixes: 832629ca5c313 ("tipc: add UDP remoteip dump to netlink API")
Signed-off-by: Haixia Qu <hxqu@hillstonenet.com>
Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech>
Link: https://patch.msgid.link/20250617055624.2680-1-hxqu@hillstonenet.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 9ac8d0c640a161486eaf71d1999ee990fad62947 ]
NIX block can receive packets from multiple links such as
MAC (RPM), LBK and CPT.
-----------------
RPM --| NIX |
-----------------
|
|
LBK
Each link supports multiple channels for example RPM link supports
16 channels. In case of link oversubsribe, NIX will assert backpressure
on receive channels.
The previous patch considered a single channel per link, resulting in
backpressure not being enabled on the remaining channels
Fixes: a7ef63dbd588 ("octeontx2-af: Disable backpressure between CPT and NIX")
Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250617063403.3582210-1-hkelam@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit a55737dab6ba63eb4241e9c6547629058af31e12 ]
Relocate the per-SDMA queue reset capability check from
kfd_topology_set_capabilities() to node_show() to ensure we read the
latest value of sdma.supported_reset after all IP blocks are initialized.
Fixes: ceb7114c961b ("drm/amdkfd: flag per-sdma queue reset supported to user space")
Reviewed-by: Jonathan Kim <jonathan.kim@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit e17df7b086cf908cedd919f448da9e00028419bb)
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit e1c75831f682eef0f68b35723437146ed86070b1 ]
If allocation of the 'imu' fails, then the existing pages aren't
unpinned in the error path. This is mostly a theoretical issue,
requiring fault injection to hit.
Move unpin_user_pages() to unified error handling to fix the page leak
issue.
Fixes: d8c2237d0aa9 ("io_uring: add io_pin_pages() helper")
Signed-off-by: Penglei Jiang <superman.xpt@gmail.com>
Link: https://lore.kernel.org/r/20250617165644.79165-1-superman.xpt@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit d0fa59897e049e84432600e86df82aab3dce7aa5 ]
After the following commit from 2024:
commit e37ab7373696 ("tcp: fix to allow timestamp undo if no retransmits were sent")
...there was buggy behavior where TCP connections without SACK support
could easily see erroneous undo events at the end of fast recovery or
RTO recovery episodes. The erroneous undo events could cause those
connections to suffer repeated loss recovery episodes and high
retransmit rates.
The problem was an interaction between the non-SACK behavior on these
connections and the undo logic. The problem is that, for non-SACK
connections at the end of a loss recovery episode, if snd_una ==
high_seq, then tcp_is_non_sack_preventing_reopen() holds steady in
CA_Recovery or CA_Loss, but clears tp->retrans_stamp to 0. Then upon
the next ACK the "tcp: fix to allow timestamp undo if no retransmits
were sent" logic saw the tp->retrans_stamp at 0 and erroneously
concluded that no data was retransmitted, and erroneously performed an
undo of the cwnd reduction, restoring cwnd immediately to the value it
had before loss recovery. This caused an immediate burst of traffic
and build-up of queues and likely another immediate loss recovery
episode.
This commit fixes tcp_packet_delayed() to ignore zero retrans_stamp
values for non-SACK connections when snd_una is at or above high_seq,
because tcp_is_non_sack_preventing_reopen() clears retrans_stamp in
this case, so it's not a valid signal that we can undo.
Note that the commit named in the Fixes footer restored long-present
behavior from roughly 2005-2019, so apparently this bug was present
for a while during that era, and this was simply not caught.
Fixes: e37ab7373696 ("tcp: fix to allow timestamp undo if no retransmits were sent")
Reported-by: Eric Wheeler <netdev@lists.ewheeler.net>
Closes: https://lore.kernel.org/netdev/64ea9333-e7f9-0df-b0f2-8d566143acab@ewheeler.net/
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Co-developed-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
