Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> audit: fix possible soft lockup in __audit_inode_child()<br /> <br /> Tracefs or debugfs maybe cause hundreds to thousands of PATH records,<br /> too many PATH records maybe cause soft lockup.<br /> <br /> For example:<br /> 1. CONFIG_KASAN=y &amp;&amp; CONFIG_PREEMPTION=n<br /> 2. auditctl -a exit,always -S open -k key<br /> 3. sysctl -w kernel.watchdog_thresh=5<br /> 4. mkdir /sys/kernel/debug/tracing/instances/test<br /> <br /> There may be a soft lockup as follows:<br /> watchdog: BUG: soft lockup - CPU#45 stuck for 7s! [mkdir:15498]<br /> Kernel panic - not syncing: softlockup: hung tasks<br /> Call trace:<br /> dump_backtrace+0x0/0x30c<br /> show_stack+0x20/0x30<br /> dump_stack+0x11c/0x174<br /> panic+0x27c/0x494<br /> watchdog_timer_fn+0x2bc/0x390<br /> __run_hrtimer+0x148/0x4fc<br /> __hrtimer_run_queues+0x154/0x210<br /> hrtimer_interrupt+0x2c4/0x760<br /> arch_timer_handler_phys+0x48/0x60<br /> handle_percpu_devid_irq+0xe0/0x340<br /> __handle_domain_irq+0xbc/0x130<br /> gic_handle_irq+0x78/0x460<br /> el1_irq+0xb8/0x140<br /> __audit_inode_child+0x240/0x7bc<br /> tracefs_create_file+0x1b8/0x2a0<br /> trace_create_file+0x18/0x50<br /> event_create_dir+0x204/0x30c<br /> __trace_add_new_event+0xac/0x100<br /> event_trace_add_tracer+0xa0/0x130<br /> trace_array_create_dir+0x60/0x140<br /> trace_array_create+0x1e0/0x370<br /> instance_mkdir+0x90/0xd0<br /> tracefs_syscall_mkdir+0x68/0xa0<br /> vfs_mkdir+0x21c/0x34c<br /> do_mkdirat+0x1b4/0x1d4<br /> __arm64_sys_mkdirat+0x4c/0x60<br /> el0_svc_common.constprop.0+0xa8/0x240<br /> do_el0_svc+0x8c/0xc0<br /> el0_svc+0x20/0x30<br /> el0_sync_handler+0xb0/0xb4<br /> el0_sync+0x160/0x180<br /> <br /> Therefore, we add cond_resched() to __audit_inode_child() to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: essiv - Handle EBUSY correctly<br /> <br /> As it is essiv only handles the special return value of EINPROGERSS,<br /> which means that in all other cases it will free data related to the<br /> request.<br /> <br /> However, as the caller of essiv may specify MAY_BACKLOG, we also need<br /> to expect EBUSY and treat it in the same way. Otherwise backlogged<br /> requests will trigger a use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/rockchip: dw_hdmi: cleanup drm encoder during unbind<br /> <br /> This fixes a use-after-free crash during rmmod.<br /> <br /> The DRM encoder is embedded inside the larger rockchip_hdmi,<br /> which is allocated with the component. The component memory<br /> gets freed before the main drm device is destroyed. Fix it<br /> by running encoder cleanup before tearing down its container.<br /> <br /> [moved encoder cleanup above clk_disable, similar to bind-error-path]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/bnxt_re: Prevent handling any completions after qp destroy<br /> <br /> HW may generate completions that indicates QP is destroyed.<br /> Driver should not be scheduling any more completion handlers<br /> for this QP, after the QP is destroyed. Since CQs are active<br /> during the QP destroy, driver may still schedule completion<br /> handlers. This can cause a race where the destroy_cq and poll_cq<br /> running simultaneously.<br /> <br /> Snippet of kernel panic while doing bnxt_re driver load unload in loop.<br /> This indicates a poll after the CQ is freed. <br /> <br /> [77786.481636] Call Trace:<br /> [77786.481640]  <br /> [77786.481644]  bnxt_re_poll_cq+0x14a/0x620 [bnxt_re]<br /> [77786.481658]  ? kvm_clock_read+0x14/0x30<br /> [77786.481693]  __ib_process_cq+0x57/0x190 [ib_core]<br /> [77786.481728]  ib_cq_poll_work+0x26/0x80 [ib_core]<br /> [77786.481761]  process_one_work+0x1e5/0x3f0<br /> [77786.481768]  worker_thread+0x50/0x3a0<br /> [77786.481785]  ? __pfx_worker_thread+0x10/0x10<br /> [77786.481790]  kthread+0xe2/0x110<br /> [77786.481794]  ? __pfx_kthread+0x10/0x10<br /> [77786.481797]  ret_from_fork+0x2c/0x50<br /> <br /> To avoid this, complete all completion handlers before returning the<br /> destroy QP. If free_cq is called soon after destroy_qp, IB stack<br /> will cancel the CQ work before invoking the destroy_cq verb and<br /> this will prevent any race mentioned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rpmsg: glink: Add check for kstrdup<br /> <br /> Add check for the return value of kstrdup() and return the error<br /> if it fails in order to avoid NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: Fix memleak when insert_old_idx() failed<br /> <br /> Following process will cause a memleak for copied up znode:<br /> <br /> dirty_cow_znode<br /> zn = copy_znode(c, znode);<br /> err = insert_old_idx(c, zbr-&gt;lnum, zbr-&gt;offs);<br /> if (unlikely(err))<br /> return ERR_PTR(err); // No one refers to zn.<br /> <br /> Fetch a reproducer in [Link].<br /> <br /> Function copy_znode() is split into 2 parts: resource allocation<br /> and znode replacement, insert_old_idx() is split in similar way,<br /> so resource cleanup could be done in error handling path without<br /> corrupting metadata(mem &amp; disk).<br /> It&amp;#39;s okay that old index inserting is put behind of add_idx_dirt(),<br /> old index is used in layout_leb_in_gaps(), so the two processes do<br /> not depend on each other.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: do not allow gso_size to be set to GSO_BY_FRAGS<br /> <br /> One missing check in virtio_net_hdr_to_skb() allowed<br /> syzbot to crash kernels again [1]<br /> <br /> Do not allow gso_size to be set to GSO_BY_FRAGS (0xffff),<br /> because this magic value is used by the kernel.<br /> <br /> [1]<br /> general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]<br /> CPU: 0 PID: 5039 Comm: syz-executor401 Not tainted 6.5.0-rc5-next-20230809-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023<br /> RIP: 0010:skb_segment+0x1a52/0x3ef0 net/core/skbuff.c:4500<br /> Code: 00 00 00 e9 ab eb ff ff e8 6b 96 5d f9 48 8b 84 24 00 01 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 b6 04 02 84 c0 74 08 3c 03 0f 8e ea 21 00 00 48 8b 84 24 00 01<br /> RSP: 0018:ffffc90003d3f1c8 EFLAGS: 00010202<br /> RAX: dffffc0000000000 RBX: 000000000001fffe RCX: 0000000000000000<br /> RDX: 000000000000000e RSI: ffffffff882a3115 RDI: 0000000000000070<br /> RBP: ffffc90003d3f378 R08: 0000000000000005 R09: 000000000000ffff<br /> R10: 000000000000ffff R11: 5ee4a93e456187d6 R12: 000000000001ffc6<br /> R13: dffffc0000000000 R14: 0000000000000008 R15: 000000000000ffff<br /> FS: 00005555563f2380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020020000 CR3: 000000001626d000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> udp6_ufo_fragment+0x9d2/0xd50 net/ipv6/udp_offload.c:109<br /> ipv6_gso_segment+0x5c4/0x17b0 net/ipv6/ip6_offload.c:120<br /> skb_mac_gso_segment+0x292/0x610 net/core/gso.c:53<br /> __skb_gso_segment+0x339/0x710 net/core/gso.c:124<br /> skb_gso_segment include/net/gso.h:83 [inline]<br /> validate_xmit_skb+0x3a5/0xf10 net/core/dev.c:3625<br /> __dev_queue_xmit+0x8f0/0x3d60 net/core/dev.c:4329<br /> dev_queue_xmit include/linux/netdevice.h:3082 [inline]<br /> packet_xmit+0x257/0x380 net/packet/af_packet.c:276<br /> packet_snd net/packet/af_packet.c:3087 [inline]<br /> packet_sendmsg+0x24c7/0x5570 net/packet/af_packet.c:3119<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> sock_sendmsg+0xd9/0x180 net/socket.c:750<br /> ____sys_sendmsg+0x6ac/0x940 net/socket.c:2496<br /> ___sys_sendmsg+0x135/0x1d0 net/socket.c:2550<br /> __sys_sendmsg+0x117/0x1e0 net/socket.c:2579<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7ff27cdb34d9

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921: fix skb leak by txs missing in AMSDU<br /> <br /> txs may be dropped if the frame is aggregated in AMSDU. When the problem<br /> shows up, some SKBs would be hold in driver to cause network stopped<br /> temporarily. Even if the problem can be recovered by txs timeout handling,<br /> mt7921 still need to disable txs in AMSDU to avoid this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: pcie: fix possible NULL pointer dereference<br /> <br /> It is possible that iwl_pci_probe() will fail and free the trans,<br /> then afterwards iwl_pci_remove() will be called and crash by trying<br /> to access trans which is already freed, fix it.<br /> <br /> iwlwifi 0000:01:00.0: Detected crf-id 0xa5a5a5a2, cnv-id 0xa5a5a5a2<br /> wfpm id 0xa5a5a5a2<br /> iwlwifi 0000:01:00.0: Can&amp;#39;t find a correct rfid for crf id 0x5a2<br /> ...<br /> BUG: kernel NULL pointer dereference, address: 0000000000000028<br /> ...<br /> RIP: 0010:iwl_pci_remove+0x12/0x30 [iwlwifi]<br /> pci_device_remove+0x3e/0xb0<br /> device_release_driver_internal+0x103/0x1f0<br /> driver_detach+0x4c/0x90<br /> bus_remove_driver+0x5c/0xd0<br /> driver_unregister+0x31/0x50<br /> pci_unregister_driver+0x40/0x90<br /> iwl_pci_unregister_driver+0x15/0x20 [iwlwifi]<br /> __exit_compat+0x9/0x98 [iwlwifi]<br /> __x64_sys_delete_module+0x147/0x260

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix bug_on in __es_tree_search caused by bad quota inode<br /> <br /> We got a issue as fllows:<br /> ==================================================================<br /> kernel BUG at fs/ext4/extents_status.c:202!<br /> invalid opcode: 0000 [#1] PREEMPT SMP<br /> CPU: 1 PID: 810 Comm: mount Not tainted 6.1.0-rc1-next-g9631525255e3 #352<br /> RIP: 0010:__es_tree_search.isra.0+0xb8/0xe0<br /> RSP: 0018:ffffc90001227900 EFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: 0000000077512a0f RCX: 0000000000000000<br /> RDX: 0000000000000002 RSI: 0000000000002a10 RDI: ffff8881004cd0c8<br /> RBP: ffff888177512ac8 R08: 47ffffffffffffff R09: 0000000000000001<br /> R10: 0000000000000001 R11: 00000000000679af R12: 0000000000002a10<br /> R13: ffff888177512d88 R14: 0000000077512a10 R15: 0000000000000000<br /> FS: 00007f4bd76dbc40(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005653bf993cf8 CR3: 000000017bfdf000 CR4: 00000000000006e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ext4_es_cache_extent+0xe2/0x210<br /> ext4_cache_extents+0xd2/0x110<br /> ext4_find_extent+0x5d5/0x8c0<br /> ext4_ext_map_blocks+0x9c/0x1d30<br /> ext4_map_blocks+0x431/0xa50<br /> ext4_getblk+0x82/0x340<br /> ext4_bread+0x14/0x110<br /> ext4_quota_read+0xf0/0x180<br /> v2_read_header+0x24/0x90<br /> v2_check_quota_file+0x2f/0xa0<br /> dquot_load_quota_sb+0x26c/0x760<br /> dquot_load_quota_inode+0xa5/0x190<br /> ext4_enable_quotas+0x14c/0x300<br /> __ext4_fill_super+0x31cc/0x32c0<br /> ext4_fill_super+0x115/0x2d0<br /> get_tree_bdev+0x1d2/0x360<br /> ext4_get_tree+0x19/0x30<br /> vfs_get_tree+0x26/0xe0<br /> path_mount+0x81d/0xfc0<br /> do_mount+0x8d/0xc0<br /> __x64_sys_mount+0xc0/0x160<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> ==================================================================<br /> <br /> Above issue may happen as follows:<br /> -------------------------------------<br /> ext4_fill_super<br /> ext4_orphan_cleanup<br /> ext4_enable_quotas<br /> ext4_quota_enable<br /> ext4_iget --&gt; get error inode <br /> ext4_ext_check_inode --&gt; Wrong imode makes it escape inspection<br /> make_bad_inode(inode) --&gt; EXT4_BOOT_LOADER_INO set imode<br /> dquot_load_quota_inode<br /> vfs_setup_quota_inode --&gt; check pass<br /> dquot_load_quota_sb<br /> v2_check_quota_file<br /> v2_read_header<br /> ext4_quota_read<br /> ext4_bread<br /> ext4_getblk<br /> ext4_map_blocks<br /> ext4_ext_map_blocks<br /> ext4_find_extent<br /> ext4_cache_extents<br /> ext4_es_cache_extent<br /> __es_tree_search.isra.0<br /> ext4_es_end --&gt; Wrong extents trigger BUG_ON<br /> <br /> In the above issue, s_usr_quota_inum is set to 5, but inode contains<br /> incorrect imode and disordered extents. Because 5 is EXT4_BOOT_LOADER_INO,<br /> the ext4_ext_check_inode check in the ext4_iget function can be bypassed,<br /> finally, the extents that are not checked trigger the BUG_ON in the<br /> __es_tree_search function. To solve this issue, check whether the inode is<br /> bad_inode in vfs_setup_quota_inode().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: use proper req destructor for IPv6<br /> <br /> Before, only the destructor from TCP request sock in IPv4 was called<br /> even if the subflow was IPv6.<br /> <br /> It is important to use the right destructor to avoid memory leaks with<br /> some advanced IPv6 features, e.g. when the request socks contain<br /> specific IPv6 options.

Missing Authorization vulnerability in bnayawpguy Resoto allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Resoto: from n/a through 1.0.8.