CVE-2022-49732
published 2025-02-26CVE-2022-49732: In the Linux kernel, the following vulnerability has been resolved: sock: redo the psock vs ULP protection check Commit 8a59f9d1e3d4 ("sock: Introduce…
PriorityP419medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.20%
10.3th percentile
In the Linux kernel, the following vulnerability has been resolved:
sock: redo the psock vs ULP protection check
Commit 8a59f9d1e3d4 ("sock: Introduce sk->sk_prot->psock_update_sk_prot()")
has moved the inet_csk_has_ulp(sk) check from sk_psock_init() to
the new tcp_bpf_update_proto() function. I'm guessing that this
was done to allow creating psocks for non-inet sockets.
Unfortunately the destruction path for psock includes the ULP
unwind, so we need to fail the sk_psock_init() itself.
Otherwise if ULP is already present we'll notice that later,
and call tcp_update_ulp() with the sk_proto of the ULP
itself, which will most likely result in the ULP looping
its callbacks.
Affected
11 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.18.14-1 (bookworm) | linux 5.18.14-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 8a59f9d1e3d4340659fdfee8879dc09a6f2546e1 < 72fa0f65b56605b8a9ae9fba2082f2123f7fe017 | 72fa0f65b56605b8a9ae9fba2082f2123f7fe017 |
| linux | linux | >= 8a59f9d1e3d4340659fdfee8879dc09a6f2546e1 < 922309e50befb0cfa5cb65e4989b7706d6578846 | 922309e50befb0cfa5cb65e4989b7706d6578846 |
| linux | linux | >= 8a59f9d1e3d4340659fdfee8879dc09a6f2546e1 < e34a07c0ae3906f97eb18df50902e2a01c1015b6 | e34a07c0ae3906f97eb18df50902e2a01c1015b6 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.18.14-1 | 5.18.14-1 |
| linux | linux_kernel | >= 0 < 5.18.14-1 | 5.18.14-1 |
| linux | linux_kernel | >= 0 < 5.18.14-1 | 5.18.14-1 |
| linux | linux_kernel | >= 5.13 < 5.15.51 | 5.15.51 |
| linux | linux_kernel | >= 5.16 < 5.18.8 | 5.18.8 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
GHSA-rvx3-cxvh-j465: In the Linux kernel, the following vulnerability has been resolved:
sock: redo the psock vs ULP protection check
Commit 8a59f9d1e3d4 ("sock: Introdu
ghsa_unreviewed·2025-10-24
CVE-2022-49732 [MEDIUM] GHSA-rvx3-cxvh-j465: In the Linux kernel, the following vulnerability has been resolved:
sock: redo the psock vs ULP protection check
Commit 8a59f9d1e3d4 ("sock: Introdu
In the Linux kernel, the following vulnerability has been resolved:
sock: redo the psock vs ULP protection check
Commit 8a59f9d1e3d4 ("sock: Introduce sk->sk_prot->psock_update_sk_prot()")
has moved the inet_csk_has_ulp(sk) check from sk_psock_init() to
the new tcp_bpf_update_proto() function. I'm guessing that this
was done to allow creating psocks for non-inet sockets.
Unfortunately the destruction path for psock includes the ULP
unwind, so we need to fail the sk_psock_init() itself.
Otherwise if ULP is already present we'll notice that later,
and call tcp_update_ulp() with the sk_proto of the ULP
itself, which will most likely result in the ULP looping
its callbacks.
OSV
CVE-2022-49732: In the Linux kernel, the following vulnerability has been resolved: sock: redo the psock vs ULP protection check Commit 8a59f9d1e3d4 ("sock: Introduce
osv·2025-02-26·CVSS 5.5
CVE-2022-49732 [MEDIUM] CVE-2022-49732: In the Linux kernel, the following vulnerability has been resolved: sock: redo the psock vs ULP protection check Commit 8a59f9d1e3d4 ("sock: Introduce
In the Linux kernel, the following vulnerability has been resolved: sock: redo the psock vs ULP protection check Commit 8a59f9d1e3d4 ("sock: Introduce sk->sk_prot->psock_update_sk_prot()") has moved the inet_csk_has_ulp(sk) check from sk_psock_init() to the new tcp_bpf_update_proto() function. I'm guessing that this was done to allow creating psocks for non-inet sockets. Unfortunately the destruction path for psock includes the ULP unwind, so we need to fail the sk_psock_init() itself. Otherwise if ULP is already present we'll notice that later, and call tcp_update_ulp() with the sk_proto of the ULP itself, which will most likely result in the ULP looping its callbacks.
Red Hat
kernel: sock: redo the psock vs ULP protection check
vendor_redhat·2025-02-26·CVSS 5.5
CVE-2022-49732 [MEDIUM] kernel: sock: redo the psock vs ULP protection check
kernel: sock: redo the psock vs ULP protection check
In the Linux kernel, the following vulnerability has been resolved:
sock: redo the psock vs ULP protection check
Commit 8a59f9d1e3d4 ("sock: Introduce sk->sk_prot->psock_update_sk_prot()")
has moved the inet_csk_has_ulp(sk) check from sk_psock_init() to
the new tcp_bpf_update_proto() function. I'm guessing that this
was done to allow creating psocks for non-inet sockets.
Unfortunately the destruction path for psock includes the ULP
unwind, so we need to fail the sk_psock_init() itself.
Otherwise if ULP is already present we'll notice that later,
and call tcp_update_ulp() with the sk_proto of the ULP
itself, which will most likely result in the ULP looping
its callbacks.
Package: kernel (Red Hat Enterprise Linux 10) - Not affected
Pack
Debian
CVE-2022-49732: linux - In the Linux kernel, the following vulnerability has been resolved: sock: redo ...
vendor_debian·2022·CVSS 5.5
CVE-2022-49732 [MEDIUM] CVE-2022-49732: linux - In the Linux kernel, the following vulnerability has been resolved: sock: redo ...
In the Linux kernel, the following vulnerability has been resolved: sock: redo the psock vs ULP protection check Commit 8a59f9d1e3d4 ("sock: Introduce sk->sk_prot->psock_update_sk_prot()") has moved the inet_csk_has_ulp(sk) check from sk_psock_init() to the new tcp_bpf_update_proto() function. I'm guessing that this was done to allow creating psocks for non-inet sockets. Unfortunately the destruction path for psock includes the ULP unwind, so we need to fail the sk_psock_init() itself. Otherwise if ULP is already present we'll notice that later, and call tcp_update_ulp() with the sk_proto of the ULP itself, which will most likely result in the ULP looping its callbacks.
Scope: local
bookworm: resolved (fixed in 5.18.14-1)
bullseye: resolved
forky: resolved (fixed in 5.18.14-1)
sid: resolve
No detection rules found.
No public exploits indexed.
2025-02-26
Published