CVE-2024-26732

See a problem?
Source
https://nvd.nist.gov/vuln/detail/CVE-2024-26732
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-26732.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2024-26732
Related
Published
2024-04-03T17:15:50Z
Modified
2024-09-18T03:26:02.436222Z
Summary
[none]
Details

In the Linux kernel, the following vulnerability has been resolved:

net: implement lockless setsockopt(SOPEEKOFF)

syzbot reported a lockdep violation [1] involving afunix support of SOPEEK_OFF.

Since SOPEEKOFF is inherently not thread safe (it uses a per-socket skpeekoff field), there is really no point to enforce a pointless thread safety in the kernel.

After this patch :

  • setsockopt(SOPEEKOFF) no longer acquires the socket lock.

  • skbconsumeudp() no longer has to acquire the socket lock.

  • afunix no longer needs a special version of sksetpeekoff(), because it does not lock u->iolock anymore.

As a followup, we could replace prot->setpeekoff to be a boolean and avoid an indirect call, since we always use sksetpeek_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: unixsetpeekoff+0x26/0xa0 net/unix/afunix.c:789

but task is already holding lock: ffff8880765e7930 (sklock-AFUNIX){+.+.}-{0:0}, at: locksock include/net/sock.h:1691 [inline] ffff8880765e7930 (sklock-AFUNIX){+.+.}-{0:0}, at: sockoptlocksock net/core/sock.c:1060 [inline] ffff8880765e7930 (sklock-AFUNIX){+.+.}-{0:0}, at: sksetsockopt+0xe52/0x3360 net/core/sock.c:1193

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (sklock-AFUNIX){+.+.}-{0:0}: lockacquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 locksocknested+0x48/0x100 net/core/sock.c:3524 locksock include/net/sock.h:1691 [inline] unixdgramrecvmsg+0x1275/0x12c0 net/unix/afunix.c:2415 sockrecvmsgnosec+0x18e/0x1d0 net/socket.c:1046 _sysrecvmsg+0x3c0/0x470 net/socket.c:2801 _sysrecvmsg net/socket.c:2845 [inline] dorecvmmsg+0x474/0xae0 net/socket.c:2939 _sysrecvmmsg net/socket.c:3018 [inline] _dosysrecvmmsg net/socket.c:3041 [inline] _sesysrecvmmsg net/socket.c:3034 [inline] _x64sysrecvmmsg+0x199/0x250 net/socket.c:3034 dosyscall64+0xf9/0x240 entrySYSCALL64afterhwframe+0x6f/0x77

-> #0 (&u->iolock){+.+.}-{3:3}: checkprevadd kernel/locking/lockdep.c:3134 [inline] checkprevsadd kernel/locking/lockdep.c:3253 [inline] validatechain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869 _lockacquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lockacquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 _mutexlockcommon kernel/locking/mutex.c:608 [inline] _mutexlock+0x136/0xd70 kernel/locking/mutex.c:752 unixsetpeekoff+0x26/0xa0 net/unix/afunix.c:789 sksetsockopt+0x207e/0x3360 dosocksetsockopt+0x2fb/0x720 net/socket.c:2307 _syssetsockopt+0x1ad/0x250 net/socket.c:2334 _dosyssetsockopt net/socket.c:2343 [inline] _sesyssetsockopt net/socket.c:2340 [inline] _x64syssetsockopt+0xb5/0xd0 net/socket.c:2340 dosyscall64+0xf9/0x240 entrySYSCALL64after_hwframe+0x6f/0x77

other info that might help us debug this:

Possible unsafe locking scenario:

   CPU0                    CPU1
   ----                    ----

lock(sklock-AFUNIX); lock(&u->iolock); lock(sklock-AFUNIX); lock(&u->iolock);

* DEADLOCK *

1 lock held by syz-executor.2/30025: #0: ffff8880765e7930 (sklock-AFUNIX){+.+.}-{0:0}, at: locksock include/net/sock.h:1691 [inline] #0: ffff8880765e7930 (sklock-AFUNIX){+.+.}-{0:0}, at: sockoptlocksock net/core/sock.c:1060 [inline] #0: ffff8880765e7930 (sklock-AFUNIX){+.+.}-{0:0}, at: sksetsockopt+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---

References

Affected packages

Debian:13 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.7.7-1

Affected versions

6.*

6.1.27-1
6.1.37-1
6.1.38-1
6.1.38-2~bpo11+1
6.1.38-2
6.1.38-3
6.1.38-4~bpo11+1
6.1.38-4
6.1.52-1
6.1.55-1~bpo11+1
6.1.55-1
6.1.64-1
6.1.66-1
6.1.67-1
6.1.69-1~bpo11+1
6.1.69-1
6.1.76-1~bpo11+1
6.1.76-1
6.1.82-1
6.1.85-1
6.1.90-1~bpo11+1
6.1.90-1
6.1.94-1~bpo11+1
6.1.94-1
6.1.98-1
6.1.99-1
6.1.106-1
6.1.106-2
6.1.106-3
6.3.1-1~exp1
6.3.2-1~exp1
6.3.4-1~exp1
6.3.5-1~exp1
6.3.7-1~bpo12+1
6.3.7-1
6.3.11-1
6.4~rc6-1~exp1
6.4~rc7-1~exp1
6.4.1-1~exp1
6.4.4-1~bpo12+1
6.4.4-1
6.4.4-2
6.4.4-3~bpo12+1
6.4.4-3
6.4.11-1
6.4.13-1
6.5~rc4-1~exp1
6.5~rc6-1~exp1
6.5~rc7-1~exp1
6.5.1-1~exp1
6.5.3-1~bpo12+1
6.5.3-1
6.5.6-1
6.5.8-1
6.5.10-1~bpo12+1
6.5.10-1
6.5.13-1
6.6.3-1~exp1
6.6.4-1~exp1
6.6.7-1~exp1
6.6.8-1
6.6.9-1
6.6.11-1
6.6.13-1~bpo12+1
6.6.13-1
6.6.15-1
6.6.15-2
6.7-1~exp1
6.7.1-1~exp1
6.7.4-1~exp1

Ecosystem specific

{
    "urgency": "not yet assigned"
}