CVE-2023-1382

What it actually does

Data race between con allocation and con->sock assignment in net/tipc/topsrv.c leads to NULL pointer dereference on con->sock->sk access in the TIPC protocol stack.

Why it matters to the business

Local denial-of-service via kernel crash on systems using TIPC, requiring reboots and potentially interrupting network-dependent workloads.

How an attack unfolds

Local attacker triggers concurrent TIPC connection setup paths to win the race between structure allocation and socket pointer assignment, resulting in NULL dereference and kernel panic.

How to fix it

Upgrade the Linux kernel to include commit 830b3c68c1fb1e9176028d02ef86f3cf76aa2476 or apply the equivalent vendor backport; rebuild and reboot.

How to confirm the fix worked

Verify the presence of commit 830b3c68c1fb1e9176028d02ef86f3cf76aa2476 in the running kernel source; attempt controlled race reproducer in a test environment to confirm absence of crash.

Typical attack path

1. Obtain local unprivileged access on a Linux system with TIPC enabled
2. Issue concurrent TIPC operations that race allocation against socket assignment in topsrv.c
3. Trigger access to con->sock->sk while the pointer remains NULL
4. Cause kernel NULL dereference panic

How to detect it

Search kernel logs and dmesg for NULL pointer dereference messages referencing tipc or topsrv.c; correlate with TIPC socket activity preceding the crash.

• NULL pointer dereference.*tipc
• net/tipc/topsrv.c
• con->sock->sk

What your security team should do

• Apply the referenced kernel commit or vendor update as soon as possible
• Disable the TIPC protocol module if it is not required for operations
• Monitor kernel logs for tipc-related NULL pointer oops