{"uuid": "6a08924a-9b12-434c-99ad-b689f2f3a54f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2023-53029", "type": "seen", "source": "https://t.me/cvedetector/21329", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2023-53029 - Marvell OcteonTX CN96XX Linux Kernel Octeontx2-pf Ratchet Sleep Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2023-53029 \nPublished : March 27, 2025, 5:15 p.m. | 27\u00a0minutes ago \nDescription : 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 ->aura_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 (&mbox->lock){+.+.}-{3:3}, at: otx2_init_hw_resources+0x8c/0x3a4  \n   #2: ffffffbfef6537e0 (&cpu_rcache->lock){+.+.}-{2:2}, at: alloc_iova_fast+0x1ac/0x2ac  \n  Preemption disabled at:  \n  [] 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 ->aura_freeptr() as what commit 87b93b678e95 does. But there are only  \ntwo ->aura_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. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"27 Mar 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-03-27T19:10:05.000000Z"}