Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: don&amp;#39;t set the MFP flag for the GTK<br /> <br /> The firmware doesn&amp;#39;t need the MFP flag for the GTK, it can even make the<br /> firmware crash. in case the AP is configured with: group cipher TKIP and<br /> MFPC. We would send the GTK with cipher = TKIP and MFP which is of course<br /> not possible.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: fix reconnection fail due to reserved tag allocation<br /> <br /> We found a issue on production environment while using NVMe over RDMA,<br /> admin_q reconnect failed forever while remote target and network is ok.<br /> After dig into it, we found it may caused by a ABBA deadlock due to tag<br /> allocation. In my case, the tag was hold by a keep alive request<br /> waiting inside admin_q, as we quiesced admin_q while reset ctrl, so the<br /> request maked as idle and will not process before reset success. As<br /> fabric_q shares tagset with admin_q, while reconnect remote target, we<br /> need a tag for connect command, but the only one reserved tag was held<br /> by keep alive command which waiting inside admin_q. As a result, we<br /> failed to reconnect admin_q forever. In order to fix this issue, I<br /> think we should keep two reserved tags for admin queue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix deadlock with fiemap and extent locking<br /> <br /> While working on the patchset to remove extent locking I got a lockdep<br /> splat with fiemap and pagefaulting with my new extent lock replacement<br /> lock.<br /> <br /> This deadlock exists with our normal code, we just don&amp;#39;t have lockdep<br /> annotations with the extent locking so we&amp;#39;ve never noticed it.<br /> <br /> Since we&amp;#39;re copying the fiemap extent to user space on every iteration<br /> we have the chance of pagefaulting. Because we hold the extent lock for<br /> the entire range we could mkwrite into a range in the file that we have<br /> mmap&amp;#39;ed. This would deadlock with the following stack trace<br /> <br /> [] lock_extent+0x28d/0x2f0<br /> [] btrfs_page_mkwrite+0x273/0x8a0<br /> [] do_page_mkwrite+0x50/0xb0<br /> [] do_fault+0xc1/0x7b0<br /> [] __handle_mm_fault+0x2fa/0x460<br /> [] handle_mm_fault+0xa4/0x330<br /> [] do_user_addr_fault+0x1f4/0x800<br /> [] exc_page_fault+0x7c/0x1e0<br /> [] asm_exc_page_fault+0x26/0x30<br /> [] rep_movs_alternative+0x33/0x70<br /> [] _copy_to_user+0x49/0x70<br /> [] fiemap_fill_next_extent+0xc8/0x120<br /> [] emit_fiemap_extent+0x4d/0xa0<br /> [] extent_fiemap+0x7f8/0xad0<br /> [] btrfs_fiemap+0x49/0x80<br /> [] __x64_sys_ioctl+0x3e1/0xb50<br /> [] do_syscall_64+0x94/0x1a0<br /> [] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> I wrote an fstest to reproduce this deadlock without my replacement lock<br /> and verified that the deadlock exists with our existing locking.<br /> <br /> To fix this simply don&amp;#39;t take the extent lock for the entire duration of<br /> the fiemap. This is safe in general because we keep track of where we<br /> are when we&amp;#39;re searching the tree, so if an ordered extent updates in<br /> the middle of our fiemap call we&amp;#39;ll still emit the correct extents<br /> because we know what offset we were on before.<br /> <br /> The only place we maintain the lock is searching delalloc. Since the<br /> delalloc stuff can change during writeback we want to lock the extent<br /> range so we have a consistent view of delalloc at the time we&amp;#39;re<br /> checking to see if we need to set the delalloc flag.<br /> <br /> With this patch applied we no longer deadlock with my testcase.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau: fix stale locked mutex in nouveau_gem_ioctl_pushbuf<br /> <br /> If VM_BIND is enabled on the client the legacy submission ioctl can&amp;#39;t be<br /> used, however if a client tries to do so regardless it will return an<br /> error. In this case the clients mutex remained unlocked leading to a<br /> deadlock inside nouveau_drm_postclose or any other nouveau ioctl call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/md-bitmap: fix incorrect usage for sb_index<br /> <br /> Commit d7038f951828 ("md-bitmap: don&amp;#39;t use -&gt;index for pages backing the<br /> bitmap file") removed page-&gt;index from bitmap code, but left wrong code<br /> logic for clustered-md. current code never set slot offset for cluster<br /> nodes, will sometimes cause crash in clustered env.<br /> <br /> Call trace (partly):<br /> md_bitmap_file_set_bit+0x110/0x1d8 [md_mod]<br /> md_bitmap_startwrite+0x13c/0x240 [md_mod]<br /> raid1_make_request+0x6b0/0x1c08 [raid1]<br /> md_handle_request+0x1dc/0x368 [md_mod]<br /> md_submit_bio+0x80/0xf8 [md_mod]<br /> __submit_bio+0x178/0x300<br /> submit_bio_noacct_nocheck+0x11c/0x338<br /> submit_bio_noacct+0x134/0x614<br /> submit_bio+0x28/0xdc<br /> submit_bh_wbc+0x130/0x1cc<br /> submit_bh+0x1c/0x28

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Stop parsing channels bits when all channels are found.<br /> <br /> If a usb audio device sets more bits than the amount of channels<br /> it could write outside of the map array.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes<br /> <br /> When moving a station out of a VLAN and deleting the VLAN afterwards, the<br /> fast_rx entry still holds a pointer to the VLAN&amp;#39;s netdev, which can cause<br /> use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx<br /> after the VLAN change.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Flush pages under kvm-&gt;lock to fix UAF in svm_register_enc_region()<br /> <br /> Do the cache flush of converted pages in svm_register_enc_region() before<br /> dropping kvm-&gt;lock to fix use-after-free issues where region and/or its<br /> array of pages could be freed by a different task, e.g. if userspace has<br /> __unregister_enc_region_locked() already queued up for the region.<br /> <br /> Note, the "obvious" alternative of using local variables doesn&amp;#39;t fully<br /> resolve the bug, as region-&gt;pages is also dynamically allocated. I.e. the<br /> region structure itself would be fine, but region-&gt;pages could be freed.<br /> <br /> Flushing multiple pages under kvm-&gt;lock is unfortunate, but the entire<br /> flow is a rare slow path, and the manual flush is only needed on CPUs that<br /> lack coherency for encrypted memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tee: optee: Fix kernel panic caused by incorrect error handling<br /> <br /> The error path while failing to register devices on the TEE bus has a<br /> bug leading to kernel panic as follows:<br /> <br /> [ 15.398930] Unable to handle kernel paging request at virtual address ffff07ed00626d7c<br /> [ 15.406913] Mem abort info:<br /> [ 15.409722] ESR = 0x0000000096000005<br /> [ 15.413490] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 15.418814] SET = 0, FnV = 0<br /> [ 15.421878] EA = 0, S1PTW = 0<br /> [ 15.425031] FSC = 0x05: level 1 translation fault<br /> [ 15.429922] Data abort info:<br /> [ 15.432813] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000<br /> [ 15.438310] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 15.443372] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 15.448697] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000d9e3e000<br /> [ 15.455413] [ffff07ed00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=0000000000000000<br /> [ 15.464146] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> <br /> Commit 7269cba53d90 ("tee: optee: Fix supplicant based device enumeration")<br /> lead to the introduction of this bug. So fix it appropriately.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: altmodes/displayport: create sysfs nodes as driver&amp;#39;s default device attribute group<br /> <br /> The DisplayPort driver&amp;#39;s sysfs nodes may be present to the userspace before<br /> typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that<br /> a sysfs read can trigger a NULL pointer error by deferencing dp-&gt;hpd in<br /> hpd_show or dp-&gt;lock in pin_assignment_show, as dev_get_drvdata() returns<br /> NULL in those cases.<br /> <br /> Remove manual sysfs node creation in favor of adding attribute group as<br /> default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is<br /> not used here otherwise the path to the sysfs nodes is no longer compliant<br /> with the ABI.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm: Ensure input to pfn_to_kaddr() is treated as a 64-bit type<br /> <br /> On 64-bit platforms, the pfn_to_kaddr() macro requires that the input<br /> value is 64 bits in order to ensure that valid address bits don&amp;#39;t get<br /> lost when shifting that input by PAGE_SHIFT to calculate the physical<br /> address to provide a virtual address for.<br /> <br /> One such example is in pvalidate_pages() (used by SEV-SNP guests), where<br /> the GFN in the struct used for page-state change requests is a 40-bit<br /> bit-field, so attempts to pass this GFN field directly into<br /> pfn_to_kaddr() ends up causing guest crashes when dealing with addresses<br /> above the 1TB range due to the above.<br /> <br /> Fix this issue with SEV-SNP guests, as well as any similar cases that<br /> might cause issues in current/future code, by using an inline function,<br /> instead of a macro, so that the input is implicitly cast to the<br /> expected 64-bit input type prior to performing the shift operation.<br /> <br /> While it might be argued that the issue is on the caller side, other<br /> archs/macros have taken similar approaches to deal with instances like<br /> this, such as ARM explicitly casting the input to phys_addr_t:<br /> <br /> e48866647b48 ("ARM: 8396/1: use phys_addr_t in pfn_to_kaddr()")<br /> <br /> A C inline function is even better though.<br /> <br /> [ mingo: Refined the changelog some more &amp; added __always_inline. ]