Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: Fix the use of GFP_KERNEL in atomic context on rt<br /> <br /> The commit 4af1b64f80fb ("octeontx2-pf: Fix lmtst ID used in aura<br /> free") uses the get/put_cpu() to protect the usage of percpu pointer<br /> in -&gt;aura_freeptr() callback, but it also unnecessarily disable the<br /> preemption for the blockable memory allocation. The commit 87b93b678e95<br /> ("octeontx2-pf: Avoid use of GFP_KERNEL in atomic context") tried to<br /> fix these sleep inside atomic warnings. But it only fix the one for<br /> the non-rt kernel. For the rt kernel, we still get the similar warnings<br /> like below.<br /> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0<br /> preempt_count: 1, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> 3 locks held by swapper/0/1:<br /> #0: ffff800009fc5fe8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x24/0x30<br /> #1: ffff000100c276c0 (&amp;mbox-&gt;lock){+.+.}-{3:3}, at: otx2_init_hw_resources+0x8c/0x3a4<br /> #2: ffffffbfef6537e0 (&amp;cpu_rcache-&gt;lock){+.+.}-{2:2}, at: alloc_iova_fast+0x1ac/0x2ac<br /> Preemption disabled at:<br /> [] otx2_rq_aura_pool_init+0x14c/0x284<br /> CPU: 20 PID: 1 Comm: swapper/0 Tainted: G W 6.2.0-rc3-rt1-yocto-preempt-rt #1<br /> Hardware name: Marvell OcteonTX CN96XX board (DT)<br /> Call trace:<br /> dump_backtrace.part.0+0xe8/0xf4<br /> show_stack+0x20/0x30<br /> dump_stack_lvl+0x9c/0xd8<br /> dump_stack+0x18/0x34<br /> __might_resched+0x188/0x224<br /> rt_spin_lock+0x64/0x110<br /> alloc_iova_fast+0x1ac/0x2ac<br /> iommu_dma_alloc_iova+0xd4/0x110<br /> __iommu_dma_map+0x80/0x144<br /> iommu_dma_map_page+0xe8/0x260<br /> dma_map_page_attrs+0xb4/0xc0<br /> __otx2_alloc_rbuf+0x90/0x150<br /> otx2_rq_aura_pool_init+0x1c8/0x284<br /> otx2_init_hw_resources+0xe4/0x3a4<br /> otx2_open+0xf0/0x610<br /> __dev_open+0x104/0x224<br /> __dev_change_flags+0x1e4/0x274<br /> dev_change_flags+0x2c/0x7c<br /> ic_open_devs+0x124/0x2f8<br /> ip_auto_config+0x180/0x42c<br /> do_one_initcall+0x90/0x4dc<br /> do_basic_setup+0x10c/0x14c<br /> kernel_init_freeable+0x10c/0x13c<br /> kernel_init+0x2c/0x140<br /> ret_from_fork+0x10/0x20<br /> <br /> Of course, we can shuffle the get/put_cpu() to only wrap the invocation<br /> of -&gt;aura_freeptr() as what commit 87b93b678e95 does. But there are only<br /> two -&gt;aura_freeptr() callbacks, otx2_aura_freeptr() and<br /> cn10k_aura_freeptr(). There is no usage of perpcu variable in the<br /> otx2_aura_freeptr() at all, so the get/put_cpu() seems redundant to it.<br /> We can move the get/put_cpu() into the corresponding callback which<br /> really has the percpu variable usage and avoid the sprinkling of<br /> get/put_cpu() in several places.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: Avoid use of GFP_KERNEL in atomic context<br /> <br /> Using GFP_KERNEL in preemption disable context, causing below warning<br /> when CONFIG_DEBUG_ATOMIC_SLEEP is enabled.<br /> <br /> [ 32.542271] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274<br /> [ 32.550883] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0<br /> [ 32.558707] preempt_count: 1, expected: 0<br /> [ 32.562710] RCU nest depth: 0, expected: 0<br /> [ 32.566800] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G W 6.2.0-rc2-00269-gae9dcb91c606 #7<br /> [ 32.576188] Hardware name: Marvell CN106XX board (DT)<br /> [ 32.581232] Call trace:<br /> [ 32.583670] dump_backtrace.part.0+0xe0/0xf0<br /> [ 32.587937] show_stack+0x18/0x30<br /> [ 32.591245] dump_stack_lvl+0x68/0x84<br /> [ 32.594900] dump_stack+0x18/0x34<br /> [ 32.598206] __might_resched+0x12c/0x160<br /> [ 32.602122] __might_sleep+0x48/0xa0<br /> [ 32.605689] __kmem_cache_alloc_node+0x2b8/0x2e0<br /> [ 32.610301] __kmalloc+0x58/0x190<br /> [ 32.613610] otx2_sq_aura_pool_init+0x1a8/0x314<br /> [ 32.618134] otx2_open+0x1d4/0x9d0<br /> <br /> To avoid use of GFP_ATOMIC for memory allocation, disable preemption<br /> after all memory allocation is done.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/core: Fix ib block iterator counter overflow<br /> <br /> When registering a new DMA MR after selecting the best aligned page size<br /> for it, we iterate over the given sglist to split each entry to smaller,<br /> aligned to the selected page size, DMA blocks.<br /> <br /> In given circumstances where the sg entry and page size fit certain<br /> sizes and the sg entry is not aligned to the selected page size, the<br /> total size of the aligned pages we need to cover the sg entry is &gt;= 4GB.<br /> Under this circumstances, while iterating page aligned blocks, the<br /> counter responsible for counting how much we advanced from the start of<br /> the sg entry is overflowed because its type is u32 and we pass 4GB in<br /> size. This can lead to an infinite loop inside the iterator function<br /> because the overflow prevents the counter to be larger<br /> than the size of the sg entry.<br /> <br /> Fix the presented problem by changing the advancement condition to<br /> eliminate overflow.<br /> <br /> Backtrace:<br /> [ 192.374329] efa_reg_user_mr_dmabuf<br /> [ 192.376783] efa_register_mr<br /> [ 192.382579] pgsz_bitmap 0xfffff000 rounddown 0x80000000<br /> [ 192.386423] pg_sz [0x80000000] umem_length[0xc0000000]<br /> [ 192.392657] start 0x0 length 0xc0000000 params.page_shift 31 params.page_num 3<br /> [ 192.399559] hp_cnt[3], pages_in_hp[524288]<br /> [ 192.403690] umem-&gt;sgt_append.sgt.nents[1]<br /> [ 192.407905] number entries: [1], pg_bit: [31]<br /> [ 192.411397] biter-&gt;__sg_nents [1] biter-&gt;__sg [0000000008b0c5d8]<br /> [ 192.415601] biter-&gt;__sg_advance [665837568] sg_dma_len[3221225472]<br /> [ 192.419823] biter-&gt;__sg_nents [1] biter-&gt;__sg [0000000008b0c5d8]<br /> [ 192.423976] biter-&gt;__sg_advance [2813321216] sg_dma_len[3221225472]<br /> [ 192.428243] biter-&gt;__sg_nents [1] biter-&gt;__sg [0000000008b0c5d8]<br /> [ 192.432397] biter-&gt;__sg_advance [665837568] sg_dma_len[3221225472]

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "wifi: mac80211: fix memory leak in ieee80211_if_add()"<br /> <br /> This reverts commit 13e5afd3d773c6fc6ca2b89027befaaaa1ea7293.<br /> <br /> ieee80211_if_free() is already called from free_netdev(ndev)<br /> because ndev-&gt;priv_destructor == ieee80211_if_free<br /> <br /> syzbot reported:<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]<br /> CPU: 0 PID: 10041 Comm: syz-executor.0 Not tainted 6.2.0-rc2-syzkaller-00388-g55b98837e37d #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> RIP: 0010:pcpu_get_page_chunk mm/percpu.c:262 [inline]<br /> RIP: 0010:pcpu_chunk_addr_search mm/percpu.c:1619 [inline]<br /> RIP: 0010:free_percpu mm/percpu.c:2271 [inline]<br /> RIP: 0010:free_percpu+0x186/0x10f0 mm/percpu.c:2254<br /> Code: 80 3c 02 00 0f 85 f5 0e 00 00 48 8b 3b 48 01 ef e8 cf b3 0b 00 48 ba 00 00 00 00 00 fc ff df 48 8d 78 20 48 89 f9 48 c1 e9 03 3c 11 00 0f 85 3b 0e 00 00 48 8b 58 20 48 b8 00 00 00 00 00 fc<br /> RSP: 0018:ffffc90004ba7068 EFLAGS: 00010002<br /> RAX: 0000000000000000 RBX: ffff88823ffe2b80 RCX: 0000000000000004<br /> RDX: dffffc0000000000 RSI: ffffffff81c1f4e7 RDI: 0000000000000020<br /> RBP: ffffe8fffe8fc220 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 1ffffffff2179ab2 R12: ffff8880b983d000<br /> R13: 0000000000000003 R14: 0000607f450fc220 R15: ffff88823ffe2988<br /> FS: 00007fcb349de700(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000001b32220000 CR3: 000000004914f000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> netdev_run_todo+0x6bf/0x1100 net/core/dev.c:10352<br /> ieee80211_register_hw+0x2663/0x4040 net/mac80211/main.c:1411<br /> mac80211_hwsim_new_radio+0x2537/0x4d80 drivers/net/wireless/mac80211_hwsim.c:4583<br /> hwsim_new_radio_nl+0xa09/0x10f0 drivers/net/wireless/mac80211_hwsim.c:5176<br /> genl_family_rcv_msg_doit.isra.0+0x1e6/0x2d0 net/netlink/genetlink.c:968<br /> genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]<br /> genl_rcv_msg+0x4ff/0x7e0 net/netlink/genetlink.c:1065<br /> netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2564<br /> genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline]<br /> netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1356<br /> netlink_sendmsg+0x91b/0xe10 net/netlink/af_netlink.c:1932<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg+0xd3/0x120 net/socket.c:734<br /> ____sys_sendmsg+0x712/0x8c0 net/socket.c:2476<br /> ___sys_sendmsg+0x110/0x1b0 net/socket.c:2530<br /> __sys_sendmsg+0xf7/0x1c0 net/socket.c:2559<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mdio: validate parameter addr in mdiobus_get_phy()<br /> <br /> The caller may pass any value as addr, what may result in an out-of-bounds<br /> access to array mdio_map. One existing case is stmmac_init_phy() that<br /> may pass -1 as addr. Therefore validate addr before using it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: fix memory leak in hci_update_adv_data()<br /> <br /> When hci_cmd_sync_queue() failed in hci_update_adv_data(), inst_ptr is<br /> not freed, which will cause memory leak, convert to use ERR_PTR/PTR_ERR<br /> to pass the instance to callback so no memory needs to be allocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_conn: Fix memory leaks<br /> <br /> When hci_cmd_sync_queue() failed in hci_le_terminate_big() or<br /> hci_le_big_terminate(), the memory pointed by variable d is not freed,<br /> which will cause memory leak. Add release process to error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: close all race conditions in l2tp_tunnel_register()<br /> <br /> The code in l2tp_tunnel_register() is racy in several ways:<br /> <br /> 1. It modifies the tunnel socket _after_ publishing it.<br /> <br /> 2. It calls setup_udp_tunnel_sock() on an existing socket without<br /> locking.<br /> <br /> 3. It changes sock lock class on fly, which triggers many syzbot<br /> reports.<br /> <br /> This patch amends all of them by moving socket initialization code<br /> before publishing and under sock lock. As suggested by Jakub, the<br /> l2tp lockdep class is not necessary as we can just switch to<br /> bh_lock_sock_nested().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: enetc: avoid deadlock in enetc_tx_onestep_tstamp()<br /> <br /> This lockdep splat says it better than I could:<br /> <br /> ================================<br /> WARNING: inconsistent lock state<br /> 6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted<br /> --------------------------------<br /> inconsistent {IN-SOFTIRQ-W} -&gt; {SOFTIRQ-ON-W} usage.<br /> kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes:<br /> ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0<br /> {IN-SOFTIRQ-W} state was registered at:<br /> _raw_spin_lock+0x5c/0xc0<br /> sch_direct_xmit+0x148/0x37c<br /> __dev_queue_xmit+0x528/0x111c<br /> ip6_finish_output2+0x5ec/0xb7c<br /> ip6_finish_output+0x240/0x3f0<br /> ip6_output+0x78/0x360<br /> ndisc_send_skb+0x33c/0x85c<br /> ndisc_send_rs+0x54/0x12c<br /> addrconf_rs_timer+0x154/0x260<br /> call_timer_fn+0xb8/0x3a0<br /> __run_timers.part.0+0x214/0x26c<br /> run_timer_softirq+0x3c/0x74<br /> __do_softirq+0x14c/0x5d8<br /> ____do_softirq+0x10/0x20<br /> call_on_irq_stack+0x2c/0x5c<br /> do_softirq_own_stack+0x1c/0x30<br /> __irq_exit_rcu+0x168/0x1a0<br /> irq_exit_rcu+0x10/0x40<br /> el1_interrupt+0x38/0x64<br /> irq event stamp: 7825<br /> hardirqs last enabled at (7825): [] exit_to_kernel_mode+0x34/0x130<br /> hardirqs last disabled at (7823): [] __do_softirq+0x550/0x5d8<br /> softirqs last enabled at (7824): [] __do_softirq+0x46c/0x5d8<br /> softirqs last disabled at (7811): [] ____do_softirq+0x10/0x20<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(_xmit_ETHER#2);<br /> <br /> lock(_xmit_ETHER#2);<br /> <br /> *** DEADLOCK ***<br /> <br /> 3 locks held by kworker/1:3/179:<br /> #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0<br /> #1: ffff80000a0bbdc8 ((work_completion)(&amp;priv-&gt;tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0<br /> #2: ffff3ec4036cd438 (&amp;dev-&gt;tx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34<br /> <br /> Workqueue: events enetc_tx_onestep_tstamp<br /> Call trace:<br /> print_usage_bug.part.0+0x208/0x22c<br /> mark_lock+0x7f0/0x8b0<br /> __lock_acquire+0x7c4/0x1ce0<br /> lock_acquire.part.0+0xe0/0x220<br /> lock_acquire+0x68/0x84<br /> _raw_spin_lock+0x5c/0xc0<br /> netif_freeze_queues+0x5c/0xc0<br /> netif_tx_lock+0x24/0x34<br /> enetc_tx_onestep_tstamp+0x20/0x100<br /> process_one_work+0x28c/0x6c0<br /> worker_thread+0x74/0x450<br /> kthread+0x118/0x11c<br /> <br /> but I&amp;#39;ll say it anyway: the enetc_tx_onestep_tstamp() work item runs in<br /> process context, therefore with softirqs enabled (i.o.w., it can be<br /> interrupted by a softirq). If we hold the netif_tx_lock() when there is<br /> an interrupt, and the NET_TX softirq then gets scheduled, this will take<br /> the netif_tx_lock() a second time and deadlock the kernel.<br /> <br /> To solve this, use netif_tx_lock_bh(), which blocks softirqs from<br /> running.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_taprio: fix possible use-after-free<br /> <br /> syzbot reported a nasty crash [1] in net_tx_action() which<br /> made little sense until we got a repro.<br /> <br /> This repro installs a taprio qdisc, but providing an<br /> invalid TCA_RATE attribute.<br /> <br /> qdisc_create() has to destroy the just initialized<br /> taprio qdisc, and taprio_destroy() is called.<br /> <br /> However, the hrtimer used by taprio had already fired,<br /> therefore advance_sched() called __netif_schedule().<br /> <br /> Then net_tx_action was trying to use a destroyed qdisc.<br /> <br /> We can not undo the __netif_schedule(), so we must wait<br /> until one cpu serviced the qdisc before we can proceed.<br /> <br /> Many thanks to Alexander Potapenko for his help.<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline]<br /> BUG: KMSAN: uninit-value in do_raw_spin_trylock include/linux/spinlock.h:191 [inline]<br /> BUG: KMSAN: uninit-value in __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline]<br /> BUG: KMSAN: uninit-value in _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138<br /> queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline]<br /> do_raw_spin_trylock include/linux/spinlock.h:191 [inline]<br /> __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline]<br /> _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138<br /> spin_trylock include/linux/spinlock.h:359 [inline]<br /> qdisc_run_begin include/net/sch_generic.h:187 [inline]<br /> qdisc_run+0xee/0x540 include/net/pkt_sched.h:125<br /> net_tx_action+0x77c/0x9a0 net/core/dev.c:5086<br /> __do_softirq+0x1cc/0x7fb kernel/softirq.c:571<br /> run_ksoftirqd+0x2c/0x50 kernel/softirq.c:934<br /> smpboot_thread_fn+0x554/0x9f0 kernel/smpboot.c:164<br /> kthread+0x31b/0x430 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slab.h:732 [inline]<br /> slab_alloc_node mm/slub.c:3258 [inline]<br /> __kmalloc_node_track_caller+0x814/0x1250 mm/slub.c:4970<br /> kmalloc_reserve net/core/skbuff.c:358 [inline]<br /> __alloc_skb+0x346/0xcf0 net/core/skbuff.c:430<br /> alloc_skb include/linux/skbuff.h:1257 [inline]<br /> nlmsg_new include/net/netlink.h:953 [inline]<br /> netlink_ack+0x5f3/0x12b0 net/netlink/af_netlink.c:2436<br /> netlink_rcv_skb+0x55d/0x6c0 net/netlink/af_netlink.c:2507<br /> rtnetlink_rcv+0x30/0x40 net/core/rtnetlink.c:6108<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]<br /> netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345<br /> netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> ____sys_sendmsg+0xabc/0xe90 net/socket.c:2482<br /> ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2536<br /> __sys_sendmsg net/socket.c:2565 [inline]<br /> __do_sys_sendmsg net/socket.c:2574 [inline]<br /> __se_sys_sendmsg net/socket.c:2572 [inline]<br /> __x64_sys_sendmsg+0x367/0x540 net/socket.c:2572<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 6.0.0-rc2-syzkaller-47461-gac3859c02d7f #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022