Syzkaller reported this issue [1].
The current sockmap has a dependency on sk_socket in both read and write
stages, but there is a possibility that sk->sk_socket is released during
the process, leading to panic situations. For a detailed reproduction,
please refer to the description in the v2:
https://lore.kernel.org/bpf/20250228055106.58071-1-jiayuan.chen@linux.dev/
The corresponding fix approaches are described in the commit messages of
each patch.
By the way, the current sockmap lacks statistical information, especially
global statistics, such as the number of successful or failed rx and tx
operations. These statistics cannot be obtained from the socket interface
itself.
These data will be of great help in troubleshooting issues and observing
sockmap behavior.
If the maintainer/reviewer does not object, I think we can provide these
statistical information in the future, either through proc/trace/bpftool.
[1] https://syzkaller.appspot.com/bug?extid=dd90a702f518e0eac072
---
v3 -> v4:
1. Rebase on -rc.
2. Incorporated valuable feedback from the v3 thread into the commit
message, making it easier to review.
https://lore.kernel.org/all/20250317092257.68760-3-jiayuan.chen@linux.dev/
v2 -> v3:
1. Michal Luczaj reported similar race issue under sockmap sending path.
2. Rcu lock is conflict with mutex_lock in unix socket read implementation.
https://lore.kernel.org/bpf/20250228055106.58071-1-jiayuan.chen@linux.dev/
v1 -> v2:
1. Add Fixes tag.
2. Extend selftest of edge case for TCP/UDP sockets.
3. Add Reviewed-by and Acked-by tag.
https://lore.kernel.org/bpf/20250226132242.52663-1-jiayuan.chen@linux.dev/T…
Jiayuan Chen (3):
bpf, sockmap: avoid using sk_socket after free when sending
bpf, sockmap: avoid using sk_socket after free when reading
selftests/bpf: Add edge case tests for sockmap
net/core/skmsg.c | 22 ++++++-
.../selftests/bpf/prog_tests/socket_helpers.h | 13 +++-
.../selftests/bpf/prog_tests/sockmap_basic.c | 60 +++++++++++++++++++
3 files changed, 91 insertions(+), 4 deletions(-)
--
2.47.1
We can reproduce the issue using the existing test program:
'./test_sockmap --ktls'
Or use the selftest I provided, which will cause a panic:
------------[ cut here ]------------
kernel BUG at lib/iov_iter.c:629!
PKRU: 55555554
Call Trace:
<TASK>
? die+0x36/0x90
? do_trap+0xdd/0x100
? iov_iter_revert+0x178/0x180
? iov_iter_revert+0x178/0x180
? do_error_trap+0x7d/0x110
? iov_iter_revert+0x178/0x180
? exc_invalid_op+0x50/0x70
? iov_iter_revert+0x178/0x180
? asm_exc_invalid_op+0x1a/0x20
? iov_iter_revert+0x178/0x180
? iov_iter_revert+0x5c/0x180
tls_sw_sendmsg_locked.isra.0+0x794/0x840
tls_sw_sendmsg+0x52/0x80
? inet_sendmsg+0x1f/0x70
__sys_sendto+0x1cd/0x200
? find_held_lock+0x2b/0x80
? syscall_trace_enter+0x140/0x270
? __lock_release.isra.0+0x5e/0x170
? find_held_lock+0x2b/0x80
? syscall_trace_enter+0x140/0x270
? lockdep_hardirqs_on_prepare+0xda/0x190
? ktime_get_coarse_real_ts64+0xc2/0xd0
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x90/0x170
1. It looks like the issue started occurring after bpf being introduced to
ktls and later the addition of assertions to iov_iter has caused a panic.
If my fix tag is incorrect, please assist me in correcting the fix tag.
2. I make minimal changes for now, it's enough to make ktls work
correctly.
---
v1->v2: Added more content to the commit message
https://lore.kernel.org/all/20250123171552.57345-1-mrpre@163.com/#r
---
Jiayuan Chen (2):
bpf: fix ktls panic with sockmap
selftests/bpf: add ktls selftest
net/tls/tls_sw.c | 8 +-
.../selftests/bpf/prog_tests/sockmap_ktls.c | 174 +++++++++++++++++-
.../selftests/bpf/progs/test_sockmap_ktls.c | 26 +++
3 files changed, 205 insertions(+), 3 deletions(-)
create mode 100644 tools/testing/selftests/bpf/progs/test_sockmap_ktls.c
--
2.47.1
Hi Linus,
Please pull the following kselftest fixes update for Linux 6.15-rc2
Fixes tpm2, futex, and mincore tests. Creates a dedicated .gitignore
for tpm2
Details:
selftests: tpm2: test_smoke: use POSIX-conformant expression operator
selftests/futex: futex_waitv wouldblock test should fail
selftests: tpm2: create a dedicated .gitignore
selftests/mincore: Allow read-ahead pages to reach the end of the file
diff is attached.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit 0af2f6be1b4281385b618cb86ad946eded089ac8:
Linux 6.15-rc1 (2025-04-06 13:11:33 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest tags/linux_kselftest-fixes-6.15-rc2
for you to fetch changes up to 197c1eaa7ba633a482ed7588eea6fd4aa57e08d4:
selftests/mincore: Allow read-ahead pages to reach the end of the file (2025-04-08 17:08:50 -0600)
----------------------------------------------------------------
linux_kselftest-fixes-6.15-rc2
Fixes tpm2, futex, and mincore tests. Creates a dedicated .gitignore
for tpm2
Details:
selftests: tpm2: test_smoke: use POSIX-conformant expression operator
selftests/futex: futex_waitv wouldblock test should fail
selftests: tpm2: create a dedicated .gitignore
selftests/mincore: Allow read-ahead pages to reach the end of the file
----------------------------------------------------------------
Ahmed Salem (1):
selftests: tpm2: test_smoke: use POSIX-conformant expression operator
Edward Liaw (1):
selftests/futex: futex_waitv wouldblock test should fail
Khaled Elnaggar (1):
selftests: tpm2: create a dedicated .gitignore
Qiuxu Zhuo (1):
selftests/mincore: Allow read-ahead pages to reach the end of the file
tools/testing/selftests/.gitignore | 1 -
tools/testing/selftests/futex/functional/futex_wait_wouldblock.c | 2 +-
tools/testing/selftests/mincore/mincore_selftest.c | 3 ---
tools/testing/selftests/tpm2/.gitignore | 3 +++
tools/testing/selftests/tpm2/test_smoke.sh | 2 +-
5 files changed, 5 insertions(+), 6 deletions(-)
create mode 100644 tools/testing/selftests/tpm2/.gitignore
----------------------------------------------------------------
On Tue, 8 Apr 2025 20:18:26 +0200 Matthieu Baerts wrote:
> On 02/04/2025 19:23, Stanislav Fomichev wrote:
> > Recent change [0] resulted in a "BUG: using __this_cpu_read() in
> > preemptible" splat [1]. PREEMPT kernels have additional requirements
> > on what can and can not run with/without preemption enabled.
> > Expose those constrains in the debug kernels.
>
> Good idea to suggest this to find more bugs!
>
> I did some quick tests on my side with our CI, and the MPTCP selftests
> seem to take a bit more time, but without impacting the results.
> Hopefully, there will be no impact in slower/busy environments :)
What kind of slow down do you see? I think we get up to 50% more time
spent in the longer tests. Not sure how bad is too bad.. I'm leaning
towards applying this to net-next and we can see if people running
on linux-next complain?
Let me CC kselftests, patch in question:
https://lore.kernel.org/all/20250402172305.1775226-1-sdf@fomichev.me/
A fix [1] came in that fixed the notrace_filter side of the subops processing
of the function graph tracer. When I started testing that fix, I discovered
that the many more functions were being enabled than were being traced.
The function graph infrastructure uses ftrace to hook to functions. It has
a single ftrace_ops to manage all the users of function graph. Each
individual user (tracing, bpf, fprobes, etc) has its own ftrace_ops to
track the functions it will have its callback called from. These
ftrace_ops are "subops" to the main ftrace_ops of the function graph
infrastructure.
Each ftrace_ops has a filter_hash and a notrace_hash that is defined as:
Only trace functions that are in the filter_hash but not in the
notrace_hash.
If the filter_hash is empty, it means to trace all functions.
If the notrace_hash is empty, it means do not disable any function.
The function graph main ftrace_ops needs to be a superset containing all
the functions to be traced by all the subops it has. The algorithm to
perform this merge was incorrect. It was merging the filter_hashes
of all the subops and taking the intersect of all the notrace_hashes
of the subops. But by taking the intersect of all the notrace_hashes
it ignored how those notrace_hashes are dependent on the associated
filter_hashes of each individual subops.
Instead, modify the algorithm to be a bit simpler and correct.
First, when adding a new subops, do not add the notrace_hash if the
filter_hash is not empty. Instead, just add the functions that are in the
filter_hash of the subops but not in the notrace_hash of the subops into the
main ops filter_hash. There's no reason to add anything to the main ops
notrace_hash for this case.
The notrace_hash of the main ops should only be non empty iff all subops
filter_hashes are empty (meaning to trace all functions) and all subops
notrace_hashes have the same functions.
That is, the main ops notrace_hash is empty if any subops filter_hash is
non empty.
The main ops notrace_hash only has content in it if all subops
filter_hashes are empty, and the content are only functions that intersect
all the subops notrace_hashes. If any subops notrace_hash is empty, then
so is the main ops notrace_hash.
[1] https://lore.kernel.org/all/20250408160258.48563-1-andybnac@gmail.com/
Steven Rostedt (2):
ftrace: Fix accounting of subop hashes
tracing/selftest: Add test to better test subops filtering of function graph
----
kernel/trace/ftrace.c | 314 ++++++++++++---------
.../ftrace/test.d/ftrace/fgraph-multi-filter.tc | 177 ++++++++++++
2 files changed, 354 insertions(+), 137 deletions(-)
create mode 100644 tools/testing/selftests/ftrace/test.d/ftrace/fgraph-multi-filter.tc
On 09/04/2025 3:24 pm, Mark Brown wrote:
> On Wed, Apr 09, 2025 at 11:45:44AM +0100, Richard Fitzgerald wrote:
>> Depend on SND_SOC_CS_AMP_LIB instead of selecting it.
>>
>> KUNIT_ALL_TESTS should only build tests for components that are
>> already being built, it should not cause other stuff to be added
>> to the build.
>
>> config SND_SOC_CS_AMP_LIB_TEST
>> - tristate "KUnit test for Cirrus Logic cs-amp-lib"
>> - depends on KUNIT
>> + tristate "KUnit test for Cirrus Logic cs-amp-lib" if !KUNIT_ALL_TESTS
>> + depends on SND_SOC_CS_AMP_LIB && KUNIT
>> default KUNIT_ALL_TESTS
>> - select SND_SOC_CS_AMP_LIB
>> help
>> This builds KUnit tests for the Cirrus Logic common
>> amplifier library.
>
> This by itself results in the Cirrus tests being removed from a kunit
> --alltests run which is a regression in coverage. I'd expect to see
> some corresponding updates in the KUnit all_tests.config to keep them
> enabled.
That's the defined behaviour of KUNIT_ALL_TESTS. It shouldn't have been
running as part of an alltests if nothing had selected it. That seems to
make people angry. Probably the same people who would complain if there
was a bug in the code that they didn't want to test.
This patch series was motivated by fixing a few bugs in the bonding
driver related to xfrm state migration on device failover.
struct xfrm_dev_offload has two net_device pointers: dev and real_dev.
The first one is the device the xfrm_state is offloaded on and the
second one is used by the bonding driver to manage the underlying device
xfrm_states are actually offloaded on. When bonding isn't used, the two
pointers are the same.
This causes confusion in drivers: Which device pointer should they use?
If they want to support bonding, they need to only use real_dev and
never look at dev.
Furthermore, real_dev is used without proper locking from multiple code
paths and changing it is dangerous. See commit [1] for example.
This patch series clears things out by removing all uses of real_dev
from outside the bonding driver.
Then, the bonding driver is refactored to fix a couple of long standing
races and the original bug which motivated this patch series.
[1] commit f8cde9805981 ("bonding: fix xfrm real_dev null pointer
dereference")
Cosmin Ratiu (6):
Cleaning up unnecessary uses of xso.real_dev:
net/mlx5: Avoid using xso.real_dev unnecessarily
xfrm: Use xdo.dev instead of xdo.real_dev
xfrm: Remove unneeded device check from validate_xmit_xfrm
Refactoring device operations to get an explicit device pointer:
xfrm: Add explicit dev to .xdo_dev_state_{add,delete,free}
Fixing a bonding xfrm state migration bug:
bonding: Mark active offloaded xfrm_states
Fixing long standing races in bonding:
bonding: Fix multiple long standing offload races
Documentation/networking/xfrm_device.rst | 10 +-
drivers/net/bonding/bond_main.c | 93 +++++++++++--------
.../net/ethernet/chelsio/cxgb4/cxgb4_main.c | 20 ++--
.../inline_crypto/ch_ipsec/chcr_ipsec.c | 18 ++--
.../net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 40 ++++----
drivers/net/ethernet/intel/ixgbevf/ipsec.c | 20 ++--
.../marvell/octeontx2/nic/cn10k_ipsec.c | 18 ++--
.../mellanox/mlx5/core/en_accel/ipsec.c | 28 +++---
.../mellanox/mlx5/core/en_accel/ipsec.h | 1 +
.../net/ethernet/netronome/nfp/crypto/ipsec.c | 11 +--
drivers/net/netdevsim/ipsec.c | 15 ++-
include/linux/netdevice.h | 10 +-
include/net/xfrm.h | 8 ++
net/xfrm/xfrm_device.c | 13 +--
net/xfrm/xfrm_state.c | 16 ++--
15 files changed, 175 insertions(+), 146 deletions(-)
--
2.45.0