Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ipset: Hold module reference while requesting a module<br /> <br /> User space may unload ip_set.ko while it is itself requesting a set type<br /> backend module, leading to a kernel crash. The race condition may be<br /> provoked by inserting an mdelay() right after the nfnl_unlock() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_inner: incorrect percpu area handling under softirq<br /> <br /> Softirq can interrupt ongoing packet from process context that is<br /> walking over the percpu area that contains inner header offsets.<br /> <br /> Disable bh and perform three checks before restoring the percpu inner<br /> header offsets to validate that the percpu area is valid for this<br /> skbuff:<br /> <br /> 1) If the NFT_PKTINFO_INNER_FULL flag is set on, then this skbuff<br /> has already been parsed before for inner header fetching to<br /> register.<br /> <br /> 2) Validate that the percpu area refers to this skbuff using the<br /> skbuff pointer as a cookie. If there is a cookie mismatch, then<br /> this skbuff needs to be parsed again.<br /> <br /> 3) Finally, validate if the percpu area refers to this tunnel type.<br /> <br /> Only after these three checks the percpu area is restored to a on-stack<br /> copy and bh is enabled again.<br /> <br /> After inner header fetching, the on-stack copy is stored back to the<br /> percpu area.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hsr: must allocate more bytes for RedBox support<br /> <br /> Blamed commit forgot to change hsr_init_skb() to allocate<br /> larger skb for RedBox case.<br /> <br /> Indeed, send_hsr_supervision_frame() will add<br /> two additional components (struct hsr_sup_tlv<br /> and struct hsr_sup_payload)<br /> <br /> syzbot reported the following crash:<br /> skbuff: skb_over_panic: text:ffffffff8afd4b0a len:34 put:6 head:ffff88802ad29e00 data:ffff88802ad29f22 tail:0x144 end:0x140 dev:gretap0<br /> ------------[ cut here ]------------<br /> kernel BUG at net/core/skbuff.c:206 !<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 2 UID: 0 PID: 7611 Comm: syz-executor Not tainted 6.12.0-syzkaller #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:skb_panic+0x157/0x1d0 net/core/skbuff.c:206<br /> Code: b6 04 01 84 c0 74 04 3c 03 7e 21 8b 4b 70 41 56 45 89 e8 48 c7 c7 a0 7d 9b 8c 41 57 56 48 89 ee 52 4c 89 e2 e8 9a 76 79 f8 90 0b 4c 89 4c 24 10 48 89 54 24 08 48 89 34 24 e8 94 76 fb f8 4c<br /> RSP: 0018:ffffc90000858ab8 EFLAGS: 00010282<br /> RAX: 0000000000000087 RBX: ffff8880598c08c0 RCX: ffffffff816d3e69<br /> RDX: 0000000000000000 RSI: ffffffff816de786 RDI: 0000000000000005<br /> RBP: ffffffff8c9b91c0 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 0000000000000302 R11: ffffffff961cc1d0 R12: ffffffff8afd4b0a<br /> R13: 0000000000000006 R14: ffff88804b938130 R15: 0000000000000140<br /> FS: 000055558a3d6500(0000) GS:ffff88806a800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f1295974ff8 CR3: 000000002ab6e000 CR4: 0000000000352ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> skb_over_panic net/core/skbuff.c:211 [inline]<br /> skb_put+0x174/0x1b0 net/core/skbuff.c:2617<br /> send_hsr_supervision_frame+0x6fa/0x9e0 net/hsr/hsr_device.c:342<br /> hsr_proxy_announce+0x1a3/0x4a0 net/hsr/hsr_device.c:436<br /> call_timer_fn+0x1a0/0x610 kernel/time/timer.c:1794<br /> expire_timers kernel/time/timer.c:1845 [inline]<br /> __run_timers+0x6e8/0x930 kernel/time/timer.c:2419<br /> __run_timer_base kernel/time/timer.c:2430 [inline]<br /> __run_timer_base kernel/time/timer.c:2423 [inline]<br /> run_timer_base+0x111/0x190 kernel/time/timer.c:2439<br /> run_timer_softirq+0x1a/0x40 kernel/time/timer.c:2449<br /> handle_softirqs+0x213/0x8f0 kernel/softirq.c:554<br /> __do_softirq kernel/softirq.c:588 [inline]<br /> invoke_softirq kernel/softirq.c:428 [inline]<br /> __irq_exit_rcu kernel/softirq.c:637 [inline]<br /> irq_exit_rcu+0xbb/0x120 kernel/softirq.c:649<br /> instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]<br /> sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix LGR and link use-after-free issue<br /> <br /> We encountered a LGR/link use-after-free issue, which manifested as<br /> the LGR/link refcnt reaching 0 early and entering the clear process,<br /> making resource access unsafe.<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140<br /> Workqueue: events smc_lgr_terminate_work [smc]<br /> Call trace:<br /> refcount_warn_saturate+0x9c/0x140<br /> __smc_lgr_terminate.part.45+0x2a8/0x370 [smc]<br /> smc_lgr_terminate_work+0x28/0x30 [smc]<br /> process_one_work+0x1b8/0x420<br /> worker_thread+0x158/0x510<br /> kthread+0x114/0x118<br /> <br /> or<br /> <br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140<br /> Workqueue: smc_hs_wq smc_listen_work [smc]<br /> Call trace:<br /> refcount_warn_saturate+0xf0/0x140<br /> smcr_link_put+0x1cc/0x1d8 [smc]<br /> smc_conn_free+0x110/0x1b0 [smc]<br /> smc_conn_abort+0x50/0x60 [smc]<br /> smc_listen_find_device+0x75c/0x790 [smc]<br /> smc_listen_work+0x368/0x8a0 [smc]<br /> process_one_work+0x1b8/0x420<br /> worker_thread+0x158/0x510<br /> kthread+0x114/0x118<br /> <br /> It is caused by repeated release of LGR/link refcnt. One suspect is that<br /> smc_conn_free() is called repeatedly because some smc_conn_free() from<br /> server listening path are not protected by sock lock.<br /> <br /> e.g.<br /> <br /> Calls under socklock | smc_listen_work<br /> -------------------------------------------------------<br /> lock_sock(sk) | smc_conn_abort<br /> smc_conn_free | \- smc_conn_free<br /> \- smcr_link_put | \- smcr_link_put (duplicated)<br /> release_sock(sk)<br /> <br /> So here add sock lock protection in smc_listen_work() path, making it<br /> exclusive with other connection operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: initialize close_work early to avoid warning<br /> <br /> We encountered a warning that close_work was canceled before<br /> initialization.<br /> <br /> WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0<br /> Workqueue: events smc_lgr_terminate_work [smc]<br /> RIP: 0010:__flush_work+0x19e/0x1b0<br /> Call Trace:<br /> ? __wake_up_common+0x7a/0x190<br /> ? work_busy+0x80/0x80<br /> __cancel_work_timer+0xe3/0x160<br /> smc_close_cancel_work+0x1a/0x70 [smc]<br /> smc_close_active_abort+0x207/0x360 [smc]<br /> __smc_lgr_terminate.part.38+0xc8/0x180 [smc]<br /> process_one_work+0x19e/0x340<br /> worker_thread+0x30/0x370<br /> ? process_one_work+0x340/0x340<br /> kthread+0x117/0x130<br /> ? __kthread_cancel_work+0x50/0x50<br /> ret_from_fork+0x22/0x30<br /> <br /> This is because when smc_close_cancel_work is triggered, e.g. the RDMA<br /> driver is rmmod and the LGR is terminated, the conn-&gt;close_work is<br /> flushed before initialization, resulting in WARN_ON(!work-&gt;func).<br /> <br /> __smc_lgr_terminate | smc_connect_{rdma|ism}<br /> -------------------------------------------------------------<br /> | smc_conn_create<br /> | \- smc_lgr_register_conn<br /> for conn in lgr-&gt;conns_all |<br /> \- smc_conn_kill |<br /> \- smc_close_active_abort |<br /> \- smc_close_cancel_work |<br /> \- cancel_work_sync |<br /> \- __flush_work |<br /> (close_work) |<br /> | smc_close_init<br /> | \- INIT_WORK(&amp;close_work)<br /> <br /> So fix this by initializing close_work before establishing the<br /> connection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: Fix use-after-free of kernel socket in cleanup_bearer().<br /> <br /> syzkaller reported a use-after-free of UDP kernel socket<br /> in cleanup_bearer() without repro. [0][1]<br /> <br /> When bearer_disable() calls tipc_udp_disable(), cleanup<br /> of the UDP kernel socket is deferred by work calling<br /> cleanup_bearer().<br /> <br /> tipc_exit_net() waits for such works to finish by checking<br /> tipc_net(net)-&gt;wq_count. However, the work decrements the<br /> count too early before releasing the kernel socket,<br /> unblocking cleanup_net() and resulting in use-after-free.<br /> <br /> Let&amp;#39;s move the decrement after releasing the socket in<br /> cleanup_bearer().<br /> <br /> [0]:<br /> ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at<br /> sk_alloc+0x438/0x608<br /> inet_create+0x4c8/0xcb0<br /> __sock_create+0x350/0x6b8<br /> sock_create_kern+0x58/0x78<br /> udp_sock_create4+0x68/0x398<br /> udp_sock_create+0x88/0xc8<br /> tipc_udp_enable+0x5e8/0x848<br /> __tipc_nl_bearer_enable+0x84c/0xed8<br /> tipc_nl_bearer_enable+0x38/0x60<br /> genl_family_rcv_msg_doit+0x170/0x248<br /> genl_rcv_msg+0x400/0x5b0<br /> netlink_rcv_skb+0x1dc/0x398<br /> genl_rcv+0x44/0x68<br /> netlink_unicast+0x678/0x8b0<br /> netlink_sendmsg+0x5e4/0x898<br /> ____sys_sendmsg+0x500/0x830<br /> <br /> [1]:<br /> BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]<br /> BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979<br /> udp_hashslot include/net/udp.h:85 [inline]<br /> udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979<br /> sk_common_release+0xaf/0x3f0 net/core/sock.c:3820<br /> inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437<br /> inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489<br /> __sock_release net/socket.c:658 [inline]<br /> sock_release+0xa0/0x210 net/socket.c:686<br /> cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310<br /> worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391<br /> kthread+0x531/0x6b0 kernel/kthread.c:389<br /> ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244<br /> <br /> Uninit was created at:<br /> slab_free_hook mm/slub.c:2269 [inline]<br /> slab_free mm/slub.c:4580 [inline]<br /> kmem_cache_free+0x207/0xc40 mm/slub.c:4682<br /> net_free net/core/net_namespace.c:454 [inline]<br /> cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310<br /> worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391<br /> kthread+0x531/0x6b0 kernel/kthread.c:389<br /> ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244<br /> <br /> CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> Workqueue: events cleanup_bearer

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: dev: can_set_termination(): allow sleeping GPIOs<br /> <br /> In commit 6e86a1543c37 ("can: dev: provide optional GPIO based<br /> termination support") GPIO based termination support was added.<br /> <br /> For no particular reason that patch uses gpiod_set_value() to set the<br /> GPIO. This leads to the following warning, if the systems uses a<br /> sleeping GPIO, i.e. behind an I2C port expander:<br /> <br /> | WARNING: CPU: 0 PID: 379 at /drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x50/0x6c<br /> | CPU: 0 UID: 0 PID: 379 Comm: ip Not tainted 6.11.0-20241016-1 #1 823affae360cc91126e4d316d7a614a8bf86236c<br /> <br /> Replace gpiod_set_value() by gpiod_set_value_cansleep() to allow the<br /> use of sleeping GPIOs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_write<br /> <br /> An offset from client could be a negative value, It could allows<br /> to write data outside the bounds of the allocated buffer.<br /> Note that this issue is coming when setting<br /> &amp;#39;vfs objects = streams_xattr parameter&amp;#39; in ksmbd.conf.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix Out-of-Bounds Read in ksmbd_vfs_stream_read<br /> <br /> An offset from client could be a negative value, It could lead<br /> to an out-of-bounds read from the stream_buf.<br /> Note that this issue is coming when setting<br /> &amp;#39;vfs objects = streams_xattr parameter&amp;#39; in ksmbd.conf.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Add architecture specific huge_pte_clear()<br /> <br /> When executing mm selftests run_vmtests.sh, there is such an error:<br /> <br /> BUG: Bad page state in process uffd-unit-tests pfn:00000<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0<br /> flags: 0xffff0000002000(reserved|node=0|zone=0|lastcpupid=0xffff)<br /> raw: 00ffff0000002000 ffffbf0000000008 ffffbf0000000008 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set<br /> Modules linked in: snd_seq_dummy snd_seq snd_seq_device rfkill vfat fat<br /> virtio_balloon efi_pstore virtio_net pstore net_failover failover fuse<br /> nfnetlink virtio_scsi virtio_gpu virtio_dma_buf dm_multipath efivarfs<br /> CPU: 2 UID: 0 PID: 1913 Comm: uffd-unit-tests Not tainted 6.12.0 #184<br /> Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022<br /> Stack : 900000047c8ac000 0000000000000000 9000000000223a7c 900000047c8ac000<br /> 900000047c8af690 900000047c8af698 0000000000000000 900000047c8af7d8<br /> 900000047c8af7d0 900000047c8af7d0 900000047c8af5b0 0000000000000001<br /> 0000000000000001 900000047c8af698 10b3c7d53da40d26 0000010000000000<br /> 0000000000000022 0000000fffffffff fffffffffe000000 ffff800000000000<br /> 000000000000002f 0000800000000000 000000017a6d4000 90000000028f8940<br /> 0000000000000000 0000000000000000 90000000025aa5e0 9000000002905000<br /> 0000000000000000 90000000028f8940 ffff800000000000 0000000000000000<br /> 0000000000000000 0000000000000000 9000000000223a94 000000012001839c<br /> 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d<br /> ...<br /> Call Trace:<br /> [] show_stack+0x5c/0x180<br /> [] dump_stack_lvl+0x6c/0xa0<br /> [] bad_page+0x1a0/0x1f0<br /> [] free_unref_folios+0xbf0/0xd20<br /> [] folios_put_refs+0x1a4/0x2b8<br /> [] free_pages_and_swap_cache+0x164/0x260<br /> [] tlb_batch_pages_flush+0xa8/0x1c0<br /> [] tlb_finish_mmu+0xa8/0x218<br /> [] exit_mmap+0x1a0/0x360<br /> [] __mmput+0x78/0x200<br /> [] do_exit+0x43c/0xde8<br /> [] do_group_exit+0x68/0x110<br /> [] sys_exit_group+0x1c/0x20<br /> [] do_syscall+0x94/0x130<br /> [] handle_syscall+0xb8/0x158<br /> Disabling lock debugging due to kernel taint<br /> BUG: non-zero pgtables_bytes on freeing mm: -16384<br /> <br /> On LoongArch system, invalid huge pte entry should be invalid_pte_table<br /> or a single _PAGE_HUGE bit rather than a zero value. And it should be<br /> the same with invalid pmd entry, since pmd_none() is called by function<br /> free_pgd_range() and pmd_none() return 0 by huge_pte_clear(). So single<br /> _PAGE_HUGE bit is also treated as a valid pte table and free_pte_range()<br /> will be called in free_pmd_range().<br /> <br /> free_pmd_range()<br /> pmd = pmd_offset(pud, addr);<br /> do {<br /> next = pmd_addr_end(addr, end);<br /> if (pmd_none_or_clear_bad(pmd))<br /> continue;<br /> free_pte_range(tlb, pmd, addr);<br /> } while (pmd++, addr = next, addr != end);<br /> <br /> Here invalid_pte_table is used for both invalid huge pte entry and<br /> pmd entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: wacom: fix when get product name maybe null pointer<br /> <br /> Due to incorrect dev-&gt;product reporting by certain devices, null<br /> pointer dereferences occur when dev-&gt;product is empty, leading to<br /> potential system crashes.<br /> <br /> This issue was found on EXCELSIOR DL37-D05 device with<br /> Loongson-LS3A6000-7A2000-DL37 motherboard.<br /> <br /> Kernel logs:<br /> [ 56.470885] usb 4-3: new full-speed USB device number 4 using ohci-pci<br /> [ 56.671638] usb 4-3: string descriptor 0 read error: -22<br /> [ 56.671644] usb 4-3: New USB device found, idVendor=056a, idProduct=0374, bcdDevice= 1.07<br /> [ 56.671647] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3<br /> [ 56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: USB HID v1.10 Device [HID 056a:0374] on usb-0000:00:05.0-3/input0<br /> [ 56.697719] CPU 2 Unable to handle kernel paging request at virtual address 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80<br /> [ 56.697732] Oops[#1]:<br /> [ 56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G OE 6.6.0-loong64-desktop #25.00.2000.015<br /> [ 56.697737] Hardware name: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 10/11/2024<br /> [ 56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0<br /> [ 56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000<br /> [ 56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000<br /> [ 56.697745] t0 ffff800004818b2d t1 0000000000000000 t2 0000000000000003 t3 0000000000000005<br /> [ 56.697747] t4 0000000000000000 t5 0000000000000000 t6 0000000000000000 t7 0000000000000000<br /> [ 56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028<br /> [ 56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000<br /> [ 56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000<br /> [ 56.697753] ra: ffff800004f98a80 wacom_update_name+0xe0/0x300 [wacom]<br /> [ 56.697802] ERA: 90000000066e35c8 strstr+0x28/0x120<br /> [ 56.697806] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)<br /> [ 56.697816] PRMD: 0000000c (PPLV0 +PIE +PWE)<br /> [ 56.697821] EUEN: 00000000 (-FPE -SXE -ASXE -BTE)<br /> [ 56.697827] ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)<br /> [ 56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)<br /> [ 56.697835] BADV: 0000000000000000<br /> [ 56.697836] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000)<br /> [ 56.697838] Modules linked in: wacom(+) bnep bluetooth rfkill qrtr nls_iso8859_1 nls_cp437 snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore input_leds mousedev led_class joydev deepin_netmonitor(OE) fuse nfnetlink dmi_sysfs ip_tables x_tables overlay amdgpu amdxcp drm_exec gpu_sched drm_buddy radeon drm_suballoc_helper i2c_algo_bit drm_ttm_helper r8169 ttm drm_display_helper spi_loongson_pci xhci_pci cec xhci_pci_renesas spi_loongson_core hid_generic realtek gpio_loongson_64bit<br /> [ 56.697887] Process (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3)<br /> [ 56.697890] Stack : 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000<br /> [ 56.697896] 0000000000000000 00000011fffffffd 0000000000000000 0000000000000000<br /> [ 56.697901] 0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0<br /> [ 56.697906] 90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c<br /> [ 56.697911] 90000001000ba000 ffff800004f9ce58 0000000000000000 ffff800005470440<br /> [ 56.697916] ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0<br /> [ 56.697921] 0000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c<br /> [ 56.697926] ffff8000054704e8 90000001000bb8b8 90000001000ba000 0000000000000000<br /> [ 56.697931] 90000001000bb8d0 <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: free inode when ocfs2_get_init_inode() fails<br /> <br /> syzbot is reporting busy inodes after unmount, for commit 9c89fe0af826<br /> ("ocfs2: Handle error from dquot_initialize()") forgot to call iput() when<br /> new_inode() succeeded and dquot_initialize() failed.