Vulnerabilities

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 /> 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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode.<br /> <br /> creating a large files during checkpoint disable until it runs out of<br /> space and then delete it, then remount to enable checkpoint again, and<br /> then unmount the filesystem triggers the f2fs_bug_on as below:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/inode.c:896!<br /> CPU: 2 UID: 0 PID: 1286 Comm: umount Not tainted 6.11.0-rc7-dirty #360<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> RIP: 0010:f2fs_evict_inode+0x58c/0x610<br /> Call Trace:<br /> __die_body+0x15/0x60<br /> die+0x33/0x50<br /> do_trap+0x10a/0x120<br /> f2fs_evict_inode+0x58c/0x610<br /> do_error_trap+0x60/0x80<br /> f2fs_evict_inode+0x58c/0x610<br /> exc_invalid_op+0x53/0x60<br /> f2fs_evict_inode+0x58c/0x610<br /> asm_exc_invalid_op+0x16/0x20<br /> f2fs_evict_inode+0x58c/0x610<br /> evict+0x101/0x260<br /> dispose_list+0x30/0x50<br /> evict_inodes+0x140/0x190<br /> generic_shutdown_super+0x2f/0x150<br /> kill_block_super+0x11/0x40<br /> kill_f2fs_super+0x7d/0x140<br /> deactivate_locked_super+0x2a/0x70<br /> cleanup_mnt+0xb3/0x140<br /> task_work_run+0x61/0x90<br /> <br /> The root cause is: creating large files during disable checkpoint<br /> period results in not enough free segments, so when writing back root<br /> inode will failed in f2fs_enable_checkpoint. When umount the file<br /> system after enabling checkpoint, the root inode is dirty in<br /> f2fs_evict_inode function, which triggers BUG_ON. The steps to<br /> reproduce are as follows:<br /> <br /> dd if=/dev/zero of=f2fs.img bs=1M count=55<br /> mount f2fs.img f2fs_dir -o checkpoint=disable:10%<br /> dd if=/dev/zero of=big bs=1M count=50<br /> sync<br /> rm big<br /> mount -o remount,checkpoint=enable f2fs_dir<br /> umount f2fs_dir<br /> <br /> Let&amp;#39;s redirty inode when there is not free segments during checkpoint<br /> is disable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> leds: class: Protect brightness_show() with led_cdev-&gt;led_access mutex<br /> <br /> There is NULL pointer issue observed if from Process A where hid device<br /> being added which results in adding a led_cdev addition and later a<br /> another call to access of led_cdev attribute from Process B can result<br /> in NULL pointer issue.<br /> <br /> Use mutex led_cdev-&gt;led_access to protect access to led-&gt;cdev and its<br /> attribute inside brightness_show() and max_brightness_show() and also<br /> update the comment for mutex that it should be used to protect the led<br /> class device fields.<br /> <br /> Process A Process B<br /> <br /> kthread+0x114<br /> worker_thread+0x244<br /> process_scheduled_works+0x248<br /> uhid_device_add_worker+0x24<br /> hid_add_device+0x120<br /> device_add+0x268<br /> bus_probe_device+0x94<br /> device_initial_probe+0x14<br /> __device_attach+0xfc<br /> bus_for_each_drv+0x10c<br /> __device_attach_driver+0x14c<br /> driver_probe_device+0x3c<br /> __driver_probe_device+0xa0<br /> really_probe+0x190<br /> hid_device_probe+0x130<br /> ps_probe+0x990<br /> ps_led_register+0x94<br /> devm_led_classdev_register_ext+0x58<br /> led_classdev_register_ext+0x1f8<br /> device_create_with_groups+0x48<br /> device_create_groups_vargs+0xc8<br /> device_add+0x244<br /> kobject_uevent+0x14<br /> kobject_uevent_env[jt]+0x224<br /> mutex_unlock[jt]+0xc4<br /> __mutex_unlock_slowpath+0xd4<br /> wake_up_q+0x70<br /> try_to_wake_up[jt]+0x48c<br /> preempt_schedule_common+0x28<br /> __schedule+0x628<br /> __switch_to+0x174<br /> el0t_64_sync+0x1a8/0x1ac<br /> el0t_64_sync_handler+0x68/0xbc<br /> el0_svc+0x38/0x68<br /> do_el0_svc+0x1c/0x28<br /> el0_svc_common+0x80/0xe0<br /> invoke_syscall+0x58/0x114<br /> __arm64_sys_read+0x1c/0x2c<br /> ksys_read+0x78/0xe8<br /> vfs_read+0x1e0/0x2c8<br /> kernfs_fop_read_iter+0x68/0x1b4<br /> seq_read_iter+0x158/0x4ec<br /> kernfs_seq_show+0x44/0x54<br /> sysfs_kf_seq_show+0xb4/0x130<br /> dev_attr_show+0x38/0x74<br /> brightness_show+0x20/0x4c<br /> dualshock4_led_get_brightness+0xc/0x74<br /> <br /> [ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060<br /> [ 3313.874301][ T4013] Mem abort info:<br /> [ 3313.874303][ T4013] ESR = 0x0000000096000006<br /> [ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 3313.874307][ T4013] SET = 0, FnV = 0<br /> [ 3313.874309][ T4013] EA = 0, S1PTW = 0<br /> [ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault<br /> [ 3313.874313][ T4013] Data abort info:<br /> [ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000<br /> [ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000<br /> ..<br /> <br /> [ 3313.874332][ T4013] Dumping ftrace buffer:<br /> [ 3313.874334][ T4013] (ftrace buffer empty)<br /> ..<br /> ..<br /> [ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader<br /> [ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74<br /> [ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60<br /> [ 3313.874656][ T4013] sp : ffffffc0b910bbd0<br /> ..<br /> ..<br /> [ 3313.874685][ T4013] Call trace:<br /> [ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74<br /> [ 3313.874690][ T4013] brightness_show+0x20/0x4c<br /> [ 3313.874692][ T4013] dev_attr_show+0x38/0x74<br /> [ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130<br /> [ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54<br /> [ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec<br /> [ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4<br /> [ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8<br /> [ 3313.874711][ T4013] ksys_read+0x78/0xe8<br /> [ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c<br /> [ 3313.874718][ T4013] invoke_syscall+0x58/0x114<br /> [ 3313.874721][ T4013] el0_svc_common+0x80/0xe0<br /> [ 3313.874724][ T4013] do_el0_svc+0x1c/0x28<br /> [ 3313.874727][ T4013] el0_svc+0x38/0x68<br /> [ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc<br /> [ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac

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.

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