commit 91786f140358b1e56efdb0feccb337ce3a59c031
Author: Greg Kroah-Hartman
Date: Thu Dec 19 18:07:23 2024 +0100
Linux 5.15.175
Link: https://lore.kernel.org/r/[email protected]
Tested-by: Florian Fainelli
Tested-by: Shuah Khan
Tested-by: Ron Economos
Tested-by: Mark Brown
Tested-by: Jon Hunter
Signed-off-by: Greg Kroah-Hartman
commit fb8c76c7604a9db2e014744a316f22757f7db187
Author: Juergen Gross
Date: Wed Dec 18 09:02:28 2024 +0100
x86/static-call: fix 32-bit build
commit 349f0086ba8b2a169877d21ff15a4d9da3a60054 upstream.
In 32-bit x86 builds CONFIG_STATIC_CALL_INLINE isn't set, leading to
static_call_initialized not being available.
Define it as "0" in that case.
Reported-by: Stephen Rothwell
Fixes: 0ef8047b737d ("x86/static-call: provide a way to do very early static-call updates")
Signed-off-by: Juergen Gross
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
commit 4e54dc4bbc602133217de301d9f814f3e6d22eee
Author: Dan Carpenter
Date: Mon Dec 2 15:57:54 2024 +0300
ALSA: usb-audio: Fix a DMA to stack memory bug
commit f7d306b47a24367302bd4fe846854e07752ffcd9 upstream.
The usb_get_descriptor() function does DMA so we're not allowed
to use a stack buffer for that. Doing DMA to the stack is not portable
all architectures. Move the "new_device_descriptor" from being stored
on the stack and allocate it with kmalloc() instead.
Fixes: b909df18ce2a ("ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices")
Cc: [email protected]
Signed-off-by: Dan Carpenter
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Takashi Iwai
Signed-off-by: Benoît Sevens
Signed-off-by: Greg Kroah-Hartman
commit ae7c1c5233237cd89bf1bb59fbcad516212c6f42
Author: Juergen Gross
Date: Thu Oct 17 15:27:31 2024 +0200
x86/xen: remove hypercall page
commit 7fa0da5373685e7ed249af3fa317ab1e1ba8b0a6 upstream.
The hypercall page is no longer needed. It can be removed, as from the
Xen perspective it is optional.
But, from Linux's perspective, it removes naked RET instructions that
escape the speculative protections that Call Depth Tracking and/or
Untrain Ret are trying to achieve.
This is part of XSA-466 / CVE-2024-53241.
Reported-by: Andrew Cooper
Signed-off-by: Juergen Gross
Reviewed-by: Andrew Cooper
Reviewed-by: Jan Beulich
Signed-off-by: Greg Kroah-Hartman
commit 1ef790d6bf55099750f1402b188c27bc42261c41
Author: Juergen Gross
Date: Thu Oct 17 14:47:13 2024 +0200
x86/xen: use new hypercall functions instead of hypercall page
commit b1c2cb86f4a7861480ad54bb9a58df3cbebf8e92 upstream.
Call the Xen hypervisor via the new xen_hypercall_func static-call
instead of the hypercall page.
This is part of XSA-466 / CVE-2024-53241.
Reported-by: Andrew Cooper
Signed-off-by: Juergen Gross
Co-developed-by: Peter Zijlstra
Co-developed-by: Josh Poimboeuf
Signed-off-by: Greg Kroah-Hartman
commit a501b4dbedb4cdcfa2372b40e6b405e26d3e8069
Author: Juergen Gross
Date: Thu Oct 17 11:00:52 2024 +0200
x86/xen: add central hypercall functions
commit b4845bb6383821a9516ce30af3a27dc873e37fd4 upstream.
Add generic hypercall functions usable for all normal (i.e. not iret)
hypercalls. Depending on the guest type and the processor vendor
different functions need to be used due to the to be used instruction
for entering the hypervisor:
- PV guests need to use syscall
- HVM/PVH guests on Intel need to use vmcall
- HVM/PVH guests on AMD and Hygon need to use vmmcall
As PVH guests need to issue hypercalls very early during boot, there
is a 4th hypercall function needed for HVM/PVH which can be used on
Intel and AMD processors. It will check the vendor type and then set
the Intel or AMD specific function to use via static_call().
This is part of XSA-466 / CVE-2024-53241.
Reported-by: Andrew Cooper
Signed-off-by: Juergen Gross
Co-developed-by: Peter Zijlstra
Signed-off-by: Greg Kroah-Hartman
commit c7b4cfa6213a44fa48714186dfdf125072d036e3
Author: Juergen Gross
Date: Wed Oct 16 10:40:26 2024 +0200
x86/xen: don't do PV iret hypercall through hypercall page
commit a2796dff62d6c6bfc5fbebdf2bee0d5ac0438906 upstream.
Instead of jumping to the Xen hypercall page for doing the iret
hypercall, directly code the required sequence in xen-asm.S.
This is done in preparation of no longer using hypercall page at all,
as it has shown to cause problems with speculation mitigations.
This is part of XSA-466 / CVE-2024-53241.
Reported-by: Andrew Cooper
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Signed-off-by: Greg Kroah-Hartman
commit 8abab99114f1713914d833344e74a0944291a5fb
Author: Juergen Gross
Date: Fri Nov 29 16:15:54 2024 +0100
x86/static-call: provide a way to do very early static-call updates
commit 0ef8047b737d7480a5d4c46d956e97c190f13050 upstream.
Add static_call_update_early() for updating static-call targets in
very early boot.
This will be needed for support of Xen guest type specific hypercall
functions.
This is part of XSA-466 / CVE-2024-53241.
Reported-by: Andrew Cooper
Signed-off-by: Juergen Gross
Co-developed-by: Peter Zijlstra
Co-developed-by: Josh Poimboeuf
Signed-off-by: Greg Kroah-Hartman
commit 1c50e8da50b07c69385d601dd0443f5bbe71d933
Author: Juergen Gross
Date: Fri Nov 29 15:47:49 2024 +0100
objtool/x86: allow syscall instruction
commit dda014ba59331dee4f3b773a020e109932f4bd24 upstream.
The syscall instruction is used in Xen PV mode for doing hypercalls.
Allow syscall to be used in the kernel in case it is tagged with an
unwind hint for objtool.
This is part of XSA-466 / CVE-2024-53241.
Reported-by: Andrew Cooper
Signed-off-by: Juergen Gross
Co-developed-by: Peter Zijlstra
Signed-off-by: Greg Kroah-Hartman
commit 8f2c179b1d3ce0a0c5d623fc9991d71167fd076f
Author: Juergen Gross
Date: Thu Oct 17 08:29:48 2024 +0200
x86: make get_cpu_vendor() accessible from Xen code
commit efbcd61d9bebb771c836a3b8bfced8165633db7c upstream.
In order to be able to differentiate between AMD and Intel based
systems for very early hypercalls without having to rely on the Xen
hypercall page, make get_cpu_vendor() non-static.
Refactor early_cpu_init() for the same reason by splitting out the
loop initializing cpu_devs() into an externally callable function.
This is part of XSA-466 / CVE-2024-53241.
Reported-by: Andrew Cooper
Signed-off-by: Juergen Gross
Signed-off-by: Greg Kroah-Hartman
commit 2657ba851fa3381256d81e431b20041dc232fd88
Author: Juergen Gross
Date: Thu Nov 7 16:17:00 2024 +0100
xen/netfront: fix crash when removing device
commit f9244fb55f37356f75c739c57323d9422d7aa0f8 upstream.
When removing a netfront device directly after a suspend/resume cycle
it might happen that the queues have not been setup again, causing a
crash during the attempt to stop the queues another time.
Fix that by checking the queues are existing before trying to stop
them.
This is XSA-465 / CVE-2024-53240.
Reported-by: Marek Marczykowski-Górecki
Fixes: d50b7914fae0 ("xen-netfront: Fix NULL sring after live migration")
Signed-off-by: Juergen Gross
Signed-off-by: Greg Kroah-Hartman
commit 3dfd8991ad33b10c2fb027a4cfcf57579fa786c1
Author: Greg Kroah-Hartman
Date: Tue Dec 17 10:06:00 2024 +0100
Revert "parisc: fix a possible DMA corruption"
This reverts commit dadac97f066a67334268132c1e2d0fd599fbcbec which is
commit 7ae04ba36b381bffe2471eff3a93edced843240f upstream.
It is reported to cause build failures.
Reported-by: Guenter Roeck
Link: https://lore.kernel.org/r/[email protected]
Cc: Mikulas Patocka
Cc: Helge Deller
Cc: Mingli Yu
Signed-off-by: Greg Kroah-Hartman
commit f585c5793aca1186129a7c26009cc7ed077eb0b0
Author: Nikolay Kuratov
Date: Mon Dec 16 14:19:23 2024 +0300
tracing/kprobes: Skip symbol counting logic for module symbols in create_local_trace_kprobe()
commit b022f0c7e404 ("tracing/kprobes: Return EADDRNOTAVAIL when func matches several symbols")
avoids checking number_of_same_symbols() for module symbol in
__trace_kprobe_create(), but create_local_trace_kprobe() should avoid this
check too. Doing this check leads to ENOENT for module_name:symbol_name
constructions passed over perf_event_open.
No bug in newer kernels as it was fixed more generally by
commit 9d8616034f16 ("tracing/kprobes: Add symbol counting check when module loads")
Link: https://lore.kernel.org/linux-trace-kernel/[email protected]
Fixes: b022f0c7e404 ("tracing/kprobes: Return EADDRNOTAVAIL when func matches several symbols")
Signed-off-by: Nikolay Kuratov
Signed-off-by: Greg Kroah-Hartman
commit b57ac2d92c1f565743f6890a5b9cf317ed856b09
Author: Eduard Zingerman
Date: Tue Sep 24 14:08:43 2024 -0700
bpf: sync_linked_regs() must preserve subreg_def
commit e9bd9c498cb0f5843996dbe5cbce7a1836a83c70 upstream.
Range propagation must not affect subreg_def marks, otherwise the
following example is rewritten by verifier incorrectly when
BPF_F_TEST_RND_HI32 flag is set:
0: call bpf_ktime_get_ns call bpf_ktime_get_ns
1: r0 &= 0x7fffffff after verifier r0 &= 0x7fffffff
2: w1 = w0 rewrites w1 = w0
3: if w0 < 10 goto +0 --------------> r11 = 0x2f5674a6 (r)
4: r1 >>= 32 r11 <<= 32 (r)
5: r0 = r1 r1 |= r11 (r)
6: exit; if w0 < 0xa goto pc+0
r1 >>= 32
r0 = r1
exit
(or zero extension of w1 at (2) is missing for architectures that
require zero extension for upper register half).
The following happens w/o this patch:
- r0 is marked as not a subreg at (0);
- w1 is marked as subreg at (2);
- w1 subreg_def is overridden at (3) by copy_register_state();
- w1 is read at (5) but mark_insn_zext() does not mark (2)
for zero extension, because w1 subreg_def is not set;
- because of BPF_F_TEST_RND_HI32 flag verifier inserts random
value for hi32 bits of (2) (marked (r));
- this random value is read at (5).
Fixes: 75748837b7e5 ("bpf: Propagate scalar ranges through register assignments.")
Reported-by: Lonial Con
Signed-off-by: Lonial Con
Signed-off-by: Eduard Zingerman
Signed-off-by: Andrii Nakryiko
Signed-off-by: Daniel Borkmann
Acked-by: Daniel Borkmann
Closes: https://lore.kernel.org/bpf/[email protected]
Link: https://lore.kernel.org/bpf/[email protected]
[ shung-hsi.yu: sync_linked_regs() was called find_equal_scalars() before commit
4bf79f9be434 ("bpf: Track equal scalars history on per-instruction level"), and
modification is done because there is only a single call to
copy_register_state() before commit 98d7ca374ba4 ("bpf: Track delta between
"linked" registers."). ]
Signed-off-by: Shung-Hsi Yu
Signed-off-by: Greg Kroah-Hartman
commit 4749f9f9b050adeb339f810e250095e2f6de9ac1
Author: Nathan Chancellor
Date: Thu Dec 12 10:13:29 2024 -0700
blk-iocost: Avoid using clamp() on inuse in __propagate_weights()
[ Upstream commit 57e420c84f9ab55ba4c5e2ae9c5f6c8e1ea834d2 ]
After a recent change to clamp() and its variants [1] that increases the
coverage of the check that high is greater than low because it can be
done through inlining, certain build configurations (such as s390
defconfig) fail to build with clang with:
block/blk-iocost.c:1101:11: error: call to '__compiletime_assert_557' declared with 'error' attribute: clamp() low limit 1 greater than high limit active
1101 | inuse = clamp_t(u32, inuse, 1, active);
| ^
include/linux/minmax.h:218:36: note: expanded from macro 'clamp_t'
218 | #define clamp_t(type, val, lo, hi) __careful_clamp(type, val, lo, hi)
| ^
include/linux/minmax.h:195:2: note: expanded from macro '__careful_clamp'
195 | __clamp_once(type, val, lo, hi, __UNIQUE_ID(v_), __UNIQUE_ID(l_), __UNIQUE_ID(h_))
| ^
include/linux/minmax.h:188:2: note: expanded from macro '__clamp_once'
188 | BUILD_BUG_ON_MSG(statically_true(ulo > uhi), \
| ^
__propagate_weights() is called with an active value of zero in
ioc_check_iocgs(), which results in the high value being less than the
low value, which is undefined because the value returned depends on the
order of the comparisons.
The purpose of this expression is to ensure inuse is not more than
active and at least 1. This could be written more simply with a ternary
expression that uses min(inuse, active) as the condition so that the
value of that condition can be used if it is not zero and one if it is.
Do this conversion to resolve the error and add a comment to deter
people from turning this back into clamp().
Fixes: 7caa47151ab2 ("blkcg: implement blk-iocost")
Link: https://lore.kernel.org/r/[email protected]/ [1]
Suggested-by: David Laight
Reported-by: Linux Kernel Functional Testing
Closes: https://lore.kernel.org/llvm/CA+G9fYsD7mw13wredcZn0L-KBA3yeoVSTuxnss-AEWMN3ha0cA@mail.gmail.com/
Reported-by: kernel test robot
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Signed-off-by: Nathan Chancellor
Acked-by: Tejun Heo
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
commit 56b9f3df5ac096ca114eecf1e0f3e290e691f82b
Author: Daniil Tatianin
Date: Fri Nov 22 11:29:54 2024 +0300
ACPICA: events/evxfregn: don't release the ContextMutex that was never acquired
[ Upstream commit c53d96a4481f42a1635b96d2c1acbb0a126bfd54 ]
This bug was first introduced in c27f3d011b08, where the author of the
patch probably meant to do DeleteMutex instead of ReleaseMutex. The
mutex leak was noticed later on and fixed in e4dfe108371, but the bogus
MutexRelease line was never removed, so do it now.
Link: https://github.com/acpica/acpica/pull/982
Fixes: c27f3d011b08 ("ACPICA: Fix race in generic_serial_bus (I2C) and GPIO op_region parameter handling")
Signed-off-by: Daniil Tatianin
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
commit bd85ca6cf9a462152ab675e898faa4d0a35f0b3a
Author: Daniel Borkmann
Date: Tue Dec 10 15:12:45 2024 +0100
team: Fix feature propagation of NETIF_F_GSO_ENCAP_ALL
[ Upstream commit 98712844589e06d9aa305b5077169942139fd75c ]
Similar to bonding driver, add NETIF_F_GSO_ENCAP_ALL to TEAM_VLAN_FEATURES
in order to support slave devices which propagate NETIF_F_GSO_UDP_TUNNEL &
NETIF_F_GSO_UDP_TUNNEL_CSUM as vlan_features.
Fixes: 3625920b62c3 ("teaming: fix vlan_features computing")
Signed-off-by: Daniel Borkmann
Cc: Nikolay Aleksandrov
Cc: Ido Schimmel
Cc: Jiri Pirko
Reviewed-by: Nikolay Aleksandrov
Reviewed-by: Hangbin Liu
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Paolo Abeni
Signed-off-by: Sasha Levin
commit 2f780d4c3b640d457470c2872569ce8142d116cf
Author: Daniel Borkmann
Date: Tue Dec 10 15:12:43 2024 +0100
bonding: Fix feature propagation of NETIF_F_GSO_ENCAP_ALL
[ Upstream commit 77b11c8bf3a228d1c63464534c2dcc8d9c8bf7ff ]
Drivers like mlx5 expose NIC's vlan_features such as
NETIF_F_GSO_UDP_TUNNEL & NETIF_F_GSO_UDP_TUNNEL_CSUM which are
later not propagated when the underlying devices are bonded and
a vlan device created on top of the bond.
Right now, the more cumbersome workaround for this is to create
the vlan on top of the mlx5 and then enslave the vlan devices
to a bond.
To fix this, add NETIF_F_GSO_ENCAP_ALL to BOND_VLAN_FEATURES
such that bond_compute_features() can probe and propagate the
vlan_features from the slave devices up to the vlan device.
Given the following bond:
# ethtool -i enp2s0f{0,1}np{0,1}
driver: mlx5_core
[...]
# ethtool -k enp2s0f0np0 | grep udp
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
tx-udp-segmentation: on
rx-udp_tunnel-port-offload: on
rx-udp-gro-forwarding: off
# ethtool -k enp2s0f1np1 | grep udp
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
tx-udp-segmentation: on
rx-udp_tunnel-port-offload: on
rx-udp-gro-forwarding: off
# ethtool -k bond0 | grep udp
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
tx-udp-segmentation: on
rx-udp_tunnel-port-offload: off [fixed]
rx-udp-gro-forwarding: off
Before:
# ethtool -k bond0.100 | grep udp
tx-udp_tnl-segmentation: off [requested on]
tx-udp_tnl-csum-segmentation: off [requested on]
tx-udp-segmentation: on
rx-udp_tunnel-port-offload: off [fixed]
rx-udp-gro-forwarding: off
After:
# ethtool -k bond0.100 | grep udp
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
tx-udp-segmentation: on
rx-udp_tunnel-port-offload: off [fixed]
rx-udp-gro-forwarding: off
Various users have run into this reporting performance issues when
configuring Cilium in vxlan tunneling mode and having the combination
of bond & vlan for the core devices connecting the Kubernetes cluster
to the outside world.
Fixes: a9b3ace44c7d ("bonding: fix vlan_features computing")
Signed-off-by: Daniel Borkmann
Cc: Nikolay Aleksandrov
Cc: Ido Schimmel
Cc: Jiri Pirko
Reviewed-by: Nikolay Aleksandrov
Reviewed-by: Hangbin Liu
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Paolo Abeni
Signed-off-by: Sasha Levin
commit c2047b0e216c8edce227d7c42f99ac2877dad0e4
Author: Martin Ottens
Date: Tue Dec 10 14:14:11 2024 +0100
net/sched: netem: account for backlog updates from child qdisc
[ Upstream commit f8d4bc455047cf3903cd6f85f49978987dbb3027 ]
In general, 'qlen' of any classful qdisc should keep track of the
number of packets that the qdisc itself and all of its children holds.
In case of netem, 'qlen' only accounts for the packets in its internal
tfifo. When netem is used with a child qdisc, the child qdisc can use
'qdisc_tree_reduce_backlog' to inform its parent, netem, about created
or dropped SKBs. This function updates 'qlen' and the backlog statistics
of netem, but netem does not account for changes made by a child qdisc.
'qlen' then indicates the wrong number of packets in the tfifo.
If a child qdisc creates new SKBs during enqueue and informs its parent
about this, netem's 'qlen' value is increased. When netem dequeues the
newly created SKBs from the child, the 'qlen' in netem is not updated.
If 'qlen' reaches the configured sch->limit, the enqueue function stops
working, even though the tfifo is not full.
Reproduce the bug:
Ensure that the sender machine has GSO enabled. Configure netem as root
qdisc and tbf as its child on the outgoing interface of the machine
as follows:
$ tc qdisc add dev root handle 1: netem delay 100ms limit 100
$ tc qdisc add dev parent 1:0 tbf rate 50Mbit burst 1542 latency 50ms
Send bulk TCP traffic out via this interface, e.g., by running an iPerf3
client on the machine. Check the qdisc statistics:
$ tc -s qdisc show dev
Statistics after 10s of iPerf3 TCP test before the fix (note that
netem's backlog > limit, netem stopped accepting packets):
qdisc netem 1: root refcnt 2 limit 1000 delay 100ms
Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0)
backlog 4294528236b 1155p requeues 0
qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms
Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0)
backlog 0b 0p requeues 0
Statistics after the fix:
qdisc netem 1: root refcnt 2 limit 1000 delay 100ms
Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms
Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0)
backlog 0b 0p requeues 0
tbf segments the GSO SKBs (tbf_segment) and updates the netem's 'qlen'.
The interface fully stops transferring packets and "locks". In this case,
the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is at
its limit and no more packets are accepted.
This patch adds a counter for the entries in the tfifo. Netem's 'qlen' is
only decreased when a packet is returned by its dequeue function, and not
during enqueuing into the child qdisc. External updates to 'qlen' are thus
accounted for and only the behavior of the backlog statistics changes. As
in other qdiscs, 'qlen' then keeps track of how many packets are held in
netem and all of its children. As before, sch->limit remains as the
maximum number of packets in the tfifo. The same applies to netem's
backlog statistics.
Fixes: 50612537e9ab ("netem: fix classful handling")
Signed-off-by: Martin Ottens
Acked-by: Jamal Hadi Salim
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
commit beffa32a21e6aedae7a956c588cfea9503161c1b
Author: Paul Barker
Date: Tue Dec 3 14:37:29 2024 +0000
Documentation: PM: Clarify pm_runtime_resume_and_get() return value
[ Upstream commit ccb84dc8f4a02e7d30ffd388522996546b4d00e1 ]
Update the documentation to match the behaviour of the code.
pm_runtime_resume_and_get() always returns 0 on success, even if
__pm_runtime_resume() returns 1.
Fixes: 2c412337cfe6 ("PM: runtime: Add documentation for pm_runtime_resume_and_get()")
Signed-off-by: Paul Barker
Link: https://patch.msgid.link/[email protected]
[ rjw: Subject and changelog edits, adjusted new comment formatting ]
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
commit 3561951e53f2112d9adce5201f9c9955cf9466b3
Author: Stefan Wahren
Date: Fri Dec 6 19:46:43 2024 +0100
qca_spi: Make driver probing reliable
[ Upstream commit becc6399ce3b724cffe9ccb7ef0bff440bb1b62b ]
The module parameter qcaspi_pluggable controls if QCA7000 signature
should be checked at driver probe (current default) or not. Unfortunately
this could fail in case the chip is temporary in reset, which isn't under
total control by the Linux host. So disable this check per default
in order to avoid unexpected probe failures.
Fixes: 291ab06ecf67 ("net: qualcomm: new Ethernet over SPI driver for QCA7000")
Signed-off-by: Stefan Wahren
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
commit 4f488db386c262c7829075f25de54b9542e538e8
Author: Stefan Wahren
Date: Fri Dec 6 19:46:42 2024 +0100
qca_spi: Fix clock speed for multiple QCA7000
[ Upstream commit 4dba406fac06b009873fe7a28231b9b7e4288b09 ]
Storing the maximum clock speed in module parameter qcaspi_clkspeed
has the unintended side effect that the first probed instance
defines the value for all other instances. Fix this issue by storing
it in max_speed_hz of the relevant SPI device.
This fix keeps the priority of the speed parameter (module parameter,
device tree property, driver default). Btw this uses the opportunity
to get the rid of the unused member clkspeed.
Fixes: 291ab06ecf67 ("net: qualcomm: new Ethernet over SPI driver for QCA7000")
Signed-off-by: Stefan Wahren
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
commit d45e3e1a77fdf1a889d8a6c962aac2dc9f84eb34
Author: Anumula Murali Mohan Reddy
Date: Fri Dec 6 11:50:14 2024 +0530
cxgb4: use port number to set mac addr
[ Upstream commit 356983f569c1f5991661fc0050aa263792f50616 ]
t4_set_vf_mac_acl() uses pf to set mac addr, but t4vf_get_vf_mac_acl()
uses port number to get mac addr, this leads to error when an attempt
to set MAC address on VF's of PF2 and PF3.
This patch fixes the issue by using port number to set mac address.
Fixes: e0cdac65ba26 ("cxgb4vf: configure ports accessible by the VF")
Signed-off-by: Anumula Murali Mohan Reddy
Signed-off-by: Potnuri Bharat Teja
Reviewed-by: Simon Horman
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
commit 78079fda4829020c76b1e607ea40423c54ac49ec
Author: Ilpo Järvinen
Date: Mon Dec 2 12:06:13 2024 +0200
ACPI: resource: Fix memory resource type union access
[ Upstream commit 7899ca9f3bd2b008e9a7c41f2a9f1986052d7e96 ]
In acpi_decode_space() addr->info.mem.caching is checked on main level
for any resource type but addr->info.mem is part of union and thus
valid only if the resource type is memory range.
Move the check inside the preceeding switch/case to only execute it
when the union is of correct type.
Fixes: fcb29bbcd540 ("ACPI: Add prefetch decoding to the address space parser")
Signed-off-by: Ilpo Järvinen
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
commit 9f82e8ace7d5f3f890d499f09fe2f3452fb85e35
Author: Daniel Machon
Date: Thu Dec 5 14:54:28 2024 +0100
net: sparx5: fix the maximum frame length register
[ Upstream commit ddd7ba006078a2bef5971b2dc5f8383d47f96207 ]
On port initialization, we configure the maximum frame length accepted
by the receive module associated with the port. This value is currently
written to the MAX_LEN field of the DEV10G_MAC_ENA_CFG register, when in
fact, it should be written to the DEV10G_MAC_MAXLEN_CFG register. Fix
this.
Fixes: 946e7fd5053a ("net: sparx5: add port module support")
Signed-off-by: Daniel Machon
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
commit 6cedf276444d487f1cb8c65214064f76eca1f3f0
Author: Daniel Machon
Date: Thu Dec 5 14:54:26 2024 +0100
net: sparx5: fix FDMA performance issue
[ Upstream commit f004f2e535e2b66ccbf5ac35f8eaadeac70ad7b7 ]
The FDMA handler is responsible for scheduling a NAPI poll, which will
eventually fetch RX packets from the FDMA queue. Currently, the FDMA
handler is run in a threaded context. For some reason, this kills
performance. Admittedly, I did not do a thorough investigation to see
exactly what causes the issue, however, I noticed that in the other
driver utilizing the same FDMA engine, we run the FDMA handler in hard
IRQ context.
Fix this performance issue, by running the FDMA handler in hard IRQ
context, not deferring any work to a thread.
Prior to this change, the RX UDP performance was:
Interval Transfer Bitrate Jitter
0.00-10.20 sec 44.6 MBytes 36.7 Mbits/sec 0.027 ms
After this change, the rx UDP performance is:
Interval Transfer Bitrate Jitter
0.00-9.12 sec 1.01 GBytes 953 Mbits/sec 0.020 ms
Fixes: 10615907e9b5 ("net: sparx5: switchdev: adding frame DMA functionality")
Signed-off-by: Daniel Machon
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
commit c21c7c1c00bcc60cf752ec491bdfd47693f4d3c7
Author: Eric Dumazet
Date: Wed Dec 4 14:10:31 2024 +0000
net: lapb: increase LAPB_HEADER_LEN
[ Upstream commit a6d75ecee2bf828ac6a1b52724aba0a977e4eaf4 ]
It is unclear if net/lapb code is supposed to be ready for 8021q.
We can at least avoid crashes like the following :
skbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:206 !
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 1 UID: 0 PID: 5508 Comm: dhcpcd Not tainted 6.12.0-rc7-syzkaller-00144-g66418447d27b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024
RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]
RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216
Code: 0d 8d 48 c7 c6 2e 9e 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 1a 6f 37 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3
RSP: 0018:ffffc90002ddf638 EFLAGS: 00010282
RAX: 0000000000000086 RBX: dffffc0000000000 RCX: 7a24750e538ff600
RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000
RBP: ffff888034a86650 R08: ffffffff8174b13c R09: 1ffff920005bbe60
R10: dffffc0000000000 R11: fffff520005bbe61 R12: 0000000000000140
R13: ffff88802824a400 R14: ffff88802824a3fe R15: 0000000000000016
FS: 00007f2a5990d740(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000110c2631fd CR3: 0000000029504000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
skb_push+0xe5/0x100 net/core/skbuff.c:2636
nr_header+0x36/0x320 net/netrom/nr_dev.c:69
dev_hard_header include/linux/netdevice.h:3148 [inline]
vlan_dev_hard_header+0x359/0x480 net/8021q/vlan_dev.c:83
dev_hard_header include/linux/netdevice.h:3148 [inline]
lapbeth_data_transmit+0x1f6/0x2a0 drivers/net/wan/lapbether.c:257
lapb_data_transmit+0x91/0xb0 net/lapb/lapb_iface.c:447
lapb_transmit_buffer+0x168/0x1f0 net/lapb/lapb_out.c:149
lapb_establish_data_link+0x84/0xd0
lapb_device_event+0x4e0/0x670
notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93
__dev_notify_flags+0x207/0x400
dev_change_flags+0xf0/0x1a0 net/core/dev.c:8922
devinet_ioctl+0xa4e/0x1aa0 net/ipv4/devinet.c:1188
inet_ioctl+0x3d7/0x4f0 net/ipv4/af_inet.c:1003
sock_do_ioctl+0x158/0x460 net/socket.c:1227
sock_ioctl+0x626/0x8e0 net/socket.c:1346
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: [email protected]
Closes: https://lore.kernel.org/netdev/[email protected]/T/#u
Signed-off-by: Eric Dumazet
Reviewed-by: Simon Horman
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
commit 22a94e0530b5e7a2d420f38f46c9a8ea91b89c64
Author: Thomas Weißschuh
Date: Tue Dec 3 18:09:55 2024 +0100
ptp: kvm: x86: Return EOPNOTSUPP instead of ENODEV from kvm_arch_ptp_init()
[ Upstream commit 5e7aa97c7acf171275ac02a8bb018c31b8918d13 ]
The caller, ptp_kvm_init(), emits a warning if kvm_arch_ptp_init() exits
with any error which is not EOPNOTSUPP:
"fail to initialize ptp_kvm"
Replace ENODEV with EOPNOTSUPP to avoid this spurious warning,
aligning with the ARM implementation.
Fixes: a86ed2cfa13c ("ptp: Don't print an error if ptp_kvm is not supported")
Signed-off-by: Thomas Weißschuh
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
commit 143304277ffd538f7f022ecba9a75c75408a3d32
Author: Jeremi Piotrowski
Date: Wed Mar 8 15:05:31 2023 +0000
ptp: kvm: Use decrypted memory in confidential guest on x86
[ Upstream commit 6365ba64b4dbe8b59ddaeaa724b281f3787715d5 ]
KVM_HC_CLOCK_PAIRING currently fails inside SEV-SNP guests because the
guest passes an address to static data to the host. In confidential
computing the host can't access arbitrary guest memory so handling the
hypercall runs into an "rmpfault". To make the hypercall work, the guest
needs to explicitly mark the memory as decrypted. Do that in
kvm_arch_ptp_init(), but retain the previous behavior for
non-confidential guests to save us from having to allocate memory.
Add a new arch-specific function (kvm_arch_ptp_exit()) to free the
allocation and mark the memory as encrypted again.
Signed-off-by: Jeremi Piotrowski
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski
Stable-dep-of: 5e7aa97c7acf ("ptp: kvm: x86: Return EOPNOTSUPP instead of ENODEV from kvm_arch_ptp_init()")
Signed-off-by: Sasha Levin
commit 80a0c4dc6641bb80e6b1a7acbd9f0bd2c07a0364
Author: Danielle Ratson
Date: Thu Dec 5 17:36:00 2024 +0100
selftests: mlxsw: sharedbuffer: Remove duplicate test cases
[ Upstream commit 6c46ad4d1bb2e8ec2265296e53765190f6e32f33 ]
On both port_tc_ip_test() and port_tc_arp_test(), the max occupancy is
checked on $h2 twice, when only the error message is different and does not
match the check itself.
Remove the two duplicated test cases from the test.
Fixes: a865ad999603 ("selftests: mlxsw: Add shared buffer traffic test")
Signed-off-by: Danielle Ratson
Reviewed-by: Ido Schimmel
Signed-off-by: Ido Schimmel
Signed-off-by: Petr Machata
Link: https://patch.msgid.link/d9eb26f6fc16a06a30b5c2c16ad80caf502bc561.1733414773.git.petrm@nvidia.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
commit b4eb6df5bc26138d1d40435c7a566a2c5bc8be76
Author: Danielle Ratson
Date: Thu Dec 5 17:35:59 2024 +0100
selftests: mlxsw: sharedbuffer: Remove h1 ingress test case
[ Upstream commit cf3515c556907b4da290967a2a6cbbd9ee0ee723 ]
The test is sending only one packet generated with mausezahn from $h1 to
$h2. However, for some reason, it is testing for non-zero maximum occupancy
in both the ingress pool of $h1 and $h2. The former only passes when $h2
happens to send a packet.
Avoid intermittent failures by removing unintentional test case
regarding the ingress pool of $h1.
Fixes: a865ad999603 ("selftests: mlxsw: Add shared buffer traffic test")
Signed-off-by: Danielle Ratson
Reviewed-by: Ido Schimmel
Signed-off-by: Ido Schimmel
Signed-off-by: Petr Machata
Link: https://patch.msgid.link/5b7344608d5e06f38209e48d8af8c92fa11b6742.1733414773.git.petrm@nvidia.com
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
commit 07b569eda6fe6a1e83be5a587abee12d1303f95e
Author: Eric Dumazet
Date: Wed Dec 4 17:05:48 2024 +0000
tipc: fix NULL deref in cleanup_bearer()
[ Upstream commit b04d86fff66b15c07505d226431f808c15b1703c ]
syzbot found [1] that after blamed commit, ub->ubsock->sk
was NULL when attempting the atomic_dec() :
atomic_dec(&tipc_net(sock_net(ub->ubsock->sk))->wq_count);
Fix this by caching the tipc_net pointer.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
CPU: 0 UID: 0 PID: 5896 Comm: kworker/0:3 Not tainted 6.13.0-rc1-next-20241203-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: events cleanup_bearer
RIP: 0010:read_pnet include/net/net_namespace.h:387 [inline]
RIP: 0010:sock_net include/net/sock.h:655 [inline]
RIP: 0010:cleanup_bearer+0x1f7/0x280 net/tipc/udp_media.c:820
Code: 18 48 89 d8 48 c1 e8 03 42 80 3c 28 00 74 08 48 89 df e8 3c f7 99 f6 48 8b 1b 48 83 c3 30 e8 f0 e4 60 00 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00 74 08 48 89 df e8 1a f7 99 f6 49 83 c7 e8 48 8b 1b
RSP: 0018:ffffc9000410fb70 EFLAGS: 00010206
RAX: 0000000000000006 RBX: 0000000000000030 RCX: ffff88802fe45a00
RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffc9000410f900
RBP: ffff88807e1f0908 R08: ffffc9000410f907 R09: 1ffff92000821f20
R10: dffffc0000000000 R11: fffff52000821f21 R12: ffff888031d19980
R13: dffffc0000000000 R14: dffffc0000000000 R15: ffff88807e1f0918
FS: 0000000000000000(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000556ca050b000 CR3: 0000000031c0c000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Fixes: 6a2fa13312e5 ("tipc: Fix use-after-free of kernel socket in cleanup_bearer().")
Reported-by: [email protected]
Closes: https://lore.kernel.org/netdev/[email protected]/T/#u
Signed-off-by: Eric Dumazet
Reviewed-by: Kuniyuki Iwashima
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
commit a864e2e1ceda0a68116c66dff25687a46b5c25a8
Author: Remi Pommarel
Date: Fri Nov 22 16:52:50 2024 +0100
batman-adv: Do not let TT changes list grows indefinitely
[ Upstream commit fff8f17c1a6fc802ca23bbd3a276abfde8cc58e6 ]
When TT changes list is too big to fit in packet due to MTU size, an
empty OGM is sent expected other node to send TT request to get the
changes. The issue is that tt.last_changeset was not built thus the
originator was responding with previous changes to those TT requests
(see batadv_send_my_tt_response). Also the changes list was never
cleaned up effectively never ending growing from this point onwards,
repeatedly sending the same TT response changes over and over, and
creating a new empty OGM every OGM interval expecting for the local
changes to be purged.
When there is more TT changes that can fit in packet, drop all changes,
send empty OGM and wait for TT request so we can respond with a full
table instead.
Fixes: e1bf0c14096f ("batman-adv: tvlv - convert tt data sent within OGMs")
Signed-off-by: Remi Pommarel
Acked-by: Antonio Quartulli
Signed-off-by: Sven Eckelmann
Signed-off-by: Simon Wunderlich
Signed-off-by: Sasha Levin
commit b0b2157b3c27445ebd16a23a77a01c86aaae26c7
Author: Remi Pommarel
Date: Fri Nov 22 16:52:49 2024 +0100
batman-adv: Remove uninitialized data in full table TT response
[ Upstream commit 8038806db64da15721775d6b834990cacbfcf0b2 ]
The number of entries filled by batadv_tt_tvlv_generate() can be less
than initially expected in batadv_tt_prepare_tvlv_{global,local}_data()
(changes can be removed by batadv_tt_local_event() in ADD+DEL sequence
in the meantime as the lock held during the whole tvlv global/local data
generation).
Thus tvlv_len could be bigger than the actual TT entry size that need
to be sent so full table TT_RESPONSE could hold invalid TT entries such
as below.
* 00:00:00:00:00:00 -1 [....] ( 0) 88:12:4e:ad:7e:ba (179) (0x45845380)
* 00:00:00:00:78:79 4092 [.W..] ( 0) 88:12:4e:ad:7e:3c (145) (0x8ebadb8b)
Remove the extra allocated space to avoid sending uninitialized entries
for full table TT_RESPONSE in both batadv_send_other_tt_response() and
batadv_send_my_tt_response().
Fixes: 7ea7b4a14275 ("batman-adv: make the TT CRC logic VLAN specific")
Signed-off-by: Remi Pommarel
Signed-off-by: Sven Eckelmann
Signed-off-by: Simon Wunderlich
Signed-off-by: Sasha Levin
commit 437529aa7d019186ea9d07302f89a90e9eaf82be
Author: Remi Pommarel
Date: Fri Nov 22 16:52:48 2024 +0100
batman-adv: Do not send uninitialized TT changes
[ Upstream commit f2f7358c3890e7366cbcb7512b4bc8b4394b2d61 ]
The number of TT changes can be less than initially expected in
batadv_tt_tvlv_container_update() (changes can be removed by
batadv_tt_local_event() in ADD+DEL sequence between reading
tt_diff_entries_num and actually iterating the change list under lock).
Thus tt_diff_len could be bigger than the actual changes size that need
to be sent. Because batadv_send_my_tt_response sends the whole
packet, uninitialized data can be interpreted as TT changes on other
nodes leading to weird TT global entries on those nodes such as:
* 00:00:00:00:00:00 -1 [....] ( 0) 88:12:4e:ad:7e:ba (179) (0x45845380)
* 00:00:00:00:78:79 4092 [.W..] ( 0) 88:12:4e:ad:7e:3c (145) (0x8ebadb8b)
All of the above also applies to OGM tvlv container buffer's tvlv_len.
Remove the extra allocated space to avoid sending uninitialized TT
changes in batadv_send_my_tt_response() and batadv_v_ogm_send_softif().
Fixes: e1bf0c14096f ("batman-adv: tvlv - convert tt data sent within OGMs")
Signed-off-by: Remi Pommarel
Signed-off-by: Sven Eckelmann
Signed-off-by: Simon Wunderlich
Signed-off-by: Sasha Levin
commit bbdb3307f609ec4dc9558770f464ede01fe52aed
Author: Suraj Sonawane
Date: Mon Nov 18 21:56:09 2024 +0530
acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl
[ Upstream commit 265e98f72bac6c41a4492d3e30a8e5fd22fe0779 ]
Fix an issue detected by syzbot with KASAN:
BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/
core.c:416 [inline]
BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0
drivers/acpi/nfit/core.c:459
The issue occurs in cmd_to_func when the call_pkg->nd_reserved2
array is accessed without verifying that call_pkg points to a buffer
that is appropriately sized as a struct nd_cmd_pkg. This can lead
to out-of-bounds access and undefined behavior if the buffer does not
have sufficient space.
To address this, a check was added in acpi_nfit_ctl() to ensure that
buf is not NULL and that buf_len is less than sizeof(*call_pkg)
before accessing it. This ensures safe access to the members of
call_pkg, including the nd_reserved2 array.
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=7534f060ebda6b8b51b3
Tested-by: [email protected]
Fixes: ebe9f6f19d80 ("acpi/nfit: Fix bus command validation")
Signed-off-by: Suraj Sonawane
Reviewed-by: Alison Schofield
Reviewed-by: Dave Jiang
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Ira Weiny
Signed-off-by: Sasha Levin
commit c052f775ee6ccacd3c97e4cf41a2a657e63d4259
Author: Sungjong Seo
Date: Fri May 31 19:14:44 2024 +0900
exfat: fix potential deadlock on __exfat_get_dentry_set
commit 89fc548767a2155231128cb98726d6d2ea1256c9 upstream.
When accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array
is allocated in __exfat_get_entry_set. The problem is that the bh-array is
allocated with GFP_KERNEL. It does not make sense. In the following cases,
a deadlock for sbi->s_lock between the two processes may occur.
CPU0 CPU1
---- ----
kswapd
balance_pgdat
lock(fs_reclaim)
exfat_iterate
lock(&sbi->s_lock)
exfat_readdir
exfat_get_uniname_from_ext_entry
exfat_get_dentry_set
__exfat_get_dentry_set
kmalloc_array
...
lock(fs_reclaim)
...
evict
exfat_evict_inode
lock(&sbi->s_lock)
To fix this, let's allocate bh-array with GFP_NOFS.
Fixes: a3ff29a95fde ("exfat: support dynamic allocate bh for exfat_entry_set_cache")
Cc: [email protected] # v6.2+
Reported-by: [email protected]
Closes: https://lore.kernel.org/lkml/[email protected]
Signed-off-by: Sungjong Seo
Signed-off-by: Namjae Jeon
[Sherry: The problematic commit was backported to 5.15.y and 5.10.y, thus backport this fix]
Signed-off-by: Sherry Yang
Signed-off-by: Greg Kroah-Hartman
commit 4310902c766e371359e6c6311056ae80b5beeac9
Author: Michal Luczaj
Date: Thu Nov 7 21:46:12 2024 +0100
virtio/vsock: Fix accept_queue memory leak
commit d7b0ff5a866724c3ad21f2628c22a63336deec3f upstream.
As the final stages of socket destruction may be delayed, it is possible
that virtio_transport_recv_listen() will be called after the accept_queue
has been flushed, but before the SOCK_DONE flag has been set. As a result,
sockets enqueued after the flush would remain unremoved, leading to a
memory leak.
vsock_release
__vsock_release
lock
virtio_transport_release
virtio_transport_close
schedule_delayed_work(close_work)
sk_shutdown = SHUTDOWN_MASK
(!) flush accept_queue
release
virtio_transport_recv_pkt
vsock_find_bound_socket
lock
if flag(SOCK_DONE) return
virtio_transport_recv_listen
child = vsock_create_connected
(!) vsock_enqueue_accept(child)
release
close_work
lock
virtio_transport_do_close
set_flag(SOCK_DONE)
virtio_transport_remove_sock
vsock_remove_sock
vsock_remove_bound
release
Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during
socket destruction.
unreferenced object 0xffff888109e3f800 (size 2040):
comm "kworker/5:2", pid 371, jiffies 4294940105
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............
backtrace (crc 9e5f4e84):
[] kmem_cache_alloc_noprof+0x2c1/0x360
[] sk_prot_alloc+0x30/0x120
[] sk_alloc+0x2c/0x4b0
[] __vsock_create.constprop.0+0x2a/0x310
[] virtio_transport_recv_pkt+0x4dc/0x9a0
[] vsock_loopback_work+0xfd/0x140
[] process_one_work+0x20c/0x570
[] worker_thread+0x1bf/0x3a0
[] kthread+0xdd/0x110
[] ret_from_fork+0x2d/0x50
[] ret_from_fork_asm+0x1a/0x30
Fixes: 3fe356d58efa ("vsock/virtio: discard packets only when socket is really closed")
Reviewed-by: Stefano Garzarella
Signed-off-by: Michal Luczaj
Signed-off-by: Paolo Abeni
[ Adapted due to missing commit 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") ]
Signed-off-by: Tomas Krcka
Signed-off-by: Greg Kroah-Hartman
commit 43e76736b4bf5be81d1749676e1554d47ff48981
Author: Michal Luczaj
Date: Mon Dec 2 12:29:23 2024 +0100
bpf, sockmap: Fix update element with same
commit 75e072a390da9a22e7ae4a4e8434dfca5da499fb upstream.
Consider a sockmap entry being updated with the same socket:
osk = stab->sks[idx];
sock_map_add_link(psock, link, map, &stab->sks[idx]);
stab->sks[idx] = sk;
if (osk)
sock_map_unref(osk, &stab->sks[idx]);
Due to sock_map_unref(), which invokes sock_map_del_link(), all the
psock's links for stab->sks[idx] are torn:
list_for_each_entry_safe(link, tmp, &psock->link, list) {
if (link->link_raw == link_raw) {
...
list_del(&link->list);
sk_psock_free_link(link);
}
}
And that includes the new link sock_map_add_link() added just before
the unref.
This results in a sockmap holding a socket, but without the respective
link. This in turn means that close(sock) won't trigger the cleanup,
i.e. a closed socket will not be automatically removed from the sockmap.
Stop tearing the links when a matching link_raw is found.
Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: Michal Luczaj
Signed-off-by: Daniel Borkmann
Reviewed-by: John Fastabend
Link: https://lore.kernel.org/bpf/[email protected]
Signed-off-by: Greg Kroah-Hartman
commit 3560e2028374e41e84bdf2304194f07b8d94baa2
Author: Darrick J. Wong
Date: Mon Dec 2 10:57:32 2024 -0800
xfs: fix scrub tracepoints when inode-rooted btrees are involved
commit ffc3ea4f3c1cc83a86b7497b0c4b0aee7de5480d upstream.
Fix a minor mistakes in the scrub tracepoints that can manifest when
inode-rooted btrees are enabled. The existing code worked fine for bmap
btrees, but we should tighten the code up to be less sloppy.
Cc: # v5.7
Fixes: 92219c292af8dd ("xfs: convert btree cursor inode-private member names")
Signed-off-by: "Darrick J. Wong"
Reviewed-by: Christoph Hellwig
Signed-off-by: Greg Kroah-Hartman
commit 58d71a547717fb1342db2d019e7eb39ff143bb92
Author: Darrick J. Wong
Date: Mon Dec 2 10:57:43 2024 -0800
xfs: return from xfs_symlink_verify early on V4 filesystems
commit 7f8b718c58783f3ff0810b39e2f62f50ba2549f6 upstream.
V4 symlink blocks didn't have headers, so return early if this is a V4
filesystem.
Cc: # v5.1
Fixes: 39708c20ab5133 ("xfs: miscellaneous verifier magic value fixups")
Signed-off-by: "Darrick J. Wong"
Reviewed-by: Christoph Hellwig
Signed-off-by: Greg Kroah-Hartman
commit 5ff4d29a675f670bd31be870ba900757a7f822af
Author: Darrick J. Wong
Date: Mon Dec 2 10:57:27 2024 -0800
xfs: don't drop errno values when we fail to ficlone the entire range
commit 7ce31f20a0771d71779c3b0ec9cdf474cc3c8e9a upstream.
Way back when we first implemented FICLONE for XFS, life was simple --
either the the entire remapping completed, or something happened and we
had to return an errno explaining what happened. Neither of those
ioctls support returning partial results, so it's all or nothing.
Then things got complicated when copy_file_range came along, because it
actually can return the number of bytes copied, so commit 3f68c1f562f1e4
tried to make it so that we could return a partial result if the
REMAP_FILE_CAN_SHORTEN flag is set. This is also how FIDEDUPERANGE can
indicate that the kernel performed a partial deduplication.
Unfortunately, the logic is wrong if an error stops the remapping and
CAN_SHORTEN is not set. Because those callers cannot return partial
results, it is an error for ->remap_file_range to return a positive
quantity that is less than the @len passed in. Implementations really
should be returning a negative errno in this case, because that's what
btrfs (which introduced FICLONE{,RANGE}) did.
Therefore, ->remap_range implementations cannot silently drop an errno
that they might have when the number of bytes remapped is less than the
number of bytes requested and CAN_SHORTEN is not set.
Found by running generic/562 on a 64k fsblock filesystem and wondering
why it reported corrupt files.
Cc: # v4.20
Fixes: 3fc9f5e409319e ("xfs: remove xfs_reflink_remap_range")
Really-Fixes: 3f68c1f562f1e4 ("xfs: support returning partial reflink results")
Signed-off-by: "Darrick J. Wong"
Reviewed-by: Christoph Hellwig
Signed-off-by: Greg Kroah-Hartman
commit fd157244902ae2e04298b3853e479688c23dcb40
Author: Darrick J. Wong
Date: Mon Dec 2 10:57:31 2024 -0800
xfs: update btree keys correctly when _insrec splits an inode root block
commit 6d7b4bc1c3e00b1a25b7a05141a64337b4629337 upstream.
In commit 2c813ad66a72, I partially fixed a bug wherein xfs_btree_insrec
would erroneously try to update the parent's key for a block that had
been split if we decided to insert the new record into the new block.
The solution was to detect this situation and update the in-core key
value that we pass up to the caller so that the caller will (eventually)
add the new block to the parent level of the tree with the correct key.
However, I missed a subtlety about the way inode-rooted btrees work. If
the full block was a maximally sized inode root block, we'll solve that
fullness by moving the root block's records to a new block, resizing the
root block, and updating the root to point to the new block. We don't
pass a pointer to the new block to the caller because that work has
already been done. The new record will /always/ land in the new block,
so in this case we need to use xfs_btree_update_keys to update the keys.
This bug can theoretically manifest itself in the very rare case that we
split a bmbt root block and the new record lands in the very first slot
of the new block, though I've never managed to trigger it in practice.
However, it is very easy to reproduce by running generic/522 with the
realtime rmapbt patchset if rtinherit=1.
Cc: # v4.8
Fixes: 2c813ad66a7218 ("xfs: support btrees with overlapping intervals for keys")
Signed-off-by: "Darrick J. Wong"
Reviewed-by: Christoph Hellwig
Signed-off-by: Greg Kroah-Hartman
commit 85128462d34869e78d4644402633a817c458cecc
Author: Jiasheng Jiang
Date: Wed Nov 27 20:10:42 2024 +0000
drm/i915: Fix memory leak by correcting cache object name in error handler
commit 2828e5808bcd5aae7fdcd169cac1efa2701fa2dd upstream.
Replace "slab_priorities" with "slab_dependencies" in the error handler
to avoid memory leak.
Fixes: 32eb6bcfdda9 ("drm/i915: Make request allocation caches global")
Cc: # v5.2+
Signed-off-by: Jiasheng Jiang
Reviewed-by: Nirmoy Das
Reviewed-by: Andi Shyti
Signed-off-by: Andi Shyti