# CVE-2024-26732: linux: In the Linux kernel, the following vulnerability has been resolved:  net: implement lockless setsockopt(SO_PEEK_OFF)...

CVE-2024-26732 is fixed in linux on 1 platform, first by DEBIAN-CVE-2024-26732, released April 3, 2024. It is not reported as exploited. Patch Radar priority: Routine.

- Web page: https://patchblox.com/security/cve/CVE-2024-26732
- Priority: Routine
- CVSS: 5.5 (medium)
- EPSS: 0.0016
- CISA KEV: not listed
- Exploited (vendor report): no
- Publicly disclosed: no
- Published: Apr 3, 2024

## Description

In the Linux kernel, the following vulnerability has been resolved:  net: implement lockless setsockopt(SO_PEEK_OFF)  syzbot reported a lockdep violation [1] involving af_unix support of SO_PEEK_OFF.  Since SO_PEEK_OFF is inherently not thread safe (it uses a per-socket sk_peek_off field), there is really no point to enforce a pointless thread safety in the kernel.  After this patch :  - setsockopt(SO_PEEK_OFF) no longer acquires the socket lock.  - skb_consume_udp() no longer has to acquire the socket lock.  - af_unix no longer needs a special version of sk_set_peek_off(),   because it does not lock u->iolock anymore.  As a followup, we could replace prot->set_peek_off to be a boolean and avoid an indirect call, since we always use sk_set_peek_off().  [1]  WARNING: possible circular locking dependency detected 6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Not tainted  syz-executor.2/30025 is trying to acquire lock:  ffff8880765e7d80 (&u->iolock){+.+.}-{3:3}, at: unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789  but task is already holding lock:  ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline]  ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline]  ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193  which lock already depends on the new lock.  the existing dependency chain (in reverse order) is:  -> #1 (sk_lock-AF_UNIX){+.+.}-{0:0}:         lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754         lock_sock_nested+0x48/0x100 net/core/sock.c:3524         lock_sock include/net/sock.h:1691 [inline]         __unix_dgram_recvmsg+0x1275/0x12c0 net/unix/af_unix.c:2415         sock_recvmsg_nosec+0x18e/0x1d0 net/socket.c:1046         ____sys_recvmsg+0x3c0/0x470 net/socket.c:2801         ___sys_recvmsg net/socket.c:2845 [inline]         do_recvmmsg+0x474/0xae0 net/socket.c:2939         __sys_recvmmsg net/socket.c:3018 [inline]         __do_sys_recvmmsg net/socket.c:3041 [inline]         __se_sys_recvmmsg net/socket.c:3034 [inline]         __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034        do_syscall_64+0xf9/0x240        entry_SYSCALL_64_after_hwframe+0x6f/0x77  -> #0 (&u->iolock){+.+.}-{3:3}:         check_prev_add kernel/locking/lockdep.c:3134 [inline]         check_prevs_add kernel/locking/lockdep.c:3253 [inline]         validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869         __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137         lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754         __mutex_lock_common kernel/locking/mutex.c:608 [inline]         __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752         unix_set_peek_off+0x26/0xa0 net/unix/af_unix.c:789        sk_setsockopt+0x207e/0x3360         do_sock_setsockopt+0x2fb/0x720 net/socket.c:2307         __sys_setsockopt+0x1ad/0x250 net/socket.c:2334         __do_sys_setsockopt net/socket.c:2343 [inline]         __se_sys_setsockopt net/socket.c:2340 [inline]         __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340        do_syscall_64+0xf9/0x240        entry_SYSCALL_64_after_hwframe+0x6f/0x77  other info that might help us debug this:   Possible unsafe locking scenario:         CPU0                    CPU1        ----                    ----   lock(sk_lock-AF_UNIX);                                lock(&u->iolock);                                lock(sk_lock-AF_UNIX);   lock(&u->iolock);   *** DEADLOCK ***  1 lock held by syz-executor.2/30025:   #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1691 [inline]   #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sockopt_lock_sock net/core/sock.c:1060 [inline]   #0: ffff8880765e7930 (sk_lock-AF_UNIX){+.+.}-{0:0}, at: sk_setsockopt+0xe52/0x3360 net/core/sock.c:1193  stack backtrace: CPU: 0 PID: 30025 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00267-g0f1dd5e91e2b #0 Hardware name: Google Google C ---truncated---

## Where it's fixed

| Platform | Product | Fixed in | Fix | Released |
|---|---|---|---|---|
| Linux | linux Debian 13.5 (trixie) | 6.7.7-1 | [DEBIAN-CVE-2024-26732](https://patchblox.com/security/data/fix/linux/debian-cve-2024-26732.md) | Apr 3, 2024 |
| Linux | linux Debian 14 | 6.7.7-1 | [DEBIAN-CVE-2024-26732](https://patchblox.com/security/data/fix/linux/debian-cve-2024-26732.md) | Apr 3, 2024 |

---

Data as of 2026-11-08T13:06:02Z UTC. Source: Patchblox Patch Radar (https://patchblox.com/security/patch-radar). Patchblox finds out-of-date software on Windows, macOS and Linux and updates it through release rings: https://patchblox.com/demo

Free to use with attribution: show "Data: Patchblox Patch Radar" with a link to https://patchblox.com/security/patch-radar. Terms, including what needs a written agreement: https://patchblox.com/security/patch-radar/use-the-data

Product names, logos and trademarks shown on Patch Radar belong to their respective owners. They are used only to identify the software each security fix applies to and to help readers find their platform. Their use does not imply any affiliation with, or endorsement by, those owners, and Patchblox is not affiliated with any of them.