Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: hisi_sas: Add cond_resched() for no forced preemption model<br /> <br /> For no forced preemption model kernel, in the scenario where the<br /> expander is connected to 12 high performance SAS SSDs, the following<br /> call trace may occur:<br /> <br /> [ 214.409199][ C240] watchdog: BUG: soft lockup - CPU#240 stuck for 22s! [irq/149-hisi_sa:3211]<br /> [ 214.568533][ C240] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)<br /> [ 214.575224][ C240] pc : fput_many+0x8c/0xdc<br /> [ 214.579480][ C240] lr : fput+0x1c/0xf0<br /> [ 214.583302][ C240] sp : ffff80002de2b900<br /> [ 214.587298][ C240] x29: ffff80002de2b900 x28: ffff1082aa412000<br /> [ 214.593291][ C240] x27: ffff3062a0348c08 x26: ffff80003a9f6000<br /> [ 214.599284][ C240] x25: ffff1062bbac5c40 x24: 0000000000001000<br /> [ 214.605277][ C240] x23: 000000000000000a x22: 0000000000000001<br /> [ 214.611270][ C240] x21: 0000000000001000 x20: 0000000000000000<br /> [ 214.617262][ C240] x19: ffff3062a41ae580 x18: 0000000000010000<br /> [ 214.623255][ C240] x17: 0000000000000001 x16: ffffdb3a6efe5fc0<br /> [ 214.629248][ C240] x15: ffffffffffffffff x14: 0000000003ffffff<br /> [ 214.635241][ C240] x13: 000000000000ffff x12: 000000000000029c<br /> [ 214.641234][ C240] x11: 0000000000000006 x10: ffff80003a9f7fd0<br /> [ 214.647226][ C240] x9 : ffffdb3a6f0482fc x8 : 0000000000000001<br /> [ 214.653219][ C240] x7 : 0000000000000002 x6 : 0000000000000080<br /> [ 214.659212][ C240] x5 : ffff55480ee9b000 x4 : fffffde7f94c6554<br /> [ 214.665205][ C240] x3 : 0000000000000002 x2 : 0000000000000020<br /> [ 214.671198][ C240] x1 : 0000000000000021 x0 : ffff3062a41ae5b8<br /> [ 214.677191][ C240] Call trace:<br /> [ 214.680320][ C240] fput_many+0x8c/0xdc<br /> [ 214.684230][ C240] fput+0x1c/0xf0<br /> [ 214.687707][ C240] aio_complete_rw+0xd8/0x1fc<br /> [ 214.692225][ C240] blkdev_bio_end_io+0x98/0x140<br /> [ 214.696917][ C240] bio_endio+0x160/0x1bc<br /> [ 214.701001][ C240] blk_update_request+0x1c8/0x3bc<br /> [ 214.705867][ C240] scsi_end_request+0x3c/0x1f0<br /> [ 214.710471][ C240] scsi_io_completion+0x7c/0x1a0<br /> [ 214.715249][ C240] scsi_finish_command+0x104/0x140<br /> [ 214.720200][ C240] scsi_softirq_done+0x90/0x180<br /> [ 214.724892][ C240] blk_mq_complete_request+0x5c/0x70<br /> [ 214.730016][ C240] scsi_mq_done+0x48/0xac<br /> [ 214.734194][ C240] sas_scsi_task_done+0xbc/0x16c [libsas]<br /> [ 214.739758][ C240] slot_complete_v3_hw+0x260/0x760 [hisi_sas_v3_hw]<br /> [ 214.746185][ C240] cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw]<br /> [ 214.752179][ C240] irq_thread_fn+0x34/0xa4<br /> [ 214.756435][ C240] irq_thread+0xc4/0x130<br /> [ 214.760520][ C240] kthread+0x108/0x13c<br /> [ 214.764430][ C240] ret_from_fork+0x10/0x18<br /> <br /> This is because in the hisi_sas driver, both the hardware interrupt<br /> handler and the interrupt thread are executed on the same CPU. In the<br /> performance test scenario, function irq_wait_for_interrupt() will always<br /> return 0 if lots of interrupts occurs and the CPU will be continuously<br /> consumed. As a result, the CPU cannot run the watchdog thread. When the<br /> watchdog time exceeds the specified time, call trace occurs.<br /> <br /> To fix it, add cond_resched() to execute the watchdog thread.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packet<br /> <br /> This fixes not checking if skb really contains an ACL header otherwise<br /> the code may attempt to access some uninitilized/invalid memory past the<br /> valid skb-&gt;data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()<br /> <br /> This patch fixes a NULL pointer dereference bug in brcmfmac that occurs<br /> when a high &amp;#39;sd_sgentry_align&amp;#39; value applies (e.g. 512) and a lot of queued SKBs<br /> are sent from the pkt queue.<br /> <br /> The problem is the number of entries in the pre-allocated sgtable, it is<br /> nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) &gt;&gt; 4 + 1.<br /> Given the default [rt]xglom_size=32 it&amp;#39;s actually 35 which is too small.<br /> Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB<br /> is added for each original SKB if tailroom isn&amp;#39;t enough to hold tail_pad.<br /> At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop"<br /> in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return<br /> NULL and this causes the oops.<br /> <br /> The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle<br /> the worst-case.<br /> Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464<br /> additional bytes of memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: set the right AMDGPU sg segment limitation<br /> <br /> The driver needs to set the correct max_segment_size;<br /> otherwise debug_dma_map_sg() will complain about the<br /> over-mapping of the AMDGPU sg length as following:<br /> <br /> WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370<br /> [ 364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd<br /> [ 364.049532] ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii<br /> [ 364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G OE 6.10.0-custom #492<br /> [ 364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021<br /> [ 364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370<br /> [ 364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05<br /> [ 364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286<br /> [ 364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027<br /> [ 364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680<br /> [ 364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930<br /> [ 364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000<br /> [ 364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800<br /> [ 364.049599] FS: 00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000<br /> [ 364.049601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0<br /> [ 364.049605] Call Trace:<br /> [ 364.049607] <br /> [ 364.049609] ? show_regs+0x6d/0x80<br /> [ 364.049614] ? __warn+0x8c/0x140<br /> [ 364.049618] ? debug_dma_map_sg+0x2dc/0x370<br /> [ 364.049621] ? report_bug+0x193/0x1a0<br /> [ 364.049627] ? handle_bug+0x46/0x80<br /> [ 364.049631] ? exc_invalid_op+0x1d/0x80<br /> [ 364.049635] ? asm_exc_invalid_op+0x1f/0x30<br /> [ 364.049642] ? debug_dma_map_sg+0x2dc/0x370<br /> [ 364.049647] __dma_map_sg_attrs+0x90/0xe0<br /> [ 364.049651] dma_map_sgtable+0x25/0x40<br /> [ 364.049654] amdgpu_bo_move+0x59a/0x850 [amdgpu]<br /> [ 364.049935] ? srso_return_thunk+0x5/0x5f<br /> [ 364.049939] ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu]<br /> [ 364.050095] ttm_bo_handle_move_mem+0xc3/0x180 [ttm]<br /> [ 364.050103] ttm_bo_validate+0xc1/0x160 [ttm]<br /> [ 364.050108] ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu]<br /> [ 364.050263] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu]<br /> [ 364.050473] kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu]<br /> [ 364.050680] kfd_ioctl+0x3c2/0x530 [amdgpu]<br /> [ 364.050866] ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu]<br /> [ 364.05105<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: add a check to prevent array-index-out-of-bounds in dbAdjTree<br /> <br /> When the value of lp is 0 at the beginning of the for loop, it will<br /> become negative in the next assignment and we should bail out.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix array-index-out-of-bounds in jfs_readdir<br /> <br /> The stbl might contain some invalid values. Added a check to<br /> return error code in that case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: qcom: camss: fix error path on configuration of power domains<br /> <br /> There is a chance to meet runtime issues during configuration of CAMSS<br /> power domains, because on the error path dev_pm_domain_detach() is<br /> unexpectedly called with NULL or error pointer.<br /> <br /> One of the simplest ways to reproduce the problem is to probe CAMSS<br /> driver before registration of CAMSS power domains, for instance if<br /> a platform CAMCC driver is simply not built.<br /> <br /> Warning backtrace example:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 00000000000001a2<br /> <br /> <br /> <br /> pc : dev_pm_domain_detach+0x8/0x48<br /> lr : camss_probe+0x374/0x9c0<br /> <br /> <br /> <br /> Call trace:<br /> dev_pm_domain_detach+0x8/0x48<br /> platform_probe+0x70/0xf0<br /> really_probe+0xc4/0x2a8<br /> __driver_probe_device+0x80/0x140<br /> driver_probe_device+0x48/0x170<br /> __device_attach_driver+0xc0/0x148<br /> bus_for_each_drv+0x88/0xf0<br /> __device_attach+0xb0/0x1c0<br /> device_initial_probe+0x1c/0x30<br /> bus_probe_device+0xb4/0xc0<br /> deferred_probe_work_func+0x90/0xd0<br /> process_one_work+0x164/0x3e0<br /> worker_thread+0x310/0x420<br /> kthread+0x120/0x130<br /> ret_from_fork+0x10/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/deadline: Fix warning in migrate_enable for boosted tasks<br /> <br /> When running the following command:<br /> <br /> while true; do<br /> stress-ng --cyclic 30 --timeout 30s --minimize --quiet<br /> done<br /> <br /> a warning is eventually triggered:<br /> <br /> WARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794<br /> setup_new_dl_entity+0x13e/0x180<br /> ...<br /> Call Trace:<br /> <br /> ? show_trace_log_lvl+0x1c4/0x2df<br /> ? enqueue_dl_entity+0x631/0x6e0<br /> ? setup_new_dl_entity+0x13e/0x180<br /> ? __warn+0x7e/0xd0<br /> ? report_bug+0x11a/0x1a0<br /> ? handle_bug+0x3c/0x70<br /> ? exc_invalid_op+0x14/0x70<br /> ? asm_exc_invalid_op+0x16/0x20<br /> enqueue_dl_entity+0x631/0x6e0<br /> enqueue_task_dl+0x7d/0x120<br /> __do_set_cpus_allowed+0xe3/0x280<br /> __set_cpus_allowed_ptr_locked+0x140/0x1d0<br /> __set_cpus_allowed_ptr+0x54/0xa0<br /> migrate_enable+0x7e/0x150<br /> rt_spin_unlock+0x1c/0x90<br /> group_send_sig_info+0xf7/0x1a0<br /> ? kill_pid_info+0x1f/0x1d0<br /> kill_pid_info+0x78/0x1d0<br /> kill_proc_info+0x5b/0x110<br /> __x64_sys_kill+0x93/0xc0<br /> do_syscall_64+0x5c/0xf0<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> RIP: 0033:0x7f0dab31f92b<br /> <br /> This warning occurs because set_cpus_allowed dequeues and enqueues tasks<br /> with the ENQUEUE_RESTORE flag set. If the task is boosted, the warning<br /> is triggered. A boosted task already had its parameters set by<br /> rt_mutex_setprio, and a new call to setup_new_dl_entity is unnecessary,<br /> hence the WARN_ON call.<br /> <br /> Check if we are requeueing a boosted task and avoid calling<br /> setup_new_dl_entity if that&amp;#39;s the case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: ref-verify: fix use-after-free after invalid ref action<br /> <br /> At btrfs_ref_tree_mod() after we successfully inserted the new ref entry<br /> (local variable &amp;#39;ref&amp;#39;) into the respective block entry&amp;#39;s rbtree (local<br /> variable &amp;#39;be&amp;#39;), if we find an unexpected action of BTRFS_DROP_DELAYED_REF,<br /> we error out and free the ref entry without removing it from the block<br /> entry&amp;#39;s rbtree. Then in the error path of btrfs_ref_tree_mod() we call<br /> btrfs_free_ref_cache(), which iterates over all block entries and then<br /> calls free_block_entry() for each one, and there we will trigger a<br /> use-after-free when we are called against the block entry to which we<br /> added the freed ref entry to its rbtree, since the rbtree still points<br /> to the block entry, as we didn&amp;#39;t remove it from the rbtree before freeing<br /> it in the error path at btrfs_ref_tree_mod(). Fix this by removing the<br /> new ref entry from the rbtree before freeing it.<br /> <br /> Syzbot report this with the following stack traces:<br /> <br /> BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615<br /> __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523<br /> update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512<br /> btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594<br /> btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754<br /> btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116<br /> btrfs_insert_empty_items+0x9c/0x1a0 fs/btrfs/ctree.c:4314<br /> btrfs_insert_empty_item fs/btrfs/ctree.h:669 [inline]<br /> btrfs_insert_orphan_item+0x1f1/0x320 fs/btrfs/orphan.c:23<br /> btrfs_orphan_add+0x6d/0x1a0 fs/btrfs/inode.c:3482<br /> btrfs_unlink+0x267/0x350 fs/btrfs/inode.c:4293<br /> vfs_unlink+0x365/0x650 fs/namei.c:4469<br /> do_unlinkat+0x4ae/0x830 fs/namei.c:4533<br /> __do_sys_unlinkat fs/namei.c:4576 [inline]<br /> __se_sys_unlinkat fs/namei.c:4569 [inline]<br /> __x64_sys_unlinkat+0xcc/0xf0 fs/namei.c:4569<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> BTRFS error (device loop0 state EA): Ref action 1, root 5, ref_root 5, parent 0, owner 260, offset 0, num_refs 1<br /> __btrfs_mod_ref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521<br /> update_ref_for_cow+0x96a/0x11f0<br /> btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594<br /> btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754<br /> btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116<br /> btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411<br /> __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030<br /> btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline]<br /> __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137<br /> __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171<br /> btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313<br /> prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586<br /> relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611<br /> btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081<br /> btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377<br /> __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161<br /> btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538<br /> BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615<br /> __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523<br /> update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512<br /> btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594<br /> btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754<br /> btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116<br /> btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411<br /> __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030<br /> btrfs_update_delayed_i<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix use-after-free in btrfs_encoded_read_endio()<br /> <br /> Shinichiro reported the following use-after free that sometimes is<br /> happening in our CI system when running fstests&amp;#39; btrfs/284 on a TCMU<br /> runner device:<br /> <br /> BUG: KASAN: slab-use-after-free in lock_release+0x708/0x780<br /> Read of size 8 at addr ffff888106a83f18 by task kworker/u80:6/219<br /> <br /> CPU: 8 UID: 0 PID: 219 Comm: kworker/u80:6 Not tainted 6.12.0-rc6-kts+ #15<br /> Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020<br /> Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6e/0xa0<br /> ? lock_release+0x708/0x780<br /> print_report+0x174/0x505<br /> ? lock_release+0x708/0x780<br /> ? __virt_addr_valid+0x224/0x410<br /> ? lock_release+0x708/0x780<br /> kasan_report+0xda/0x1b0<br /> ? lock_release+0x708/0x780<br /> ? __wake_up+0x44/0x60<br /> lock_release+0x708/0x780<br /> ? __pfx_lock_release+0x10/0x10<br /> ? __pfx_do_raw_spin_lock+0x10/0x10<br /> ? lock_is_held_type+0x9a/0x110<br /> _raw_spin_unlock_irqrestore+0x1f/0x60<br /> __wake_up+0x44/0x60<br /> btrfs_encoded_read_endio+0x14b/0x190 [btrfs]<br /> btrfs_check_read_bio+0x8d9/0x1360 [btrfs]<br /> ? lock_release+0x1b0/0x780<br /> ? trace_lock_acquire+0x12f/0x1a0<br /> ? __pfx_btrfs_check_read_bio+0x10/0x10 [btrfs]<br /> ? process_one_work+0x7e3/0x1460<br /> ? lock_acquire+0x31/0xc0<br /> ? process_one_work+0x7e3/0x1460<br /> process_one_work+0x85c/0x1460<br /> ? __pfx_process_one_work+0x10/0x10<br /> ? assign_work+0x16c/0x240<br /> worker_thread+0x5e6/0xfc0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x2c3/0x3a0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x31/0x70<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Allocated by task 3661:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0xaa/0xb0<br /> btrfs_encoded_read_regular_fill_pages+0x16c/0x6d0 [btrfs]<br /> send_extent_data+0xf0f/0x24a0 [btrfs]<br /> process_extent+0x48a/0x1830 [btrfs]<br /> changed_cb+0x178b/0x2ea0 [btrfs]<br /> btrfs_ioctl_send+0x3bf9/0x5c20 [btrfs]<br /> _btrfs_ioctl_send+0x117/0x330 [btrfs]<br /> btrfs_ioctl+0x184a/0x60a0 [btrfs]<br /> __x64_sys_ioctl+0x12e/0x1a0<br /> do_syscall_64+0x95/0x180<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Freed by task 3661:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3b/0x70<br /> __kasan_slab_free+0x4f/0x70<br /> kfree+0x143/0x490<br /> btrfs_encoded_read_regular_fill_pages+0x531/0x6d0 [btrfs]<br /> send_extent_data+0xf0f/0x24a0 [btrfs]<br /> process_extent+0x48a/0x1830 [btrfs]<br /> changed_cb+0x178b/0x2ea0 [btrfs]<br /> btrfs_ioctl_send+0x3bf9/0x5c20 [btrfs]<br /> _btrfs_ioctl_send+0x117/0x330 [btrfs]<br /> btrfs_ioctl+0x184a/0x60a0 [btrfs]<br /> __x64_sys_ioctl+0x12e/0x1a0<br /> do_syscall_64+0x95/0x180<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The buggy address belongs to the object at ffff888106a83f00<br /> which belongs to the cache kmalloc-rnd-07-96 of size 96<br /> The buggy address is located 24 bytes inside of<br /> freed 96-byte region [ffff888106a83f00, ffff888106a83f60)<br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888106a83800 pfn:0x106a83<br /> flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)<br /> page_type: f5(slab)<br /> raw: 0017ffffc0000000 ffff888100053680 ffffea0004917200 0000000000000004<br /> raw: ffff888106a83800 0000000080200019 00000001f5000000 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff888106a83e00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> ffff888106a83e80: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> &gt;ffff888106a83f00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> ^<br /> ffff888106a83f80: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> ffff888106a84000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ==================================================================<br /> <br /> Further analyzing the trace and <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/tctx: work around xa_store() allocation error issue<br /> <br /> syzbot triggered the following WARN_ON:<br /> <br /> WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51<br /> <br /> which is the<br /> <br /> WARN_ON_ONCE(!xa_empty(&amp;tctx-&gt;xa));<br /> <br /> sanity check in __io_uring_free() when a io_uring_task is going through<br /> its final put. The syzbot test case includes injecting memory allocation<br /> failures, and it very much looks like xa_store() can fail one of its<br /> memory allocations and end up with -&gt;head being non-NULL even though no<br /> entries exist in the xarray.<br /> <br /> Until this issue gets sorted out, work around it by attempting to<br /> iterate entries in our xarray, and WARN_ON_ONCE() if one is found.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Fix sleeping in atomic context for PREEMPT_RT<br /> <br /> Commit bab1c299f3945ffe79 ("LoongArch: Fix sleeping in atomic context in<br /> setup_tlb_handler()") changes the gfp flag from GFP_KERNEL to GFP_ATOMIC<br /> for alloc_pages_node(). However, for PREEMPT_RT kernels we can still get<br /> a "sleeping in atomic context" error:<br /> <br /> [ 0.372259] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> [ 0.372266] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1<br /> [ 0.372268] preempt_count: 1, expected: 0<br /> [ 0.372270] RCU nest depth: 1, expected: 1<br /> [ 0.372272] 3 locks held by swapper/1/0:<br /> [ 0.372274] #0: 900000000c9f5e60 (&amp;pcp-&gt;lock){+.+.}-{3:3}, at: get_page_from_freelist+0x524/0x1c60<br /> [ 0.372294] #1: 90000000087013b8 (rcu_read_lock){....}-{1:3}, at: rt_spin_trylock+0x50/0x140<br /> [ 0.372305] #2: 900000047fffd388 (&amp;zone-&gt;lock){+.+.}-{3:3}, at: __rmqueue_pcplist+0x30c/0xea0<br /> [ 0.372314] irq event stamp: 0<br /> [ 0.372316] hardirqs last enabled at (0): [] 0x0<br /> [ 0.372322] hardirqs last disabled at (0): [] copy_process+0x9c0/0x26e0<br /> [ 0.372329] softirqs last enabled at (0): [] copy_process+0x9c0/0x26e0<br /> [ 0.372335] softirqs last disabled at (0): [] 0x0<br /> [ 0.372341] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.12.0-rc7+ #1891<br /> [ 0.372346] Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022<br /> [ 0.372349] Stack : 0000000000000089 9000000005a0db9c 90000000071519c8 9000000100388000<br /> [ 0.372486] 900000010038b890 0000000000000000 900000010038b898 9000000007e53788<br /> [ 0.372492] 900000000815bcc8 900000000815bcc0 900000010038b700 0000000000000001<br /> [ 0.372498] 0000000000000001 4b031894b9d6b725 00000000055ec000 9000000100338fc0<br /> [ 0.372503] 00000000000000c4 0000000000000001 000000000000002d 0000000000000003<br /> [ 0.372509] 0000000000000030 0000000000000003 00000000055ec000 0000000000000003<br /> [ 0.372515] 900000000806d000 9000000007e53788 00000000000000b0 0000000000000004<br /> [ 0.372521] 0000000000000000 0000000000000000 900000000c9f5f10 0000000000000000<br /> [ 0.372526] 90000000076f12d8 9000000007e53788 9000000005924778 0000000000000000<br /> [ 0.372532] 00000000000000b0 0000000000000004 0000000000000000 0000000000070000<br /> [ 0.372537] ...<br /> [ 0.372540] Call Trace:<br /> [ 0.372542] [] show_stack+0x38/0x180<br /> [ 0.372548] [] dump_stack_lvl+0x94/0xe4<br /> [ 0.372555] [] __might_resched+0x1a0/0x260<br /> [ 0.372561] [] rt_spin_lock+0x4c/0x140<br /> [ 0.372565] [] __rmqueue_pcplist+0x308/0xea0<br /> [ 0.372570] [] get_page_from_freelist+0x564/0x1c60<br /> [ 0.372575] [] __alloc_pages_noprof+0x218/0x1820<br /> [ 0.372580] [] tlb_init+0x1ac/0x298<br /> [ 0.372585] [] per_cpu_trap_init+0x114/0x140<br /> [ 0.372589] [] cpu_probe+0x4e4/0xa60<br /> [ 0.372592] [] start_secondary+0x34/0xc0<br /> [ 0.372599] [] smpboot_entry+0x64/0x6c<br /> <br /> This is because in PREEMPT_RT kernels normal spinlocks are replaced by<br /> rt spinlocks and rt_spin_lock() will cause sleeping. Fix it by disabling<br /> NUMA optimization completely for PREEMPT_RT kernels.