Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen/events: close evtchn after mapping cleanup<br /> <br /> shutdown_pirq and startup_pirq are not taking the<br /> irq_mapping_update_lock because they can&amp;#39;t due to lock inversion. Both<br /> are called with the irq_desc-&gt;lock being taking. The lock order,<br /> however, is first irq_mapping_update_lock and then irq_desc-&gt;lock.<br /> <br /> This opens multiple races:<br /> - shutdown_pirq can be interrupted by a function that allocates an event<br /> channel:<br /> <br /> CPU0 CPU1<br /> shutdown_pirq {<br /> xen_evtchn_close(e)<br /> __startup_pirq {<br /> EVTCHNOP_bind_pirq<br /> -&gt; returns just freed evtchn e<br /> set_evtchn_to_irq(e, irq)<br /> }<br /> xen_irq_info_cleanup() {<br /> set_evtchn_to_irq(e, -1)<br /> }<br /> }<br /> <br /> Assume here event channel e refers here to the same event channel<br /> number.<br /> After this race the evtchn_to_irq mapping for e is invalid (-1).<br /> <br /> - __startup_pirq races with __unbind_from_irq in a similar way. Because<br /> __startup_pirq doesn&amp;#39;t take irq_mapping_update_lock it can grab the<br /> evtchn that __unbind_from_irq is currently freeing and cleaning up. In<br /> this case even though the event channel is allocated, its mapping can<br /> be unset in evtchn_to_irq.<br /> <br /> The fix is to first cleanup the mappings and then close the event<br /> channel. In this way, when an event channel gets allocated it&amp;#39;s<br /> potential previous evtchn_to_irq mappings are guaranteed to be unset already.<br /> This is also the reverse order of the allocation where first the event<br /> channel is allocated and then the mappings are setup.<br /> <br /> On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal<br /> [un]bind interfaces"), we hit a BUG like the following during probing of NVMe<br /> devices. The issue is that during nvme_setup_io_queues, pci_free_irq<br /> is called for every device which results in a call to shutdown_pirq.<br /> With many nvme devices it&amp;#39;s therefore likely to hit this race during<br /> boot because there will be multiple calls to shutdown_pirq and<br /> startup_pirq are running potentially in parallel.<br /> <br /> ------------[ cut here ]------------<br /> blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled<br /> kernel BUG at drivers/xen/events/events_base.c:499!<br /> invalid opcode: 0000 [#1] SMP PTI<br /> CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1<br /> Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006<br /> Workqueue: nvme-reset-wq nvme_reset_work<br /> RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0<br /> Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00<br /> RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006<br /> RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff<br /> RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed<br /> R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002<br /> FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> ? show_trace_log_lvl+0x1c1/0x2d9<br /> ? show_trace_log_lvl+0x1c1/0x2d9<br /> ? set_affinity_irq+0xdc/0x1c0<br /> ? __die_body.cold+0x8/0xd<br /> ? die+0x2b/0x50<br /> ? do_trap+0x90/0x110<br /> ? bind_evtchn_to_cpu+0xdf/0xf0<br /> ? do_error_trap+0x65/0x80<br /> ? bind_evtchn_to_cpu+0xdf/0xf0<br /> ? exc_invalid_op+0x4e/0x70<br /> ? bind_evtchn_to_cpu+0xdf/0xf0<br /> ? asm_exc_invalid_op+0x12/0x20<br /> ? bind_evtchn_to_cpu+0xdf/0x<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super<br /> <br /> When configuring a hugetlb filesystem via the fsconfig() syscall, there is<br /> a possible NULL dereference in hugetlbfs_fill_super() caused by assigning<br /> NULL to ctx-&gt;hstate in hugetlbfs_parse_param() when the requested pagesize<br /> is non valid.<br /> <br /> E.g: Taking the following steps:<br /> <br /> fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC);<br /> fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0);<br /> fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);<br /> <br /> Given that the requested "pagesize" is invalid, ctxt-&gt;hstate will be replaced<br /> with NULL, losing its previous value, and we will print an error:<br /> <br /> ...<br /> ...<br /> case Opt_pagesize:<br /> ps = memparse(param-&gt;string, &amp;rest);<br /> ctx-&gt;hstate = h;<br /> if (!ctx-&gt;hstate) {<br /> pr_err("Unsupported page size %lu MB\n", ps / SZ_1M);<br /> return -EINVAL;<br /> }<br /> return 0;<br /> ...<br /> ...<br /> <br /> This is a problem because later on, we will dereference ctxt-&gt;hstate in<br /> hugetlbfs_fill_super()<br /> <br /> ...<br /> ...<br /> sb-&gt;s_blocksize = huge_page_size(ctx-&gt;hstate);<br /> ...<br /> ...<br /> <br /> Causing below Oops.<br /> <br /> Fix this by replacing cxt-&gt;hstate value only when then pagesize is known<br /> to be valid.<br /> <br /> kernel: hugetlbfs: Unsupported page size 0 MB<br /> kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028<br /> kernel: #PF: supervisor read access in kernel mode<br /> kernel: #PF: error_code(0x0000) - not-present page<br /> kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0<br /> kernel: Oops: 0000 [#1] PREEMPT SMP PTI<br /> kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f<br /> kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017<br /> kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0<br /> kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28<br /> kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246<br /> kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004<br /> kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000<br /> kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004<br /> kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000<br /> kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400<br /> kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000<br /> kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0<br /> kernel: Call Trace:<br /> kernel: <br /> kernel: ? __die_body+0x1a/0x60<br /> kernel: ? page_fault_oops+0x16f/0x4a0<br /> kernel: ? search_bpf_extables+0x65/0x70<br /> kernel: ? fixup_exception+0x22/0x310<br /> kernel: ? exc_page_fault+0x69/0x150<br /> kernel: ? asm_exc_page_fault+0x22/0x30<br /> kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10<br /> kernel: ? hugetlbfs_fill_super+0xb4/0x1a0<br /> kernel: ? hugetlbfs_fill_super+0x28/0x1a0<br /> kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10<br /> kernel: vfs_get_super+0x40/0xa0<br /> kernel: ? __pfx_bpf_lsm_capable+0x10/0x10<br /> kernel: vfs_get_tree+0x25/0xd0<br /> kernel: vfs_cmd_create+0x64/0xe0<br /> kernel: __x64_sys_fsconfig+0x395/0x410<br /> kernel: do_syscall_64+0x80/0x160<br /> kernel: ? syscall_exit_to_user_mode+0x82/0x240<br /> kernel: ? do_syscall_64+0x8d/0x160<br /> kernel: ? syscall_exit_to_user_mode+0x82/0x240<br /> kernel: ? do_syscall_64+0x8d/0x160<br /> kernel: ? exc_page_fault+0x69/0x150<br /> kernel: entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> kernel: RIP: 0033:0x7ffbc0cb87c9<br /> kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48<br /> kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af<br /> kernel: RAX: fffffffffff<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: prevent use-after-free in encode_cap_msg()<br /> <br /> In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was<br /> caught by KASAN at this line - &amp;#39;ceph_buffer_get(arg-&gt;xattr_buf);&amp;#39;. This<br /> implies before the refcount could be increment here, it was freed.<br /> <br /> In same file, in "handle_cap_grant()" refcount is decremented by this<br /> line - &amp;#39;ceph_buffer_put(ci-&gt;i_xattrs.blob);&amp;#39;. It appears that a race<br /> occurred and resource was freed by the latter line before the former<br /> line could increment it.<br /> <br /> encode_cap_msg() is called by __send_cap() and __send_cap() is called by<br /> ceph_check_caps() after calling __prep_cap(). __prep_cap() is where<br /> arg-&gt;xattr_buf is assigned to ci-&gt;i_xattrs.blob. This is the spot where<br /> the refcount must be increased to prevent "use after free" error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: protect updates of 64-bit statistics counters<br /> <br /> As explained by a comment in , write side of struct<br /> u64_stats_sync must ensure mutual exclusion, or one seqcount update could<br /> be lost on 32-bit platforms, thus blocking readers forever. Such lockups<br /> have been observed in real world after stmmac_xmit() on one CPU raced with<br /> stmmac_napi_poll_tx() on another CPU.<br /> <br /> To fix the issue without introducing a new lock, split the statics into<br /> three parts:<br /> <br /> 1. fields updated only under the tx queue lock,<br /> 2. fields updated only during NAPI poll,<br /> 3. fields updated only from interrupt context,<br /> <br /> Updates to fields in the first two groups are already serialized through<br /> other locks. It is sufficient to split the existing struct u64_stats_sync<br /> so that each group has its own.<br /> <br /> Note that tx_set_ic_bit is updated from both contexts. Split this counter<br /> so that each context gets its own, and calculate their sum to get the total<br /> value in stmmac_get_ethtool_stats().<br /> <br /> For the third group, multiple interrupts may be processed by different CPUs<br /> at the same time, but interrupts on the same CPU will not nest. Move fields<br /> from this group to a newly created per-cpu struct stmmac_pcpu_stats.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Fix circular locking dependency<br /> <br /> The rule inside kvm enforces that the vcpu-&gt;mutex is taken *inside*<br /> kvm-&gt;lock. The rule is violated by the pkvm_create_hyp_vm() which acquires<br /> the kvm-&gt;lock while already holding the vcpu-&gt;mutex lock from<br /> kvm_vcpu_ioctl(). Avoid the circular locking dependency altogether by<br /> protecting the hyp vm handle with the config_lock, much like we already<br /> do for other forms of VM-scoped data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: Fix regression in writes when non-standard maximum write size negotiated<br /> <br /> The conversion to netfs in the 6.3 kernel caused a regression when<br /> maximum write size is set by the server to an unexpected value which is<br /> not a multiple of 4096 (similarly if the user overrides the maximum<br /> write size by setting mount parm "wsize", but sets it to a value that<br /> is not a multiple of 4096). When negotiated write size is not a<br /> multiple of 4096 the netfs code can skip the end of the final<br /> page when doing large sequential writes, causing data corruption.<br /> <br /> This section of code is being rewritten/removed due to a large<br /> netfs change, but until that point (ie for the 6.3 kernel until now)<br /> we can not support non-standard maximum write sizes.<br /> <br /> Add a warning if a user specifies a wsize on mount that is not<br /> a multiple of 4096 (and round down), also add a change where we<br /> round down the maximum write size if the server negotiates a value<br /> that is not a multiple of 4096 (we also have to check to make sure that<br /> we do not round it down to zero).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: fix a crash when we run out of stations<br /> <br /> A DoS tool that injects loads of authentication frames made our AP<br /> crash. The iwl_mvm_is_dup() function couldn&amp;#39;t find the per-queue<br /> dup_data which was not allocated.<br /> <br /> The root cause for that is that we ran out of stations in the firmware<br /> and we didn&amp;#39;t really add the station to the firmware, yet we didn&amp;#39;t<br /> return an error to mac80211.<br /> Mac80211 was thinking that we have the station and because of that,<br /> sta_info::uploaded was set to 1. This allowed<br /> ieee80211_find_sta_by_ifaddr() to return a valid station object, but<br /> that ieee80211_sta didn&amp;#39;t have any iwl_mvm_sta object initialized and<br /> that caused the crash mentioned earlier when we got Rx on that station.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: fix double-free bug<br /> <br /> The storage for the TLV PC register data wasn&amp;#39;t done like all<br /> the other storage in the drv-&gt;fw area, which is cleared at the<br /> end of deallocation. Therefore, the freeing must also be done<br /> differently, explicitly NULL&amp;#39;ing it out after the free, since<br /> otherwise there&amp;#39;s a nasty double-free bug here if a file fails<br /> to load after this has been parsed, and we get another free<br /> later (e.g. because no other file exists.) Fix that by adding<br /> the missing NULL assignment.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_locked<br /> <br /> The SEV platform device can be shutdown with a null psp_master,<br /> e.g., using DEBUG_TEST_DRIVER_REMOVE. Found using KASAN:<br /> <br /> [ 137.148210] ccp 0000:23:00.1: enabling device (0000 -&gt; 0002)<br /> [ 137.162647] ccp 0000:23:00.1: no command queues available<br /> [ 137.170598] ccp 0000:23:00.1: sev enabled<br /> [ 137.174645] ccp 0000:23:00.1: psp enabled<br /> [ 137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI<br /> [ 137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7]<br /> [ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311<br /> [ 137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180<br /> [ 137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c<br /> [ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216<br /> [ 137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e<br /> [ 137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0<br /> [ 137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66<br /> [ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28<br /> [ 137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8<br /> [ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000<br /> [ 137.182693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0<br /> [ 137.182693] Call Trace:<br /> [ 137.182693] <br /> [ 137.182693] ? show_regs+0x6c/0x80<br /> [ 137.182693] ? __die_body+0x24/0x70<br /> [ 137.182693] ? die_addr+0x4b/0x80<br /> [ 137.182693] ? exc_general_protection+0x126/0x230<br /> [ 137.182693] ? asm_exc_general_protection+0x2b/0x30<br /> [ 137.182693] ? __sev_platform_shutdown_locked+0x51/0x180<br /> [ 137.182693] sev_firmware_shutdown.isra.0+0x1e/0x80<br /> [ 137.182693] sev_dev_destroy+0x49/0x100<br /> [ 137.182693] psp_dev_destroy+0x47/0xb0<br /> [ 137.182693] sp_destroy+0xbb/0x240<br /> [ 137.182693] sp_pci_remove+0x45/0x60<br /> [ 137.182693] pci_device_remove+0xaa/0x1d0<br /> [ 137.182693] device_remove+0xc7/0x170<br /> [ 137.182693] really_probe+0x374/0xbe0<br /> [ 137.182693] ? srso_return_thunk+0x5/0x5f<br /> [ 137.182693] __driver_probe_device+0x199/0x460<br /> [ 137.182693] driver_probe_device+0x4e/0xd0<br /> [ 137.182693] __driver_attach+0x191/0x3d0<br /> [ 137.182693] ? __pfx___driver_attach+0x10/0x10<br /> [ 137.182693] bus_for_each_dev+0x100/0x190<br /> [ 137.182693] ? __pfx_bus_for_each_dev+0x10/0x10<br /> [ 137.182693] ? __kasan_check_read+0x15/0x20<br /> [ 137.182693] ? srso_return_thunk+0x5/0x5f<br /> [ 137.182693] ? _raw_spin_unlock+0x27/0x50<br /> [ 137.182693] driver_attach+0x41/0x60<br /> [ 137.182693] bus_add_driver+0x2a8/0x580<br /> [ 137.182693] driver_register+0x141/0x480<br /> [ 137.182693] __pci_register_driver+0x1d6/0x2a0<br /> [ 137.182693] ? srso_return_thunk+0x5/0x5f<br /> [ 137.182693] ? esrt_sysfs_init+0x1cd/0x5d0<br /> [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10<br /> [ 137.182693] sp_pci_init+0x22/0x30<br /> [ 137.182693] sp_mod_init+0x14/0x30<br /> [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10<br /> [ 137.182693] do_one_initcall+0xd1/0x470<br /> [ 137.182693] ? __pfx_do_one_initcall+0x10/0x10<br /> [ 137.182693] ? parameq+0x80/0xf0<br /> [ 137.182693] ? srso_return_thunk+0x5/0x5f<br /> [ 137.182693] ? __kmalloc+0x3b0/0x4e0<br /> [ 137.182693] ? kernel_init_freeable+0x92d/0x1050<br /> [ 137.182693] ? kasan_populate_vmalloc_pte+0x171/0x190<br /> [ 137.182693] ? srso_return_thunk+0x5/0x5f<br /> [ 137.182693] kernel_init_freeable+0xa64/0x1050<br /> [ 137.182693] ? __pfx_kernel_init+0x10/0x10<br /> [ 137.182693] kernel_init+0x24/0x160<br /> [ 137.182693] ? __switch_to_asm+0x3e/0x70<br /> [ 137.182693] ret_from_fork+0x40/0x80<br /> [ 137.182693] ? __pfx_kernel_init+0x1<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()<br /> <br /> Syzbot reported a hang issue in migrate_pages_batch() called by mbind()<br /> and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.<br /> <br /> While migrate_pages_batch() locks a folio and waits for the writeback to<br /> complete, the log writer thread that should bring the writeback to<br /> completion picks up the folio being written back in<br /> nilfs_lookup_dirty_data_buffers() that it calls for subsequent log<br /> creation and was trying to lock the folio. Thus causing a deadlock.<br /> <br /> In the first place, it is unexpected that folios/pages in the middle of<br /> writeback will be updated and become dirty. Nilfs2 adds a checksum to<br /> verify the validity of the log being written and uses it for recovery at<br /> mount, so data changes during writeback are suppressed. Since this is<br /> broken, an unclean shutdown could potentially cause recovery to fail.<br /> <br /> Investigation revealed that the root cause is that the wait for writeback<br /> completion in nilfs_page_mkwrite() is conditional, and if the backing<br /> device does not require stable writes, data may be modified without<br /> waiting.<br /> <br /> Fix these issues by making nilfs_page_mkwrite() wait for writeback to<br /> finish regardless of the stable write requirement of the backing device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix data corruption in dsync block recovery for small block sizes<br /> <br /> The helper function nilfs_recovery_copy_block() of<br /> nilfs_recovery_dsync_blocks(), which recovers data from logs created by<br /> data sync writes during a mount after an unclean shutdown, incorrectly<br /> calculates the on-page offset when copying repair data to the file&amp;#39;s page<br /> cache. In environments where the block size is smaller than the page<br /> size, this flaw can cause data corruption and leak uninitialized memory<br /> bytes during the recovery process.<br /> <br /> Fix these issues by correcting this byte offset calculation on the page.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove<br /> <br /> In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the<br /> VMBus channel"), napi_disable was getting called for all channels,<br /> including all subchannels without confirming if they are enabled or not.<br /> <br /> This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()<br /> has finished running but nvdev-&gt;subchan_work has not started yet.<br /> netvsc_subchan_work() -&gt; rndis_set_subchannel() has not created the<br /> sub-channels and because of that netvsc_sc_open() is not running.<br /> netvsc_remove() calls cancel_work_sync(&amp;nvdev-&gt;subchan_work), for which<br /> netvsc_subchan_work did not run.<br /> <br /> netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI<br /> cannot be scheduled. Then netvsc_sc_open() -&gt; napi_enable will clear the<br /> NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the<br /> opposite.<br /> <br /> Now during netvsc_device_remove(), when napi_disable is called for those<br /> subchannels, napi_disable gets stuck on infinite msleep.<br /> <br /> This fix addresses this problem by ensuring that napi_disable() is not<br /> getting called for non-enabled NAPI struct.<br /> But netif_napi_del() is still necessary for these non-enabled NAPI struct<br /> for cleanup purpose.<br /> <br /> Call trace:<br /> [ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002<br /> [ 654.568030] Call Trace:<br /> [ 654.571221] <br /> [ 654.573790] __schedule+0x2d6/0x960<br /> [ 654.577733] schedule+0x69/0xf0<br /> [ 654.581214] schedule_timeout+0x87/0x140<br /> [ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20<br /> [ 654.590291] msleep+0x2d/0x40<br /> [ 654.593625] napi_disable+0x2b/0x80<br /> [ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]<br /> [ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]<br /> [ 654.611101] ? do_wait_intr+0xb0/0xb0<br /> [ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc]<br /> [ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]