Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libbpf: Fix memory leak in strset<br /> <br /> Free struct strset itself, not just its internal parts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: fix NULL deref in fifo_set_limit()<br /> <br /> syzbot reported another NULL deref in fifo_set_limit() [1]<br /> <br /> I could repro the issue with :<br /> <br /> unshare -n<br /> tc qd add dev lo root handle 1:0 tbf limit 200000 burst 70000 rate 100Mbit<br /> tc qd replace dev lo parent 1:0 pfifo_fast<br /> tc qd change dev lo root handle 1:0 tbf limit 300000 burst 70000 rate 100Mbit<br /> <br /> pfifo_fast does not have a change() operation.<br /> Make fifo_set_limit() more robust about this.<br /> <br /> [1]<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PGD 1cf99067 P4D 1cf99067 PUD 7ca49067 PMD 0<br /> Oops: 0010 [#1] PREEMPT SMP KASAN<br /> CPU: 1 PID: 14443 Comm: syz-executor959 Not tainted 5.15.0-rc3-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:0x0<br /> Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.<br /> RSP: 0018:ffffc9000e2f7310 EFLAGS: 00010246<br /> RAX: dffffc0000000000 RBX: ffffffff8d6ecc00 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffff888024c27910 RDI: ffff888071e34000<br /> RBP: ffff888071e34000 R08: 0000000000000001 R09: ffffffff8fcfb947<br /> R10: 0000000000000001 R11: 0000000000000000 R12: ffff888024c27910<br /> R13: ffff888071e34018 R14: 0000000000000000 R15: ffff88801ef74800<br /> FS: 00007f321d897700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffffffffd6 CR3: 00000000722c3000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> fifo_set_limit net/sched/sch_fifo.c:242 [inline]<br /> fifo_set_limit+0x198/0x210 net/sched/sch_fifo.c:227<br /> tbf_change+0x6ec/0x16d0 net/sched/sch_tbf.c:418<br /> qdisc_change net/sched/sch_api.c:1332 [inline]<br /> tc_modify_qdisc+0xd9a/0x1a60 net/sched/sch_api.c:1634<br /> rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5572<br /> netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]<br /> netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340<br /> netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929<br /> sock_sendmsg_nosec net/socket.c:704 [inline]<br /> sock_sendmsg+0xcf/0x120 net/socket.c:724<br /> ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409<br /> ___sys_sendmsg+0xf3/0x170 net/socket.c:2463<br /> __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_taprio: properly cancel timer from taprio_destroy()<br /> <br /> There is a comment in qdisc_create() about us not calling ops-&gt;reset()<br /> in some cases.<br /> <br /> err_out4:<br /> /*<br /> * Any broken qdiscs that would require a ops-&gt;reset() here?<br /> * The qdisc was never in action so it shouldn&amp;#39;t be necessary.<br /> */<br /> <br /> As taprio sets a timer before actually receiving a packet, we need<br /> to cancel it from ops-&gt;destroy, just in case ops-&gt;reset has not<br /> been called.<br /> <br /> syzbot reported:<br /> <br /> ODEBUG: free active (active state 0) object type: hrtimer hint: advance_sched+0x0/0x9a0 arch/x86/include/asm/atomic64_64.h:22<br /> WARNING: CPU: 0 PID: 8441 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505<br /> Modules linked in:<br /> CPU: 0 PID: 8441 Comm: syz-executor813 Not tainted 5.14.0-rc6-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505<br /> Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd e0 d3 e3 89 4c 89 ee 48 c7 c7 e0 c7 e3 89 e8 5b 86 11 05 0b 83 05 85 03 92 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3<br /> RSP: 0018:ffffc9000130f330 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000<br /> RDX: ffff88802baeb880 RSI: ffffffff815d87b5 RDI: fffff52000261e58<br /> RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffffffff815d25ee R11: 0000000000000000 R12: ffffffff898dd020<br /> R13: ffffffff89e3ce20 R14: ffffffff81653630 R15: dffffc0000000000<br /> FS: 0000000000f0d300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffb64b3e000 CR3: 0000000036557000 CR4: 00000000001506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> __debug_check_no_obj_freed lib/debugobjects.c:987 [inline]<br /> debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1018<br /> slab_free_hook mm/slub.c:1603 [inline]<br /> slab_free_freelist_hook+0x171/0x240 mm/slub.c:1653<br /> slab_free mm/slub.c:3213 [inline]<br /> kfree+0xe4/0x540 mm/slub.c:4267<br /> qdisc_create+0xbcf/0x1320 net/sched/sch_api.c:1299<br /> tc_modify_qdisc+0x4c8/0x1a60 net/sched/sch_api.c:1663<br /> rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571<br /> netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]<br /> netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340<br /> netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929<br /> sock_sendmsg_nosec net/socket.c:704 [inline]<br /> sock_sendmsg+0xcf/0x120 net/socket.c:724<br /> ____sys_sendmsg+0x6e8/0x810 net/socket.c:2403<br /> ___sys_sendmsg+0xf3/0x170 net/socket.c:2457<br /> __sys_sendmsg+0xe5/0x1b0 net/socket.c:2486<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: fix a potential ttm-&gt;sg memory leak<br /> <br /> Memory is allocated for ttm-&gt;sg by kmalloc in kfd_mem_dmamap_userptr,<br /> but isn&amp;#39;t freed by kfree in kfd_mem_dmaunmap_userptr. Free it!

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau/kms/nv50-: fix file release memory leak<br /> <br /> When using single_open() for opening, single_release() should be<br /> called, otherwise the &amp;#39;op&amp;#39; allocated in single_open() will be leaked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau/debugfs: fix file release memory leak<br /> <br /> When using single_open() for opening, single_release() should be<br /> called, otherwise the &amp;#39;op&amp;#39; allocated in single_open() will be leaked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix freeing of uninitialized misc IRQ vector<br /> <br /> When VSI set up failed in i40e_probe() as part of PF switch set up<br /> driver was trying to free misc IRQ vectors in<br /> i40e_clear_interrupt_scheme and produced a kernel Oops:<br /> <br /> Trying to free already-free IRQ 266<br /> WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300<br /> Workqueue: events work_for_cpu_fn<br /> RIP: 0010:__free_irq+0x9a/0x300<br /> Call Trace:<br /> ? synchronize_irq+0x3a/0xa0<br /> free_irq+0x2e/0x60<br /> i40e_clear_interrupt_scheme+0x53/0x190 [i40e]<br /> i40e_probe.part.108+0x134b/0x1a40 [i40e]<br /> ? kmem_cache_alloc+0x158/0x1c0<br /> ? acpi_ut_update_ref_count.part.1+0x8e/0x345<br /> ? acpi_ut_update_object_reference+0x15e/0x1e2<br /> ? strstr+0x21/0x70<br /> ? irq_get_irq_data+0xa/0x20<br /> ? mp_check_pin_attr+0x13/0xc0<br /> ? irq_get_irq_data+0xa/0x20<br /> ? mp_map_pin_to_irq+0xd3/0x2f0<br /> ? acpi_register_gsi_ioapic+0x93/0x170<br /> ? pci_conf1_read+0xa4/0x100<br /> ? pci_bus_read_config_word+0x49/0x70<br /> ? do_pci_enable_device+0xcc/0x100<br /> local_pci_probe+0x41/0x90<br /> work_for_cpu_fn+0x16/0x20<br /> process_one_work+0x1a7/0x360<br /> worker_thread+0x1cf/0x390<br /> ? create_worker+0x1a0/0x1a0<br /> kthread+0x112/0x130<br /> ? kthread_flush_work_fn+0x10/0x10<br /> ret_from_fork+0x1f/0x40<br /> <br /> The problem is that at that point misc IRQ vectors<br /> were not allocated yet and we get a call trace<br /> that driver is trying to free already free IRQ vectors.<br /> <br /> Add a check in i40e_clear_interrupt_scheme for __I40E_MISC_IRQ_REQUESTED<br /> PF state before calling i40e_free_misc_vector. This state is set only if<br /> misc IRQ vectors were properly initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: acpi: fix resource leak in reconfiguration device addition<br /> <br /> acpi_i2c_find_adapter_by_handle() calls bus_find_device() which takes a<br /> reference on the adapter which is never released which will result in a<br /> reference count leak and render the adapter unremovable. Make sure to<br /> put the adapter after creating the client in the same manner that we do<br /> for OF.<br /> <br /> [wsa: fixed title]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume<br /> <br /> In current code, when a PCI error state pci_channel_io_normal is detectd,<br /> it will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI<br /> driver will continue the execution of PCI resume callback report_resume by<br /> pci_walk_bridge, and the callback will go into amdgpu_pci_resume<br /> finally, where write lock is releasd unconditionally without acquiring<br /> such lock first. In this case, a deadlock will happen when other threads<br /> start to acquire the read lock.<br /> <br /> To fix this, add a member in amdgpu_device strucutre to cache<br /> pci_channel_state, and only continue the execution in amdgpu_pci_resume<br /> when it&amp;#39;s pci_channel_io_frozen.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: usbhid: free raw_report buffers in usbhid_stop<br /> <br /> Free the unsent raw_report buffers when the device is removed.<br /> <br /> Fixes a memory leak reported by syzbot at:<br /> https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: add error checking to ext4_ext_replay_set_iblocks()<br /> <br /> If the call to ext4_map_blocks() fails due to an corrupted file<br /> system, ext4_ext_replay_set_iblocks() can get stuck in an infinite<br /> loop. This could be reproduced by running generic/526 with a file<br /> system that has inline_data and fast_commit enabled. The system will<br /> repeatedly log to the console:<br /> <br /> EXT4-fs warning (device dm-3): ext4_block_to_path:105: block 1074800922 &gt; max in inode 131076<br /> <br /> and the stack that it gets stuck in is:<br /> <br /> ext4_block_to_path+0xe3/0x130<br /> ext4_ind_map_blocks+0x93/0x690<br /> ext4_map_blocks+0x100/0x660<br /> skip_hole+0x47/0x70<br /> ext4_ext_replay_set_iblocks+0x223/0x440<br /> ext4_fc_replay_inode+0x29e/0x3b0<br /> ext4_fc_replay+0x278/0x550<br /> do_one_pass+0x646/0xc10<br /> jbd2_journal_recover+0x14a/0x270<br /> jbd2_journal_load+0xc4/0x150<br /> ext4_load_journal+0x1f3/0x490<br /> ext4_fill_super+0x22d4/0x2c00<br /> <br /> With this patch, generic/526 still fails, but system is no longer<br /> locking up in a tight loop. It&amp;#39;s likely the root casue is that<br /> fast_commit replay is corrupting file systems with inline_data, and we<br /> probably need to add better error handling in the fast commit replay<br /> code path beyond what is done here, which essentially just breaks the<br /> infinite loop without reporting the to the higher levels of the code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Handle SRCU initialization failure during page track init<br /> <br /> Check the return of init_srcu_struct(), which can fail due to OOM, when<br /> initializing the page track mechanism. Lack of checking leads to a NULL<br /> pointer deref found by a modified syzkaller.<br /> <br /> [Move the call towards the beginning of kvm_arch_init_vm. - Paolo]