Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: fix soft lockup in status_resync<br /> <br /> status_resync() will calculate &amp;#39;curr_resync - recovery_active&amp;#39; to show<br /> user a progress bar like following:<br /> <br /> [============&gt;........] resync = 61.4%<br /> <br /> &amp;#39;curr_resync&amp;#39; and &amp;#39;recovery_active&amp;#39; is updated in md_do_sync(), and<br /> status_resync() can read them concurrently, hence it&amp;#39;s possible that<br /> &amp;#39;curr_resync - recovery_active&amp;#39; can overflow to a huge number. In this<br /> case status_resync() will be stuck in the loop to print a large amount<br /> of &amp;#39;=&amp;#39;, which will end up soft lockup.<br /> <br /> Fix the problem by setting &amp;#39;resync&amp;#39; to MD_RESYNC_ACTIVE in this case,<br /> this way resync in progress will be reported to user.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: Avoid nf_ct_helper_hash uses after free<br /> <br /> If nf_conntrack_init_start() fails (for example due to a<br /> register_nf_conntrack_bpf() failure), the nf_conntrack_helper_fini()<br /> clean-up path frees the nf_ct_helper_hash map.<br /> <br /> When built with NF_CONNTRACK=y, further netfilter modules (e.g:<br /> netfilter_conntrack_ftp) can still be loaded and call<br /> nf_conntrack_helpers_register(), independently of whether nf_conntrack<br /> initialized correctly. This accesses the nf_ct_helper_hash dangling<br /> pointer and causes a uaf, possibly leading to random memory corruption.<br /> <br /> This patch guards nf_conntrack_helper_register() from accessing a freed<br /> or uninitialized nf_ct_helper_hash pointer and fixes possible<br /> uses-after-free when loading a conntrack module.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: reject invalid reloc tree root keys with stack dump<br /> <br /> [BUG]<br /> Syzbot reported a crash that an ASSERT() got triggered inside<br /> prepare_to_merge().<br /> <br /> That ASSERT() makes sure the reloc tree is properly pointed back by its<br /> subvolume tree.<br /> <br /> [CAUSE]<br /> After more debugging output, it turns out we had an invalid reloc tree:<br /> <br /> BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17<br /> <br /> Note the above root key is (TREE_RELOC_OBJECTID, ROOT_ITEM,<br /> QUOTA_TREE_OBJECTID), meaning it&amp;#39;s a reloc tree for quota tree.<br /> <br /> But reloc trees can only exist for subvolumes, as for non-subvolume<br /> trees, we just COW the involved tree block, no need to create a reloc<br /> tree since those tree blocks won&amp;#39;t be shared with other trees.<br /> <br /> Only subvolumes tree can share tree blocks with other trees (thus they<br /> have BTRFS_ROOT_SHAREABLE flag).<br /> <br /> Thus this new debug output proves my previous assumption that corrupted<br /> on-disk data can trigger that ASSERT().<br /> <br /> [FIX]<br /> Besides the dedicated fix and the graceful exit, also let tree-checker to<br /> check such root keys, to make sure reloc trees can only exist for subvolumes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: aspeed: socinfo: Add kfree for kstrdup<br /> <br /> Add kfree() in the later error handling in order to avoid memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix a null-ptr-deref in tipc_topsrv_accept<br /> <br /> syzbot found a crash in tipc_topsrv_accept:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> Workqueue: tipc_rcv tipc_topsrv_accept<br /> RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487<br /> Call Trace:<br /> <br /> tipc_topsrv_accept+0x197/0x280 net/tipc/topsrv.c:460<br /> process_one_work+0x991/0x1610 kernel/workqueue.c:2289<br /> worker_thread+0x665/0x1080 kernel/workqueue.c:2436<br /> kthread+0x2e4/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306<br /> <br /> It was caused by srv-&gt;listener that might be set to null by<br /> tipc_topsrv_stop() in net .exit whereas it&amp;#39;s still used in<br /> tipc_topsrv_accept() worker.<br /> <br /> srv-&gt;listener is protected by srv-&gt;idr_lock in tipc_topsrv_stop(), so add<br /> a check for srv-&gt;listener under srv-&gt;idr_lock in tipc_topsrv_accept() to<br /> avoid the null-ptr-deref. To ensure the lsock is not released during the<br /> tipc_topsrv_accept(), move sock_release() after tipc_topsrv_work_stop()<br /> where it&amp;#39;s waiting until the tipc_topsrv_accept worker to be done.<br /> <br /> Note that sk_callback_lock is used to protect sk-&gt;sk_user_data instead of<br /> srv-&gt;listener, and it should check srv in tipc_topsrv_listener_data_ready()<br /> instead. This also ensures that no more tipc_topsrv_accept worker will be<br /> started after tipc_conn_close() is called in tipc_topsrv_stop() where it<br /> sets sk-&gt;sk_user_data to null.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: avoid double -&gt;queue_rq() because of early timeout<br /> <br /> David Jeffery found one double -&gt;queue_rq() issue, so far it can<br /> be triggered in VM use case because of long vmexit latency or preempt<br /> latency of vCPU pthread or long page fault in vCPU pthread, then block<br /> IO req could be timed out before queuing the request to hardware but after<br /> calling blk_mq_start_request() during -&gt;queue_rq(), then timeout handler<br /> may handle it by requeue, then double -&gt;queue_rq() is caused, and kernel<br /> panic.<br /> <br /> So far, it is driver&amp;#39;s responsibility to cover the race between timeout<br /> and completion, so it seems supposed to be solved in driver in theory,<br /> given driver has enough knowledge.<br /> <br /> But it is really one common problem, lots of driver could have similar<br /> issue, and could be hard to fix all affected drivers, even it isn&amp;#39;t easy<br /> for driver to handle the race. So David suggests this patch by draining<br /> in-progress -&gt;queue_rq() for solving this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/hist: Fix out-of-bound write on &amp;#39;action_data.var_ref_idx&amp;#39;<br /> <br /> When generate a synthetic event with many params and then create a trace<br /> action for it [1], kernel panic happened [2].<br /> <br /> It is because that in trace_action_create() &amp;#39;data-&gt;n_params&amp;#39; is up to<br /> SYNTH_FIELDS_MAX (current value is 64), and array &amp;#39;data-&gt;var_ref_idx&amp;#39;<br /> keeps indices into array &amp;#39;hist_data-&gt;var_refs&amp;#39; for each synthetic event<br /> param, but the length of &amp;#39;data-&gt;var_ref_idx&amp;#39; is TRACING_MAP_VARS_MAX<br /> (current value is 16), so out-of-bound write happened when &amp;#39;data-&gt;n_params&amp;#39;<br /> more than 16. In this case, &amp;#39;data-&gt;match_data.event&amp;#39; is overwritten and<br /> eventually cause the panic.<br /> <br /> To solve the issue, adjust the length of &amp;#39;data-&gt;var_ref_idx&amp;#39; to be<br /> SYNTH_FIELDS_MAX and add sanity checks to avoid out-of-bound write.<br /> <br /> [1]<br /> # cd /sys/kernel/tracing/<br /> # echo "my_synth_event int v1; int v2; int v3; int v4; int v5; int v6;\<br /> int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\<br /> int v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\<br /> int v23; int v24; int v25; int v26; int v27; int v28; int v29; int v30;\<br /> int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\<br /> int v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\<br /> int v47; int v48; int v49; int v50; int v51; int v52; int v53; int v54;\<br /> int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\<br /> int v63" &gt;&gt; synthetic_events<br /> # echo &amp;#39;hist:keys=pid:ts0=common_timestamp.usecs if comm=="bash"&amp;#39; &gt;&gt; \<br /> events/sched/sched_waking/trigger<br /> # echo "hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(\<br /> pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\<br /> pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\<br /> pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\<br /> pid,pid,pid,pid,pid,pid,pid,pid,pid)" &gt;&gt; events/sched/sched_switch/trigger<br /> <br /> [2]<br /> BUG: unable to handle page fault for address: ffff91c900000000<br /> PGD 61001067 P4D 61001067 PUD 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 2 PID: 322 Comm: bash Tainted: G W 6.1.0-rc8+ #229<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:strcmp+0xc/0x30<br /> Code: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee<br /> c3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 b6 14<br /> 07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3<br /> RSP: 0018:ffff9b3b00f53c48 EFLAGS: 00000246<br /> RAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000<br /> RDX: 0000000000000010 RSI: ffff91c943d33a90 RDI: ffff91c900000000<br /> RBP: ffff91c900000000 R08: 00000018d604b529 R09: 0000000000000000<br /> R10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580<br /> R13: ffff91c9479f0538 R14: ffff91c9457c2848 R15: ffff91c9479f0538<br /> FS: 00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffff91c900000000 CR3: 0000000006316000 CR4: 00000000000006e0<br /> Call Trace:<br /> <br /> __find_event_file+0x55/0x90<br /> action_create+0x76c/0x1060<br /> event_hist_trigger_parse+0x146d/0x2060<br /> ? event_trigger_write+0x31/0xd0<br /> trigger_process_regex+0xbb/0x110<br /> event_trigger_write+0x6b/0xd0<br /> vfs_write+0xc8/0x3e0<br /> ? alloc_fd+0xc0/0x160<br /> ? preempt_count_add+0x4d/0xa0<br /> ? preempt_count_add+0x70/0xa0<br /> ksys_write+0x5f/0xe0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f1d1d0cf077<br /> Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e<br /> fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 3d 00<br /> f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74<br /> RSP: 002b:00007ffcebb0e568 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000000143 RCX: 00007f1d1d0cf077<br /> RDX: 0000000000000143 RSI: 00005639265aa7e0 RDI: 0000000000000001<br /> RBP: 00005639265aa7e0 R08: 000000000000000a R09: 0000000000000142<br /> R<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request()<br /> <br /> This patch fixes a shift-out-of-bounds in brcmfmac that occurs in<br /> BIT(chiprev) when a &amp;#39;chiprev&amp;#39; provided by the device is too large.<br /> It should also not be equal to or greater than BITS_PER_TYPE(u32)<br /> as we do bitwise AND with a u32 variable and BIT(chiprev). The patch<br /> adds a check that makes the function return NULL if that is the case.<br /> Note that the NULL case is later handled by the bus-specific caller,<br /> brcmf_usb_probe_cb() or brcmf_usb_reset_resume(), for example.<br /> <br /> Found by a modified version of syzkaller.<br /> <br /> UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c<br /> shift exponent 151055786 is too large for 64-bit type &amp;#39;long unsigned int&amp;#39;<br /> CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014<br /> Workqueue: usb_hub_wq hub_event<br /> Call Trace:<br /> dump_stack_lvl+0x57/0x7d<br /> ubsan_epilogue+0x5/0x40<br /> __ubsan_handle_shift_out_of_bounds.cold+0x53/0xdb<br /> ? lock_chain_count+0x20/0x20<br /> brcmf_fw_alloc_request.cold+0x19/0x3ea<br /> ? brcmf_fw_get_firmwares+0x250/0x250<br /> ? brcmf_usb_ioctl_resp_wait+0x1a7/0x1f0<br /> brcmf_usb_get_fwname+0x114/0x1a0<br /> ? brcmf_usb_reset_resume+0x120/0x120<br /> ? number+0x6c4/0x9a0<br /> brcmf_c_process_clm_blob+0x168/0x590<br /> ? put_dec+0x90/0x90<br /> ? enable_ptr_key_workfn+0x20/0x20<br /> ? brcmf_common_pd_remove+0x50/0x50<br /> ? rcu_read_lock_sched_held+0xa1/0xd0<br /> brcmf_c_preinit_dcmds+0x673/0xc40<br /> ? brcmf_c_set_joinpref_default+0x100/0x100<br /> ? rcu_read_lock_sched_held+0xa1/0xd0<br /> ? rcu_read_lock_bh_held+0xb0/0xb0<br /> ? lock_acquire+0x19d/0x4e0<br /> ? find_held_lock+0x2d/0x110<br /> ? brcmf_usb_deq+0x1cc/0x260<br /> ? mark_held_locks+0x9f/0xe0<br /> ? lockdep_hardirqs_on_prepare+0x273/0x3e0<br /> ? _raw_spin_unlock_irqrestore+0x47/0x50<br /> ? trace_hardirqs_on+0x1c/0x120<br /> ? brcmf_usb_deq+0x1a7/0x260<br /> ? brcmf_usb_rx_fill_all+0x5a/0xf0<br /> brcmf_attach+0x246/0xd40<br /> ? wiphy_new_nm+0x1476/0x1d50<br /> ? kmemdup+0x30/0x40<br /> brcmf_usb_probe+0x12de/0x1690<br /> ? brcmf_usbdev_qinit.constprop.0+0x470/0x470<br /> usb_probe_interface+0x25f/0x710<br /> really_probe+0x1be/0xa90<br /> __driver_probe_device+0x2ab/0x460<br /> ? usb_match_id.part.0+0x88/0xc0<br /> driver_probe_device+0x49/0x120<br /> __device_attach_driver+0x18a/0x250<br /> ? driver_allows_async_probing+0x120/0x120<br /> bus_for_each_drv+0x123/0x1a0<br /> ? bus_rescan_devices+0x20/0x20<br /> ? lockdep_hardirqs_on_prepare+0x273/0x3e0<br /> ? trace_hardirqs_on+0x1c/0x120<br /> __device_attach+0x207/0x330<br /> ? device_bind_driver+0xb0/0xb0<br /> ? kobject_uevent_env+0x230/0x12c0<br /> bus_probe_device+0x1a2/0x260<br /> device_add+0xa61/0x1ce0<br /> ? __mutex_unlock_slowpath+0xe7/0x660<br /> ? __fw_devlink_link_to_suppliers+0x550/0x550<br /> usb_set_configuration+0x984/0x1770<br /> ? kernfs_create_link+0x175/0x230<br /> usb_generic_driver_probe+0x69/0x90<br /> usb_probe_device+0x9c/0x220<br /> really_probe+0x1be/0xa90<br /> __driver_probe_device+0x2ab/0x460<br /> driver_probe_device+0x49/0x120<br /> __device_attach_driver+0x18a/0x250<br /> ? driver_allows_async_probing+0x120/0x120<br /> bus_for_each_drv+0x123/0x1a0<br /> ? bus_rescan_devices+0x20/0x20<br /> ? lockdep_hardirqs_on_prepare+0x273/0x3e0<br /> ? trace_hardirqs_on+0x1c/0x120<br /> __device_attach+0x207/0x330<br /> ? device_bind_driver+0xb0/0xb0<br /> ? kobject_uevent_env+0x230/0x12c0<br /> bus_probe_device+0x1a2/0x260<br /> device_add+0xa61/0x1ce0<br /> ? __fw_devlink_link_to_suppliers+0x550/0x550<br /> usb_new_device.cold+0x463/0xf66<br /> ? hub_disconnect+0x400/0x400<br /> ? _raw_spin_unlock_irq+0x24/0x30<br /> hub_event+0x10d5/0x3330<br /> ? hub_port_debounce+0x280/0x280<br /> ? __lock_acquire+0x1671/0x5790<br /> ? wq_calc_node_cpumask+0x170/0x2a0<br /> ? lock_release+0x640/0x640<br /> ? rcu_read_lock_sched_held+0xa1/0xd0<br /> ? rcu_read_lock_bh_held+0xb0/0xb0<br /> ? lockdep_hardirqs_on_prepare+0x273/0x3e0<br /> process_one_work+0x873/0x13e0<br /> ? lock_release+0x640/0x640<br /> ? pwq_dec_nr_in_flight+0x320/0x320<br /> ? rwlock_bug.part.0+0x90/0x90<br /> worker_thread+0x8b/0xd10<br /> ? __kthread_parkme+0xd9/0x1d0<br /> ? pr<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: use quiesced elevator switch when reinitializing queues<br /> <br /> The hctx&amp;#39;s run_work may be racing with the elevator switch when<br /> reinitializing hardware queues. The queue is merely frozen in this<br /> context, but that only prevents requests from allocating and doesn&amp;#39;t<br /> stop the hctx work from running. The work may get an elevator pointer<br /> that&amp;#39;s being torn down, and can result in use-after-free errors and<br /> kernel panics (example below). Use the quiesced elevator switch instead,<br /> and make the previous one static since it is now only used locally.<br /> <br /> nvme nvme0: resetting controller<br /> nvme nvme0: 32/0/0 default/read/poll queues<br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0<br /> Oops: 0000 [#1] SMP PTI<br /> Workqueue: kblockd blk_mq_run_work_fn<br /> RIP: 0010:kyber_has_work+0x29/0x70<br /> <br /> ...<br /> <br /> Call Trace:<br /> __blk_mq_do_dispatch_sched+0x83/0x2b0<br /> __blk_mq_sched_dispatch_requests+0x12e/0x170<br /> blk_mq_sched_dispatch_requests+0x30/0x60<br /> __blk_mq_run_hw_queue+0x2b/0x50<br /> process_one_work+0x1ef/0x380<br /> worker_thread+0x2d/0x3e0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-iolatency: Fix memory leak on add_disk() failures<br /> <br /> When a gendisk is successfully initialized but add_disk() fails such as when<br /> a loop device has invalid number of minor device numbers specified,<br /> blkcg_init_disk() is called during init and then blkcg_exit_disk() during<br /> error handling. Unfortunately, iolatency gets initialized in the former but<br /> doesn&amp;#39;t get cleaned up in the latter.<br /> <br /> This is because, in non-error cases, the cleanup is performed by<br /> del_gendisk() calling rq_qos_exit(), the assumption being that rq_qos<br /> policies, iolatency being one of them, can only be activated once the disk<br /> is fully registered and visible. That assumption is true for wbt and iocost,<br /> but not so for iolatency as it gets initialized before add_disk() is called.<br /> <br /> It is desirable to lazy-init rq_qos policies because they are optional<br /> features and add to hot path overhead once initialized - each IO has to walk<br /> all the registered rq_qos policies. So, we want to switch iolatency to lazy<br /> init too. However, that&amp;#39;s a bigger change. As a fix for the immediate<br /> problem, let&amp;#39;s just add an extra call to rq_qos_exit() in blkcg_exit_disk().<br /> This is safe because duplicate calls to rq_qos_exit() become noop&amp;#39;s.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix uninititialized value in &amp;#39;ext4_evict_inode&amp;#39;<br /> <br /> Syzbot found the following issue:<br /> =====================================================<br /> BUG: KMSAN: uninit-value in ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180<br /> ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180<br /> evict+0x365/0x9a0 fs/inode.c:664<br /> iput_final fs/inode.c:1747 [inline]<br /> iput+0x985/0xdd0 fs/inode.c:1773<br /> __ext4_new_inode+0xe54/0x7ec0 fs/ext4/ialloc.c:1361<br /> ext4_mknod+0x376/0x840 fs/ext4/namei.c:2844<br /> vfs_mknod+0x79d/0x830 fs/namei.c:3914<br /> do_mknodat+0x47d/0xaa0<br /> __do_sys_mknodat fs/namei.c:3992 [inline]<br /> __se_sys_mknodat fs/namei.c:3989 [inline]<br /> __ia32_sys_mknodat+0xeb/0x150 fs/namei.c:3989<br /> do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]<br /> __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178<br /> do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203<br /> do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246<br /> entry_SYSENTER_compat_after_hwframe+0x70/0x82<br /> <br /> Uninit was created at:<br /> __alloc_pages+0x9f1/0xe80 mm/page_alloc.c:5578<br /> alloc_pages+0xaae/0xd80 mm/mempolicy.c:2285<br /> alloc_slab_page mm/slub.c:1794 [inline]<br /> allocate_slab+0x1b5/0x1010 mm/slub.c:1939<br /> new_slab mm/slub.c:1992 [inline]<br /> ___slab_alloc+0x10c3/0x2d60 mm/slub.c:3180<br /> __slab_alloc mm/slub.c:3279 [inline]<br /> slab_alloc_node mm/slub.c:3364 [inline]<br /> slab_alloc mm/slub.c:3406 [inline]<br /> __kmem_cache_alloc_lru mm/slub.c:3413 [inline]<br /> kmem_cache_alloc_lru+0x6f3/0xb30 mm/slub.c:3429<br /> alloc_inode_sb include/linux/fs.h:3117 [inline]<br /> ext4_alloc_inode+0x5f/0x860 fs/ext4/super.c:1321<br /> alloc_inode+0x83/0x440 fs/inode.c:259<br /> new_inode_pseudo fs/inode.c:1018 [inline]<br /> new_inode+0x3b/0x430 fs/inode.c:1046<br /> __ext4_new_inode+0x2a7/0x7ec0 fs/ext4/ialloc.c:959<br /> ext4_mkdir+0x4d5/0x1560 fs/ext4/namei.c:2992<br /> vfs_mkdir+0x62a/0x870 fs/namei.c:4035<br /> do_mkdirat+0x466/0x7b0 fs/namei.c:4060<br /> __do_sys_mkdirat fs/namei.c:4075 [inline]<br /> __se_sys_mkdirat fs/namei.c:4073 [inline]<br /> __ia32_sys_mkdirat+0xc4/0x120 fs/namei.c:4073<br /> do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]<br /> __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178<br /> do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203<br /> do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246<br /> entry_SYSENTER_compat_after_hwframe+0x70/0x82<br /> <br /> CPU: 1 PID: 4625 Comm: syz-executor.2 Not tainted 6.1.0-rc4-syzkaller-62821-gcb231e2f67ec #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> =====================================================<br /> <br /> Now, &amp;#39;ext4_alloc_inode()&amp;#39; didn&amp;#39;t init &amp;#39;ei-&gt;i_flags&amp;#39;. If new inode failed<br /> before set &amp;#39;ei-&gt;i_flags&amp;#39; in &amp;#39;__ext4_new_inode()&amp;#39;, then do &amp;#39;iput()&amp;#39;. As after<br /> 6bc0d63dad7f commit will access &amp;#39;ei-&gt;i_flags&amp;#39; in &amp;#39;ext4_evict_inode()&amp;#39; which<br /> will lead to access uninit-value.<br /> To solve above issue just init &amp;#39;ei-&gt;i_flags&amp;#39; in &amp;#39;ext4_alloc_inode()&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: solo6x10: fix possible memory leak in solo_sysfs_init()<br /> <br /> If device_register() returns error in solo_sysfs_init(), the<br /> name allocated by dev_set_name() need be freed. As comment of<br /> device_register() says, it should use put_device() to give up<br /> the reference in the error path. So fix this by calling<br /> put_device(), then the name can be freed in kobject_cleanup().