Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pstore/ram: 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 /> leds: led-core: Fix refcount leak in of_led_get()<br /> <br /> class_find_device_by_of_node() calls class_find_device(), it will take<br /> the reference, use the put_device() to drop the reference when not need<br /> anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/hyperv: Disable IBT when hypercall page lacks ENDBR instruction<br /> <br /> On hardware that supports Indirect Branch Tracking (IBT), Hyper-V VMs<br /> with ConfigVersion 9.3 or later support IBT in the guest. However,<br /> current versions of Hyper-V have a bug in that there&amp;#39;s not an ENDBR64<br /> instruction at the beginning of the hypercall page. Since hypercalls are<br /> made with an indirect call to the hypercall page, all hypercall attempts<br /> fail with an exception and Linux panics.<br /> <br /> A Hyper-V fix is in progress to add ENDBR64. But guard against the Linux<br /> panic by clearing X86_FEATURE_IBT if the hypercall page doesn&amp;#39;t start<br /> with ENDBR. The VM will boot and run without IBT.<br /> <br /> If future Linux 32-bit kernels were to support IBT, additional hypercall<br /> page hackery would be needed to make IBT work for such kernels in a<br /> Hyper-V VM.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Disable preemption in bpf_event_output<br /> <br /> We received report [1] of kernel crash, which is caused by<br /> using nesting protection without disabled preemption.<br /> <br /> The bpf_event_output can be called by programs executed by<br /> bpf_prog_run_array_cg function that disabled migration but<br /> keeps preemption enabled.<br /> <br /> This can cause task to be preempted by another one inside the<br /> nesting protection and lead eventually to two tasks using same<br /> perf_sample_data buffer and cause crashes like:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000001<br /> #PF: supervisor instruction fetch in kernel mode<br /> #PF: error_code(0x0010) - not-present page<br /> ...<br /> ? perf_output_sample+0x12a/0x9a0<br /> ? finish_task_switch.isra.0+0x81/0x280<br /> ? perf_event_output+0x66/0xa0<br /> ? bpf_event_output+0x13a/0x190<br /> ? bpf_event_output_data+0x22/0x40<br /> ? bpf_prog_dfc84bbde731b257_cil_sock4_connect+0x40a/0xacb<br /> ? xa_load+0x87/0xe0<br /> ? __cgroup_bpf_run_filter_sock_addr+0xc1/0x1a0<br /> ? release_sock+0x3e/0x90<br /> ? sk_setsockopt+0x1a1/0x12f0<br /> ? udp_pre_connect+0x36/0x50<br /> ? inet_dgram_connect+0x93/0xa0<br /> ? __sys_connect+0xb4/0xe0<br /> ? udp_setsockopt+0x27/0x40<br /> ? __pfx_udp_push_pending_frames+0x10/0x10<br /> ? __sys_setsockopt+0xdf/0x1a0<br /> ? __x64_sys_connect+0xf/0x20<br /> ? do_syscall_64+0x3a/0x90<br /> ? entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> Fixing this by disabling preemption in bpf_event_output.<br /> <br /> [1] https://github.com/cilium/cilium/issues/26756

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio: Fix NULL pointer dereference caused by uninitialized group-&gt;iommufd<br /> <br /> group-&gt;iommufd is not initialized for the iommufd_ctx_put()<br /> <br /> [20018.331541] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [20018.377508] RIP: 0010:iommufd_ctx_put+0x5/0x10 [iommufd]<br /> ...<br /> [20018.476483] Call Trace:<br /> [20018.479214] <br /> [20018.481555] vfio_group_fops_unl_ioctl+0x506/0x690 [vfio]<br /> [20018.487586] __x64_sys_ioctl+0x6a/0xb0<br /> [20018.491773] ? trace_hardirqs_on+0xc5/0xe0<br /> [20018.496347] do_syscall_64+0x67/0x90<br /> [20018.500340] entry_SYSCALL_64_after_hwframe+0x4b/0xb5

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: xiic: xiic_xfer(): Fix runtime PM leak on error path<br /> <br /> The xiic_xfer() function gets a runtime PM reference when the function is<br /> entered. This reference is released when the function is exited. There is<br /> currently one error path where the function exits directly, which leads to<br /> a leak of the runtime PM reference.<br /> <br /> Make sure that this error path also releases the runtime PM reference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: stricter state check in mptcp_worker<br /> <br /> As reported by Christoph, the mptcp protocol can run the<br /> worker when the relevant msk socket is in an unexpected state:<br /> <br /> connect()<br /> // incoming reset + fastclose<br /> // the mptcp worker is scheduled<br /> mptcp_disconnect()<br /> // msk is now CLOSED<br /> listen()<br /> mptcp_worker()<br /> <br /> Leading to the following splat:<br /> <br /> divide error: 0000 [#1] PREEMPT SMP<br /> CPU: 1 PID: 21 Comm: kworker/1:0 Not tainted 6.3.0-rc1-gde5e8fd0123c #11<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014<br /> Workqueue: events mptcp_worker<br /> RIP: 0010:__tcp_select_window+0x22c/0x4b0 net/ipv4/tcp_output.c:3018<br /> RSP: 0018:ffffc900000b3c98 EFLAGS: 00010293<br /> RAX: 000000000000ffd7 RBX: 000000000000ffd7 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffffffff8214ce97 RDI: 0000000000000004<br /> RBP: 000000000000ffd7 R08: 0000000000000004 R09: 0000000000010000<br /> R10: 000000000000ffd7 R11: ffff888005afa148 R12: 000000000000ffd7<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000405270 CR3: 000000003011e006 CR4: 0000000000370ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> tcp_select_window net/ipv4/tcp_output.c:262 [inline]<br /> __tcp_transmit_skb+0x356/0x1280 net/ipv4/tcp_output.c:1345<br /> tcp_transmit_skb net/ipv4/tcp_output.c:1417 [inline]<br /> tcp_send_active_reset+0x13e/0x320 net/ipv4/tcp_output.c:3459<br /> mptcp_check_fastclose net/mptcp/protocol.c:2530 [inline]<br /> mptcp_worker+0x6c7/0x800 net/mptcp/protocol.c:2705<br /> process_one_work+0x3bd/0x950 kernel/workqueue.c:2390<br /> worker_thread+0x5b/0x610 kernel/workqueue.c:2537<br /> kthread+0x138/0x170 kernel/kthread.c:376<br /> ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308<br /> <br /> <br /> This change addresses the issue explicitly checking for bad states<br /> before running the mptcp worker.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> quota: fix warning in dqgrab()<br /> <br /> There&amp;#39;s issue as follows when do fault injection:<br /> WARNING: CPU: 1 PID: 14870 at include/linux/quotaops.h:51 dquot_disable+0x13b7/0x18c0<br /> Modules linked in:<br /> CPU: 1 PID: 14870 Comm: fsconfig Not tainted 6.3.0-next-20230505-00006-g5107a9c821af-dirty #541<br /> RIP: 0010:dquot_disable+0x13b7/0x18c0<br /> RSP: 0018:ffffc9000acc79e0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88825e41b980<br /> RDX: 0000000000000000 RSI: ffff88825e41b980 RDI: 0000000000000002<br /> RBP: ffff888179f68000 R08: ffffffff82087ca7 R09: 0000000000000000<br /> R10: 0000000000000001 R11: ffffed102f3ed026 R12: ffff888179f68130<br /> R13: ffff888179f68110 R14: dffffc0000000000 R15: ffff888179f68118<br /> FS: 00007f450a073740(0000) GS:ffff88882fc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffe96f2efd8 CR3: 000000025c8ad000 CR4: 00000000000006e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> dquot_load_quota_sb+0xd53/0x1060<br /> dquot_resume+0x172/0x230<br /> ext4_reconfigure+0x1dc6/0x27b0<br /> reconfigure_super+0x515/0xa90<br /> __x64_sys_fsconfig+0xb19/0xd20<br /> do_syscall_64+0x39/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Above issue may happens as follows:<br /> ProcessA ProcessB ProcessC<br /> sys_fsconfig<br /> vfs_fsconfig_locked<br /> reconfigure_super<br /> ext4_remount<br /> dquot_suspend -&gt; suspend all type quota<br /> <br /> sys_fsconfig<br /> vfs_fsconfig_locked<br /> reconfigure_super<br /> ext4_remount<br /> dquot_resume<br /> ret = dquot_load_quota_sb<br /> add_dquot_ref<br /> do_open -&gt; open file O_RDWR<br /> vfs_open<br /> do_dentry_open<br /> get_write_access<br /> atomic_inc_unless_negative(&amp;inode-&gt;i_writecount)<br /> ext4_file_open<br /> dquot_file_open<br /> dquot_initialize<br /> __dquot_initialize<br /> dqget<br /> atomic_inc(&amp;dquot-&gt;dq_count);<br /> <br /> __dquot_initialize<br /> __dquot_initialize<br /> dqget<br /> if (!test_bit(DQ_ACTIVE_B, &amp;dquot-&gt;dq_flags))<br /> ext4_acquire_dquot<br /> -&gt; Return error DQ_ACTIVE_B flag isn&amp;#39;t set<br /> dquot_disable<br /> invalidate_dquots<br /> if (atomic_read(&amp;dquot-&gt;dq_count))<br /> dqgrab<br /> WARN_ON_ONCE(!test_bit(DQ_ACTIVE_B, &amp;dquot-&gt;dq_flags))<br /> -&gt; Trigger warning<br /> <br /> In the above scenario, &amp;#39;dquot-&gt;dq_flags&amp;#39; has no DQ_ACTIVE_B is normal when<br /> dqgrab().<br /> To solve above issue just replace the dqgrab() use in invalidate_dquots() with<br /> atomic_inc(&amp;dquot-&gt;dq_count).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of: unittest: fix null pointer dereferencing in of_unittest_find_node_by_name()<br /> <br /> when kmalloc() fail to allocate memory in kasprintf(), name<br /> or full_name will be NULL, strcmp() will cause<br /> null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Array index may go out of bound<br /> <br /> Klocwork reports array &amp;#39;vha-&gt;host_str&amp;#39; of size 16 may use index value(s)<br /> 16..19. Use snprintf() instead of sprintf().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: handle case when repair happens with dev-replace<br /> <br /> [BUG]<br /> There is a bug report that a BUG_ON() in btrfs_repair_io_failure()<br /> (originally repair_io_failure() in v6.0 kernel) got triggered when<br /> replacing a unreliable disk:<br /> <br /> BTRFS warning (device sda1): csum failed root 257 ino 2397453 off 39624704 csum 0xb0d18c75 expected csum 0x4dae9c5e mirror 3<br /> kernel BUG at fs/btrfs/extent_io.c:2380!<br /> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 9 PID: 3614331 Comm: kworker/u257:2 Tainted: G OE 6.0.0-5-amd64 #1 Debian 6.0.10-2<br /> Hardware name: Micro-Star International Co., Ltd. MS-7C60/TRX40 PRO WIFI (MS-7C60), BIOS 2.70 07/01/2021<br /> Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]<br /> RIP: 0010:repair_io_failure+0x24a/0x260 [btrfs]<br /> Call Trace:<br /> <br /> clean_io_failure+0x14d/0x180 [btrfs]<br /> end_bio_extent_readpage+0x412/0x6e0 [btrfs]<br /> ? __switch_to+0x106/0x420<br /> process_one_work+0x1c7/0x380<br /> worker_thread+0x4d/0x380<br /> ? rescuer_thread+0x3a0/0x3a0<br /> kthread+0xe9/0x110<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br /> <br /> [CAUSE]<br /> <br /> Before the BUG_ON(), we got some read errors from the replace target<br /> first, note the mirror number (3, which is beyond RAID1 duplication,<br /> thus it&amp;#39;s read from the replace target device).<br /> <br /> Then at the BUG_ON() location, we are trying to writeback the repaired<br /> sectors back the failed device.<br /> <br /> The check looks like this:<br /> <br /> ret = btrfs_map_block(fs_info, BTRFS_MAP_WRITE, logical,<br /> &amp;map_length, &amp;bioc, mirror_num);<br /> if (ret)<br /> goto out_counter_dec;<br /> BUG_ON(mirror_num != bioc-&gt;mirror_num);<br /> <br /> But inside btrfs_map_block(), we can modify bioc-&gt;mirror_num especially<br /> for dev-replace:<br /> <br /> if (dev_replace_is_ongoing &amp;&amp; mirror_num == map-&gt;num_stripes + 1 &amp;&amp;<br /> !need_full_stripe(op) &amp;&amp; dev_replace-&gt;tgtdev != NULL) {<br /> ret = get_extra_mirror_from_replace(fs_info, logical, *length,<br /> dev_replace-&gt;srcdev-&gt;devid,<br /> &amp;mirror_num,<br /> &amp;physical_to_patch_in_first_stripe);<br /> patch_the_first_stripe_for_dev_replace = 1;<br /> }<br /> <br /> Thus if we&amp;#39;re repairing the replace target device, we&amp;#39;re going to<br /> trigger that BUG_ON().<br /> <br /> But in reality, the read failure from the replace target device may be<br /> that, our replace hasn&amp;#39;t reached the range we&amp;#39;re reading, thus we&amp;#39;re<br /> reading garbage, but with replace running, the range would be properly<br /> filled later.<br /> <br /> Thus in that case, we don&amp;#39;t need to do anything but let the replace<br /> routine to handle it.<br /> <br /> [FIX]<br /> Instead of a BUG_ON(), just skip the repair if we&amp;#39;re repairing the<br /> device replace target device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm integrity: Fix UAF in dm_integrity_dtr()<br /> <br /> Dm_integrity also has the same UAF problem when dm_resume()<br /> and dm_destroy() are concurrent.<br /> <br /> Therefore, cancelling timer again in dm_integrity_dtr().