ghsa-xpq9-hr2h-w5cj
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: Fix the use of GFP_KERNEL in atomic context on rt
The commit 4af1b64f80fb ("octeontx2-pf: Fix lmtst ID used in aura free") uses the get/put_cpu() to protect the usage of percpu pointer in ->aura_freeptr() callback, but it also unnecessarily disable the preemption for the blockable memory allocation. The commit 87b93b678e95 ("octeontx2-pf: Avoid use of GFP_KERNEL in atomic context") tried to fix these sleep inside atomic warnings. But it only fix the one for the non-rt kernel. For the rt kernel, we still get the similar warnings like below. BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by swapper/0/1: #0: ffff800009fc5fe8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x24/0x30 #1: ffff000100c276c0 (&mbox->lock){+.+.}-{3:3}, at: otx2_init_hw_resources+0x8c/0x3a4 #2: ffffffbfef6537e0 (&cpu_rcache->lock){+.+.}-{2:2}, at: alloc_iova_fast+0x1ac/0x2ac Preemption disabled at: [] otx2_rq_aura_pool_init+0x14c/0x284 CPU: 20 PID: 1 Comm: swapper/0 Tainted: G W 6.2.0-rc3-rt1-yocto-preempt-rt #1 Hardware name: Marvell OcteonTX CN96XX board (DT) Call trace: dump_backtrace.part.0+0xe8/0xf4 show_stack+0x20/0x30 dump_stack_lvl+0x9c/0xd8 dump_stack+0x18/0x34 __might_resched+0x188/0x224 rt_spin_lock+0x64/0x110 alloc_iova_fast+0x1ac/0x2ac iommu_dma_alloc_iova+0xd4/0x110 __iommu_dma_map+0x80/0x144 iommu_dma_map_page+0xe8/0x260 dma_map_page_attrs+0xb4/0xc0 __otx2_alloc_rbuf+0x90/0x150 otx2_rq_aura_pool_init+0x1c8/0x284 otx2_init_hw_resources+0xe4/0x3a4 otx2_open+0xf0/0x610 __dev_open+0x104/0x224 __dev_change_flags+0x1e4/0x274 dev_change_flags+0x2c/0x7c ic_open_devs+0x124/0x2f8 ip_auto_config+0x180/0x42c do_one_initcall+0x90/0x4dc do_basic_setup+0x10c/0x14c kernel_init_freeable+0x10c/0x13c kernel_init+0x2c/0x140 ret_from_fork+0x10/0x20
Of course, we can shuffle the get/put_cpu() to only wrap the invocation of ->aura_freeptr() as what commit 87b93b678e95 does. But there are only two ->aura_freeptr() callbacks, otx2_aura_freeptr() and cn10k_aura_freeptr(). There is no usage of perpcu variable in the otx2_aura_freeptr() at all, so the get/put_cpu() seems redundant to it. We can move the get/put_cpu() into the corresponding callback which really has the percpu variable usage and avoid the sprinkling of get/put_cpu() in several places.
{
"affected": [],
"aliases": [
"CVE-2023-53029"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-27T17:15:52Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: Fix the use of GFP_KERNEL in atomic context on rt\n\nThe commit 4af1b64f80fb (\"octeontx2-pf: Fix lmtst ID used in aura\nfree\") uses the get/put_cpu() to protect the usage of percpu pointer\nin -\u003eaura_freeptr() callback, but it also unnecessarily disable the\npreemption for the blockable memory allocation. The commit 87b93b678e95\n(\"octeontx2-pf: Avoid use of GFP_KERNEL in atomic context\") tried to\nfix these sleep inside atomic warnings. But it only fix the one for\nthe non-rt kernel. For the rt kernel, we still get the similar warnings\nlike below.\n BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46\n in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0\n preempt_count: 1, expected: 0\n RCU nest depth: 0, expected: 0\n 3 locks held by swapper/0/1:\n #0: ffff800009fc5fe8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x24/0x30\n #1: ffff000100c276c0 (\u0026mbox-\u003elock){+.+.}-{3:3}, at: otx2_init_hw_resources+0x8c/0x3a4\n #2: ffffffbfef6537e0 (\u0026cpu_rcache-\u003elock){+.+.}-{2:2}, at: alloc_iova_fast+0x1ac/0x2ac\n Preemption disabled at:\n [\u003cffff800008b1908c\u003e] otx2_rq_aura_pool_init+0x14c/0x284\n CPU: 20 PID: 1 Comm: swapper/0 Tainted: G W 6.2.0-rc3-rt1-yocto-preempt-rt #1\n Hardware name: Marvell OcteonTX CN96XX board (DT)\n Call trace:\n dump_backtrace.part.0+0xe8/0xf4\n show_stack+0x20/0x30\n dump_stack_lvl+0x9c/0xd8\n dump_stack+0x18/0x34\n __might_resched+0x188/0x224\n rt_spin_lock+0x64/0x110\n alloc_iova_fast+0x1ac/0x2ac\n iommu_dma_alloc_iova+0xd4/0x110\n __iommu_dma_map+0x80/0x144\n iommu_dma_map_page+0xe8/0x260\n dma_map_page_attrs+0xb4/0xc0\n __otx2_alloc_rbuf+0x90/0x150\n otx2_rq_aura_pool_init+0x1c8/0x284\n otx2_init_hw_resources+0xe4/0x3a4\n otx2_open+0xf0/0x610\n __dev_open+0x104/0x224\n __dev_change_flags+0x1e4/0x274\n dev_change_flags+0x2c/0x7c\n ic_open_devs+0x124/0x2f8\n ip_auto_config+0x180/0x42c\n do_one_initcall+0x90/0x4dc\n do_basic_setup+0x10c/0x14c\n kernel_init_freeable+0x10c/0x13c\n kernel_init+0x2c/0x140\n ret_from_fork+0x10/0x20\n\nOf course, we can shuffle the get/put_cpu() to only wrap the invocation\nof -\u003eaura_freeptr() as what commit 87b93b678e95 does. But there are only\ntwo -\u003eaura_freeptr() callbacks, otx2_aura_freeptr() and\ncn10k_aura_freeptr(). There is no usage of perpcu variable in the\notx2_aura_freeptr() at all, so the get/put_cpu() seems redundant to it.\nWe can move the get/put_cpu() into the corresponding callback which\nreally has the percpu variable usage and avoid the sprinkling of\nget/put_cpu() in several places.",
"id": "GHSA-xpq9-hr2h-w5cj",
"modified": "2025-03-27T18:31:29Z",
"published": "2025-03-27T18:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53029"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/29e9c67bf3271067735c188e95cf3631ecd64d58"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/55ba18dc62deff5910c0fa64486dea1ff20832ff"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/659518e013d6bd562bb0f1d2d9f99d0ac54720e2"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.