Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: Protect reconfiguration of sb read-write from racing writes<br /> <br /> The reconfigure / remount code takes a lot of effort to protect<br /> filesystem&amp;#39;s reconfiguration code from racing writes on remounting<br /> read-only. However during remounting read-only filesystem to read-write<br /> mode userspace writes can start immediately once we clear SB_RDONLY<br /> flag. This is inconvenient for example for ext4 because we need to do<br /> some writes to the filesystem (such as preparation of quota files)<br /> before we can take userspace writes so we are clearing SB_RDONLY flag<br /> before we are fully ready to accept userpace writes and syzbot has found<br /> a way to exploit this [1]. Also as far as I&amp;#39;m reading the code<br /> the filesystem remount code was protected from racing writes in the<br /> legacy mount path by the mount&amp;#39;s MNT_READONLY flag so this is relatively<br /> new problem. It is actually fairly easy to protect remount read-write<br /> from racing writes using sb-&gt;s_readonly_remount flag so let&amp;#39;s just do<br /> that instead of having to workaround these races in the filesystem code.<br /> <br /> [1] https://lore.kernel.org/all/00000000000006a0df05f6667499@google.com/T/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qedi: Fix use after free bug in qedi_remove()<br /> <br /> In qedi_probe() we call __qedi_probe() which initializes<br /> &amp;qedi-&gt;recovery_work with qedi_recovery_handler() and<br /> &amp;qedi-&gt;board_disable_work with qedi_board_disable_work().<br /> <br /> When qedi_schedule_recovery_handler() is called, schedule_delayed_work()<br /> will finally start the work.<br /> <br /> In qedi_remove(), which is called to remove the driver, the following<br /> sequence may be observed:<br /> <br /> Fix this by finishing the work before cleanup in qedi_remove().<br /> <br /> CPU0 CPU1<br /> <br /> |qedi_recovery_handler<br /> qedi_remove |<br /> __qedi_remove |<br /> iscsi_host_free |<br /> scsi_host_put |<br /> //free shost |<br /> |iscsi_host_for_each_session<br /> |//use qedi-&gt;shost<br /> <br /> Cancel recovery_work and board_disable_work in __qedi_remove().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver: soc: xilinx: use _safe loop iterator to avoid a use after free<br /> <br /> The hash_for_each_possible() loop dereferences "eve_data" to get the<br /> next item on the list. However the loop frees eve_data so it leads to<br /> a use after free. Use hash_for_each_possible_safe() instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Fix null-ptr-deref in unix_stream_sendpage().<br /> <br /> Bing-Jhong Billy Jheng reported null-ptr-deref in unix_stream_sendpage()<br /> with detailed analysis and a nice repro.<br /> <br /> unix_stream_sendpage() tries to add data to the last skb in the peer&amp;#39;s<br /> recv queue without locking the queue.<br /> <br /> If the peer&amp;#39;s FD is passed to another socket and the socket&amp;#39;s FD is<br /> passed to the peer, there is a loop between them. If we close both<br /> sockets without receiving FD, the sockets will be cleaned up by garbage<br /> collection.<br /> <br /> The garbage collection iterates such sockets and unlinks skb with<br /> FD from the socket&amp;#39;s receive queue under the queue&amp;#39;s lock.<br /> <br /> So, there is a race where unix_stream_sendpage() could access an skb<br /> locklessly that is being released by garbage collection, resulting in<br /> use-after-free.<br /> <br /> To avoid the issue, unix_stream_sendpage() must lock the peer&amp;#39;s recv<br /> queue.<br /> <br /> Note the issue does not exist in 6.5+ thanks to the recent sendpage()<br /> refactoring.<br /> <br /> This patch is originally written by Linus Torvalds.<br /> <br /> BUG: unable to handle page fault for address: ffff988004dd6870<br /> PF: supervisor read access in kernel mode<br /> PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> PREEMPT SMP PTI<br /> CPU: 4 PID: 297 Comm: garbage_uaf Not tainted 6.1.46 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:kmem_cache_alloc_node+0xa2/0x1e0<br /> Code: c0 0f 84 32 01 00 00 41 83 fd ff 74 10 48 8b 00 48 c1 e8 3a 41 39 c5 0f 85 1c 01 00 00 41 8b 44 24 28 49 8b 3c 24 48 8d 4a 40 8b 1c 06 4c 89 f0 65 48 0f c7 0f 0f 94 c0 84 c0 74 a1 41 8b 44<br /> RSP: 0018:ffffc9000079fac0 EFLAGS: 00000246<br /> RAX: 0000000000000070 RBX: 0000000000000005 RCX: 000000000001a284<br /> RDX: 000000000001a244 RSI: 0000000000400cc0 RDI: 000000000002eee0<br /> RBP: 0000000000400cc0 R08: 0000000000400cc0 R09: 0000000000000003<br /> R10: 0000000000000001 R11: 0000000000000000 R12: ffff888003970f00<br /> R13: 00000000ffffffff R14: ffff988004dd6800 R15: 00000000000000e8<br /> FS: 00007f174d6f3600(0000) GS:ffff88807db00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffff988004dd6870 CR3: 00000000092be000 CR4: 00000000007506e0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x1a/0x1f<br /> ? page_fault_oops+0xa9/0x1e0<br /> ? fixup_exception+0x1d/0x310<br /> ? exc_page_fault+0xa8/0x150<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? kmem_cache_alloc_node+0xa2/0x1e0<br /> ? __alloc_skb+0x16c/0x1e0<br /> __alloc_skb+0x16c/0x1e0<br /> alloc_skb_with_frags+0x48/0x1e0<br /> sock_alloc_send_pskb+0x234/0x270<br /> unix_stream_sendmsg+0x1f5/0x690<br /> sock_sendmsg+0x5d/0x60<br /> ____sys_sendmsg+0x210/0x260<br /> ___sys_sendmsg+0x83/0xd0<br /> ? kmem_cache_alloc+0xc6/0x1c0<br /> ? avc_disable+0x20/0x20<br /> ? percpu_counter_add_batch+0x53/0xc0<br /> ? alloc_empty_file+0x5d/0xb0<br /> ? alloc_file+0x91/0x170<br /> ? alloc_file_pseudo+0x94/0x100<br /> ? __fget_light+0x9f/0x120<br /> __sys_sendmsg+0x54/0xa0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x69/0xd3<br /> RIP: 0033:0x7f174d639a7d<br /> Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 8a c1 f4 ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 de c1 f4 ff 48<br /> RSP: 002b:00007ffcb563ea50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f174d639a7d<br /> RDX: 0000000000000000 RSI: 00007ffcb563eab0 RDI: 0000000000000007<br /> RBP: 00007ffcb563eb10 R08: 0000000000000000 R09: 00000000ffffffff<br /> R10: 00000000004040a0 R11: 0000000000000293 R12: 00007ffcb563ec28<br /> R13: 0000000000401398 R14: 0000000000403e00 R15: 00007f174d72c000<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: tegra: xusb: Clear the driver reference in usb-phy dev<br /> <br /> For the dual-role port, it will assign the phy dev to usb-phy dev and<br /> use the port dev driver as the dev driver of usb-phy.<br /> <br /> When we try to destroy the port dev, it will destroy its dev driver<br /> as well. But we did not remove the reference from usb-phy dev. This<br /> might cause the use-after-free issue in KASAN.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: firewire-digi00x: prevent potential use after free<br /> <br /> This code was supposed to return an error code if init_stream()<br /> failed, but it instead freed dg00x-&gt;rx_stream and returned success.<br /> This potentially leads to a use after free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix NULL pointer dereference on fastopen early fallback<br /> <br /> In case of early fallback to TCP, subflow_syn_recv_sock() deletes<br /> the subflow context before returning the newly allocated sock to<br /> the caller.<br /> <br /> The fastopen path does not cope with the above unconditionally<br /> dereferencing the subflow context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Add preempt_count_{sub,add} into btf id deny list<br /> <br /> The recursion check in __bpf_prog_enter* and __bpf_prog_exit*<br /> leave preempt_count_{sub,add} unprotected. When attaching trampoline to<br /> them we get panic as follows,<br /> <br /> [ 867.843050] BUG: TASK stack guard page was hit at 0000000009d325cf (stack is 0000000046a46a15..00000000537e7b28)<br /> [ 867.843064] stack guard page: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 867.843067] CPU: 8 PID: 11009 Comm: trace Kdump: loaded Not tainted 6.2.0+ #4<br /> [ 867.843100] Call Trace:<br /> [ 867.843101] <br /> [ 867.843104] asm_exc_int3+0x3a/0x40<br /> [ 867.843108] RIP: 0010:preempt_count_sub+0x1/0xa0<br /> [ 867.843135] __bpf_prog_enter_recur+0x17/0x90<br /> [ 867.843148] bpf_trampoline_6442468108_0+0x2e/0x1000<br /> [ 867.843154] ? preempt_count_sub+0x1/0xa0<br /> [ 867.843157] preempt_count_sub+0x5/0xa0<br /> [ 867.843159] ? migrate_enable+0xac/0xf0<br /> [ 867.843164] __bpf_prog_exit_recur+0x2d/0x40<br /> [ 867.843168] bpf_trampoline_6442468108_0+0x55/0x1000<br /> ...<br /> [ 867.843788] preempt_count_sub+0x5/0xa0<br /> [ 867.843793] ? migrate_enable+0xac/0xf0<br /> [ 867.843829] __bpf_prog_exit_recur+0x2d/0x40<br /> [ 867.843837] BUG: IRQ stack guard page was hit at 0000000099bd8228 (stack is 00000000b23e2bc4..000000006d95af35)<br /> [ 867.843841] BUG: IRQ stack guard page was hit at 000000005ae07924 (stack is 00000000ffd69623..0000000014eb594c)<br /> [ 867.843843] BUG: IRQ stack guard page was hit at 00000000028320f0 (stack is 00000000034b6438..0000000078d1bcec)<br /> [ 867.843842] bpf_trampoline_6442468108_0+0x55/0x1000<br /> ...<br /> <br /> That is because in __bpf_prog_exit_recur, the preempt_count_{sub,add} are<br /> called after prog-&gt;active is decreased.<br /> <br /> Fixing this by adding these two functions into btf ids deny list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubi: Fix possible null-ptr-deref in ubi_free_volume()<br /> <br /> It willl cause null-ptr-deref in the following case:<br /> <br /> uif_init()<br /> ubi_add_volume()<br /> cdev_add() -&gt; if it fails, call kill_volumes()<br /> device_register()<br /> <br /> kill_volumes() -&gt; if ubi_add_volume() fails call this function<br /> ubi_free_volume()<br /> cdev_del()<br /> device_unregister() -&gt; trying to delete a not added device,<br /> it causes null-ptr-deref<br /> <br /> So in ubi_free_volume(), it delete devices whether they are added<br /> or not, it will causes null-ptr-deref.<br /> <br /> Handle the error case whlie calling ubi_add_volume() to fix this<br /> problem. If add volume fails, set the corresponding vol to null,<br /> so it can not be accessed in kill_volumes() and release the<br /> resource in ubi_add_volume() error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-cgroup: hold queue_lock when removing blkg-&gt;q_node<br /> <br /> When blkg is removed from q-&gt;blkg_list from blkg_free_workfn(), queue_lock<br /> has to be held, otherwise, all kinds of bugs(list corruption, hard lockup,<br /> ..) can be triggered from blkg_destroy_all().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_pmem: add the missing REQ_OP_WRITE for flush bio<br /> <br /> When doing mkfs.xfs on a pmem device, the following warning was<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 2 PID: 384 at block/blk-core.c:751 submit_bio_noacct<br /> Modules linked in:<br /> CPU: 2 PID: 384 Comm: mkfs.xfs Not tainted 6.4.0-rc7+ #154<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> RIP: 0010:submit_bio_noacct+0x340/0x520<br /> ......<br /> Call Trace:<br /> <br /> ? submit_bio_noacct+0xd5/0x520<br /> submit_bio+0x37/0x60<br /> async_pmem_flush+0x79/0xa0<br /> nvdimm_flush+0x17/0x40<br /> pmem_submit_bio+0x370/0x390<br /> __submit_bio+0xbc/0x190<br /> submit_bio_noacct_nocheck+0x14d/0x370<br /> submit_bio_noacct+0x1ef/0x520<br /> submit_bio+0x55/0x60<br /> submit_bio_wait+0x5a/0xc0<br /> blkdev_issue_flush+0x44/0x60<br /> <br /> The root cause is that submit_bio_noacct() needs bio_op() is either<br /> WRITE or ZONE_APPEND for flush bio and async_pmem_flush() doesn&amp;#39;t assign<br /> REQ_OP_WRITE when allocating flush bio, so submit_bio_noacct just fail<br /> the flush bio.<br /> <br /> Simply fix it by adding the missing REQ_OP_WRITE for flush bio. And we<br /> could fix the flush order issue and do flush optimization later.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbe: Fix panic during XDP_TX with &gt; 64 CPUs<br /> <br /> Commit 4fe815850bdc ("ixgbe: let the xdpdrv work with more than 64 cpus")<br /> adds support to allow XDP programs to run on systems with more than<br /> 64 CPUs by locking the XDP TX rings and indexing them using cpu % 64<br /> (IXGBE_MAX_XDP_QS).<br /> <br /> Upon trying this out patch on a system with more than 64 cores,<br /> the kernel paniced with an array-index-out-of-bounds at the return in<br /> ixgbe_determine_xdp_ring in ixgbe.h, which means ixgbe_determine_xdp_q_idx<br /> was just returning the cpu instead of cpu % IXGBE_MAX_XDP_QS. An example<br /> splat:<br /> <br /> ==========================================================================<br /> UBSAN: array-index-out-of-bounds in<br /> /var/lib/dkms/ixgbe/5.18.6+focal-1/build/src/ixgbe.h:1147:26<br /> index 65 is out of range for type &amp;#39;ixgbe_ring *[64]&amp;#39;<br /> ==========================================================================<br /> BUG: kernel NULL pointer dereference, address: 0000000000000058<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP NOPTI<br /> CPU: 65 PID: 408 Comm: ksoftirqd/65<br /> Tainted: G IOE 5.15.0-48-generic #54~20.04.1-Ubuntu<br /> Hardware name: Dell Inc. PowerEdge R640/0W23H8, BIOS 2.5.4 01/13/2020<br /> RIP: 0010:ixgbe_xmit_xdp_ring+0x1b/0x1c0 [ixgbe]<br /> Code: 3b 52 d4 cf e9 42 f2 ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 55 b9<br /> 00 00 00 00 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 0f b7<br /> 47 58 0f b7 47 5a 0f b7 57 54 44 0f b7 76 08 66 41 39 c0<br /> RSP: 0018:ffffbc3fcd88fcb0 EFLAGS: 00010282<br /> RAX: ffff92a253260980 RBX: ffffbc3fe68b00a0 RCX: 0000000000000000<br /> RDX: ffff928b5f659000 RSI: ffff928b5f659000 RDI: 0000000000000000<br /> RBP: ffffbc3fcd88fce0 R08: ffff92b9dfc20580 R09: 0000000000000001<br /> R10: 3d3d3d3d3d3d3d3d R11: 3d3d3d3d3d3d3d3d R12: 0000000000000000<br /> R13: ffff928b2f0fa8c0 R14: ffff928b9be20050 R15: 000000000000003c<br /> FS: 0000000000000000(0000) GS:ffff92b9dfc00000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000058 CR3: 000000011dd6a002 CR4: 00000000007706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ixgbe_poll+0x103e/0x1280 [ixgbe]<br /> ? sched_clock_cpu+0x12/0xe0<br /> __napi_poll+0x30/0x160<br /> net_rx_action+0x11c/0x270<br /> __do_softirq+0xda/0x2ee<br /> run_ksoftirqd+0x2f/0x50<br /> smpboot_thread_fn+0xb7/0x150<br /> ? sort_range+0x30/0x30<br /> kthread+0x127/0x150<br /> ? set_kthread_struct+0x50/0x50<br /> ret_from_fork+0x1f/0x30<br /> <br /> <br /> I think this is how it happens:<br /> <br /> Upon loading the first XDP program on a system with more than 64 CPUs,<br /> ixgbe_xdp_locking_key is incremented in ixgbe_xdp_setup. However,<br /> immediately after this, the rings are reconfigured by ixgbe_setup_tc.<br /> ixgbe_setup_tc calls ixgbe_clear_interrupt_scheme which calls<br /> ixgbe_free_q_vectors which calls ixgbe_free_q_vector in a loop.<br /> ixgbe_free_q_vector decrements ixgbe_xdp_locking_key once per call if<br /> it is non-zero. Commenting out the decrement in ixgbe_free_q_vector<br /> stopped my system from panicing.<br /> <br /> I suspect to make the original patch work, I would need to load an XDP<br /> program and then replace it in order to get ixgbe_xdp_locking_key back<br /> above 0 since ixgbe_setup_tc is only called when transitioning between<br /> XDP and non-XDP ring configurations, while ixgbe_xdp_locking_key is<br /> incremented every time ixgbe_xdp_setup is called.<br /> <br /> Also, ixgbe_setup_tc can be called via ethtool --set-channels, so this<br /> becomes another path to decrement ixgbe_xdp_locking_key to 0 on systems<br /> with more than 64 CPUs.<br /> <br /> Since ixgbe_xdp_locking_key only protects the XDP_TX path and is tied<br /> to the number of CPUs present, there is no reason to disable it upon<br /> unloading an XDP program. To avoid confusion, I have moved enabling<br /> ixgbe_xdp_locking_key into ixgbe_sw_init, which is part of the probe path.