Deadlock Affecting bpftool package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CENTOS7-BPFTOOL-7080454
- published23 May 2024
- disclosed21 May 2024
Introduced: 21 May 2024
CVE-2023-52813 (opens in a new tab)How to fix?
There is no fixed version for Centos:7 bpftool.
NVD Description
Note: Versions mentioned in the description apply only to the upstream bpftool package and not the bpftool package as distributed by Centos.
See How to fix? for Centos:7 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
crypto: pcrypt - Fix hungtask for PADATA_RESET
We found a hungtask bug in test_aead_vec_cfg as follows:
INFO: task cryptomgr_test:391009 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Call trace: __switch_to+0x98/0xe0 __schedule+0x6c4/0xf40 schedule+0xd8/0x1b4 schedule_timeout+0x474/0x560 wait_for_common+0x368/0x4e0 wait_for_completion+0x20/0x30 wait_for_completion+0x20/0x30 test_aead_vec_cfg+0xab4/0xd50 test_aead+0x144/0x1f0 alg_test_aead+0xd8/0x1e0 alg_test+0x634/0x890 cryptomgr_test+0x40/0x70 kthread+0x1e0/0x220 ret_from_fork+0x10/0x18 Kernel panic - not syncing: hung_task: blocked tasks
For padata_do_parallel, when the return err is 0 or -EBUSY, it will call wait_for_completion(&wait->completion) in test_aead_vec_cfg. In normal case, aead_request_complete() will be called in pcrypt_aead_serial and the return err is 0 for padata_do_parallel. But, when pinst->flags is PADATA_RESET, the return err is -EBUSY for padata_do_parallel, and it won't call aead_request_complete(). Therefore, test_aead_vec_cfg will hung at wait_for_completion(&wait->completion), which will cause hungtask.
The problem comes as following: (padata_do_parallel) | rcu_read_lock_bh(); | err = -EINVAL; | (padata_replace) | pinst->flags |= PADATA_RESET; err = -EBUSY | if (pinst->flags & PADATA_RESET) | rcu_read_unlock_bh() | return err
In order to resolve the problem, we replace the return err -EBUSY with -EAGAIN, which means parallel_data is changing, and the caller should call it again.
v3: remove retry and just change the return err. v2: introduce padata_try_do_parallel() in pcrypt_aead_encrypt and pcrypt_aead_decrypt to solve the hungtask.
References
- https://access.redhat.com/security/cve/CVE-2023-52813
- https://git.kernel.org/stable/c/039fec48e062504f14845124a1a25eb199b2ddc0
- https://git.kernel.org/stable/c/372636debe852913529b1716f44addd94fff2d28
- https://git.kernel.org/stable/c/546c1796ad1ed0d87dab3c4b5156d75819be2316
- https://git.kernel.org/stable/c/8f4f68e788c3a7a696546291258bfa5fdb215523
- https://git.kernel.org/stable/c/c55fc098fd9d2dca475b82d00ffbcaf97879d77e
- https://git.kernel.org/stable/c/c9c1334697301c10e6918d747ed38abfbc0c96e7
- https://git.kernel.org/stable/c/e134f3aba98e6c801a693f540912c2d493718ddf
- https://git.kernel.org/stable/c/e97bf4ada7dddacd184c3e196bd063b0dc71b41d
- https://git.kernel.org/stable/c/fb2d3a50a8f29a3c66682bb426144f40e32ab818