Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hfi1: Fix use-after-free bug for mm struct<br /> <br /> Under certain conditions, such as MPI_Abort, the hfi1 cleanup code may<br /> represent the last reference held on the task mm.<br /> hfi1_mmu_rb_unregister() then drops the last reference and the mm is freed<br /> before the final use in hfi1_release_user_pages(). A new task may<br /> allocate the mm structure while it is still being used, resulting in<br /> problems. One manifestation is corruption of the mmap_sem counter leading<br /> to a hang in down_write(). Another is corruption of an mm struct that is<br /> in use by another task.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: release correct delalloc amount in direct IO write path<br /> <br /> Running generic/406 causes the following WARNING in btrfs_destroy_inode()<br /> which tells there are outstanding extents left.<br /> <br /> In btrfs_get_blocks_direct_write(), we reserve a temporary outstanding<br /> extents with btrfs_delalloc_reserve_metadata() (or indirectly from<br /> btrfs_delalloc_reserve_space(()). We then release the outstanding extents<br /> with btrfs_delalloc_release_extents(). However, the "len" can be modified<br /> in the COW case, which releases fewer outstanding extents than expected.<br /> <br /> Fix it by calling btrfs_delalloc_release_extents() for the original length.<br /> <br /> To reproduce the warning, the filesystem should be 1 GiB. It&amp;#39;s<br /> triggering a short-write, due to not being able to allocate a large<br /> extent and instead allocating a smaller one.<br /> <br /> WARNING: CPU: 0 PID: 757 at fs/btrfs/inode.c:8848 btrfs_destroy_inode+0x1e6/0x210 [btrfs]<br /> Modules linked in: btrfs blake2b_generic xor lzo_compress<br /> lzo_decompress raid6_pq zstd zstd_decompress zstd_compress xxhash zram<br /> zsmalloc<br /> CPU: 0 PID: 757 Comm: umount Not tainted 5.17.0-rc8+ #101<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS d55cb5a 04/01/2014<br /> RIP: 0010:btrfs_destroy_inode+0x1e6/0x210 [btrfs]<br /> RSP: 0018:ffffc9000327bda8 EFLAGS: 00010206<br /> RAX: 0000000000000000 RBX: ffff888100548b78 RCX: 0000000000000000<br /> RDX: 0000000000026900 RSI: 0000000000000000 RDI: ffff888100548b78<br /> RBP: ffff888100548940 R08: 0000000000000000 R09: ffff88810b48aba8<br /> R10: 0000000000000001 R11: ffff8881004eb240 R12: ffff88810b48a800<br /> R13: ffff88810b48ec08 R14: ffff88810b48ed00 R15: ffff888100490c68<br /> FS: 00007f8549ea0b80(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f854a09e733 CR3: 000000010a2e9003 CR4: 0000000000370eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> destroy_inode+0x33/0x70<br /> dispose_list+0x43/0x60<br /> evict_inodes+0x161/0x1b0<br /> generic_shutdown_super+0x2d/0x110<br /> kill_anon_super+0xf/0x20<br /> btrfs_kill_super+0xd/0x20 [btrfs]<br /> deactivate_locked_super+0x27/0x90<br /> cleanup_mnt+0x12c/0x180<br /> task_work_run+0x54/0x80<br /> exit_to_user_mode_prepare+0x152/0x160<br /> syscall_exit_to_user_mode+0x12/0x30<br /> do_syscall_64+0x42/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f854a000fb7

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix by adding FPU protection for dcn30_internal_validate_bw<br /> <br /> [Why]<br /> Below general protection fault observed when WebGL Aquarium is run for<br /> longer duration. If drm debug logs are enabled and set to 0x1f then the<br /> issue is observed within 10 minutes of run.<br /> <br /> [ 100.717056] general protection fault, probably for non-canonical address 0x2d33302d32323032: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 100.727921] CPU: 3 PID: 1906 Comm: DrmThread Tainted: G W 5.15.30 #12 d726c6a2d6ebe5cf9223931cbca6892f916fe18b<br /> [ 100.754419] RIP: 0010:CalculateSwathWidth+0x1f7/0x44f<br /> [ 100.767109] Code: 00 00 00 f2 42 0f 11 04 f0 48 8b 85 88 00 00 00 f2 42 0f 10 04 f0 48 8b 85 98 00 00 00 f2 42 0f 11 04 f0 48 8b 45 10 0f 57 c0 42 0f 2a 04 b0 0f 57 c9 f3 43 0f 2a 0c b4 e8 8c e2 f3 ff 48 8b<br /> [ 100.781269] RSP: 0018:ffffa9230079eeb0 EFLAGS: 00010246<br /> [ 100.812528] RAX: 2d33302d32323032 RBX: 0000000000000500 RCX: 0000000000000000<br /> [ 100.819656] RDX: 0000000000000001 RSI: ffff99deb712c49c RDI: 0000000000000000<br /> [ 100.826781] RBP: ffffa9230079ef50 R08: ffff99deb712460c R09: ffff99deb712462c<br /> [ 100.833907] R10: ffff99deb7124940 R11: ffff99deb7124d70 R12: ffff99deb712ae44<br /> [ 100.841033] R13: 0000000000000001 R14: 0000000000000000 R15: ffffa9230079f0a0<br /> [ 100.848159] FS: 00007af121212640(0000) GS:ffff99deba780000(0000) knlGS:0000000000000000<br /> [ 100.856240] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 100.861980] CR2: 0000209000fe1000 CR3: 000000011b18c000 CR4: 0000000000350ee0<br /> [ 100.869106] Call Trace:<br /> [ 100.871555] <br /> [ 100.873655] ? asm_sysvec_reschedule_ipi+0x12/0x20<br /> [ 100.878449] CalculateSwathAndDETConfiguration+0x1a3/0x6dd<br /> [ 100.883937] dml31_ModeSupportAndSystemConfigurationFull+0x2ce4/0x76da<br /> [ 100.890467] ? kallsyms_lookup_buildid+0xc8/0x163<br /> [ 100.895173] ? kallsyms_lookup_buildid+0xc8/0x163<br /> [ 100.899874] ? __sprint_symbol+0x80/0x135<br /> [ 100.903883] ? dm_update_plane_state+0x3f9/0x4d2<br /> [ 100.908500] ? symbol_string+0xb7/0xde<br /> [ 100.912250] ? number+0x145/0x29b<br /> [ 100.915566] ? vsnprintf+0x341/0x5ff<br /> [ 100.919141] ? desc_read_finalized_seq+0x39/0x87<br /> [ 100.923755] ? update_load_avg+0x1b9/0x607<br /> [ 100.927849] ? compute_mst_dsc_configs_for_state+0x7d/0xd5b<br /> [ 100.933416] ? fetch_pipe_params+0xa4d/0xd0c<br /> [ 100.937686] ? dc_fpu_end+0x3d/0xa8<br /> [ 100.941175] dml_get_voltage_level+0x16b/0x180<br /> [ 100.945619] dcn30_internal_validate_bw+0x10e/0x89b<br /> [ 100.950495] ? dcn31_validate_bandwidth+0x68/0x1fc<br /> [ 100.955285] ? resource_build_scaling_params+0x98b/0xb8c<br /> [ 100.960595] ? dcn31_validate_bandwidth+0x68/0x1fc<br /> [ 100.965384] dcn31_validate_bandwidth+0x9a/0x1fc<br /> [ 100.970001] dc_validate_global_state+0x238/0x295<br /> [ 100.974703] amdgpu_dm_atomic_check+0x9c1/0xbce<br /> [ 100.979235] ? _printk+0x59/0x73<br /> [ 100.982467] drm_atomic_check_only+0x403/0x78b<br /> [ 100.986912] drm_mode_atomic_ioctl+0x49b/0x546<br /> [ 100.991358] ? drm_ioctl+0x1c1/0x3b3<br /> [ 100.994936] ? drm_atomic_set_property+0x92a/0x92a<br /> [ 100.999725] drm_ioctl_kernel+0xdc/0x149<br /> [ 101.003648] drm_ioctl+0x27f/0x3b3<br /> [ 101.007051] ? drm_atomic_set_property+0x92a/0x92a<br /> [ 101.011842] amdgpu_drm_ioctl+0x49/0x7d<br /> [ 101.015679] __se_sys_ioctl+0x7c/0xb8<br /> [ 101.015685] do_syscall_64+0x5f/0xb8<br /> [ 101.015690] ? __irq_exit_rcu+0x34/0x96<br /> <br /> [How]<br /> It calles populate_dml_pipes which uses doubles to initialize.<br /> Adding FPU protection avoids context switch and probable loss of vba context<br /> as there is potential contention while drm debug logs are enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: Fix unregistering of framebuffers without device<br /> <br /> OF framebuffers do not have an underlying device in the Linux<br /> device hierarchy. Do a regular unregister call instead of hot<br /> unplugging such a non-existing device. Fixes a NULL dereference.<br /> An example error message on ppc64le is shown below.<br /> <br /> BUG: Kernel NULL pointer dereference on read at 0x00000060<br /> Faulting instruction address: 0xc00000000080dfa4<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries<br /> [...]<br /> CPU: 2 PID: 139 Comm: systemd-udevd Not tainted 5.17.0-ae085d7f9365 #1<br /> NIP: c00000000080dfa4 LR: c00000000080df9c CTR: c000000000797430<br /> REGS: c000000004132fe0 TRAP: 0300 Not tainted (5.17.0-ae085d7f9365)<br /> MSR: 8000000002009033 CR: 28228282 XER: 20000000<br /> CFAR: c00000000000c80c DAR: 0000000000000060 DSISR: 40000000 IRQMASK: 0<br /> GPR00: c00000000080df9c c000000004133280 c00000000169d200 0000000000000029<br /> GPR04: 00000000ffffefff c000000004132f90 c000000004132f88 0000000000000000<br /> GPR08: c0000000015658f8 c0000000015cd200 c0000000014f57d0 0000000048228283<br /> GPR12: 0000000000000000 c00000003fffe300 0000000020000000 0000000000000000<br /> GPR16: 0000000000000000 0000000113fc4a40 0000000000000005 0000000113fcfb80<br /> GPR20: 000001000f7283b0 0000000000000000 c000000000e4a588 c000000000e4a5b0<br /> GPR24: 0000000000000001 00000000000a0000 c008000000db0168 c0000000021f6ec0<br /> GPR28: c0000000016d65a8 c000000004b36460 0000000000000000 c0000000016d64b0<br /> NIP [c00000000080dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0<br /> [c000000004133280] [c00000000080df9c] do_remove_conflicting_framebuffers+0x17c/0x1d0 (unreliable)<br /> [c000000004133350] [c00000000080e4d0] remove_conflicting_framebuffers+0x60/0x150<br /> [c0000000041333a0] [c00000000080e6f4] remove_conflicting_pci_framebuffers+0x134/0x1b0<br /> [c000000004133450] [c008000000e70438] drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm]<br /> [c000000004133490] [c008000000da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs]<br /> [...]<br /> [c000000004133db0] [c00000000002aaa0] system_call_exception+0x170/0x2d0<br /> [c000000004133e10] [c00000000000c3cc] system_call_common+0xec/0x250<br /> <br /> The bug [1] was introduced by commit 27599aacbaef ("fbdev: Hot-unplug<br /> firmware fb devices on forced removal"). Most firmware framebuffers<br /> have an underlying platform device, which can be hot-unplugged<br /> before loading the native graphics driver. OF framebuffers do not<br /> (yet) have that device. Fix the code by unregistering the framebuffer<br /> as before without a hot unplug.<br /> <br /> Tested with 5.17 on qemu ppc64le emulation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: sata_dwc_460ex: Fix crash due to OOB write<br /> <br /> the driver uses libata&amp;#39;s "tag" values from in various arrays.<br /> Since the mentioned patch bumped the ATA_TAG_INTERNAL to 32,<br /> the value of the SATA_DWC_QCMD_MAX needs to account for that.<br /> <br /> Otherwise ATA_TAG_INTERNAL usage cause similar crashes like<br /> this as reported by Tice Rex on the OpenWrt Forum and<br /> reproduced (with symbols) here:<br /> <br /> | BUG: Kernel NULL pointer dereference at 0x00000000<br /> | Faulting instruction address: 0xc03ed4b8<br /> | Oops: Kernel access of bad area, sig: 11 [#1]<br /> | BE PAGE_SIZE=4K PowerPC 44x Platform<br /> | CPU: 0 PID: 362 Comm: scsi_eh_1 Not tainted 5.4.163 #0<br /> | NIP: c03ed4b8 LR: c03d27e8 CTR: c03ed36c<br /> | REGS: cfa59950 TRAP: 0300 Not tainted (5.4.163)<br /> | MSR: 00021000 CR: 42000222 XER: 00000000<br /> | DEAR: 00000000 ESR: 00000000<br /> | GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...]<br /> | [..]<br /> | NIP [c03ed4b8] sata_dwc_qc_issue+0x14c/0x254<br /> | LR [c03d27e8] ata_qc_issue+0x1c8/0x2dc<br /> | Call Trace:<br /> | [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (unreliable)<br /> | [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc<br /> | [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524<br /> | [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0<br /> | [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204<br /> | [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130<br /> | [...]<br /> <br /> This is because sata_dwc_dma_xfer_complete() NULLs the<br /> dma_pending&amp;#39;s next neighbour "chan" (a *dma_chan struct) in<br /> this &amp;#39;32&amp;#39; case right here (line ~735):<br /> &gt; hsdevp-&gt;dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE;<br /> <br /> Then the next time, a dma gets issued; dma_dwc_xfer_setup() passes<br /> the NULL&amp;#39;d hsdevp-&gt;chan to the dmaengine_slave_config() which then<br /> causes the crash.<br /> <br /> With this patch, SATA_DWC_QCMD_MAX is now set to ATA_MAX_QUEUE + 1.<br /> This avoids the OOB. But please note, there was a worthwhile discussion<br /> on what ATA_TAG_INTERNAL and ATA_MAX_QUEUE is. And why there should not<br /> be a "fake" 33 command-long queue size.<br /> <br /> Ideally, the dw driver should account for the ATA_TAG_INTERNAL.<br /> In Damien Le Moal&amp;#39;s words: "... having looked at the driver, it<br /> is a bigger change than just faking a 33rd "tag" that is in fact<br /> not a command tag at all."<br /> <br /> BugLink: https://github.com/openwrt/openwrt/issues/9505

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix qgroup reserve overflow the qgroup limit<br /> <br /> We use extent_changeset-&gt;bytes_changed in qgroup_reserve_data() to record<br /> how many bytes we set for EXTENT_QGROUP_RESERVED state. Currently the<br /> bytes_changed is set as "unsigned int", and it will overflow if we try to<br /> fallocate a range larger than 4GiB. The result is we reserve less bytes<br /> and eventually break the qgroup limit.<br /> <br /> Unlike regular buffered/direct write, which we use one changeset for<br /> each ordered extent, which can never be larger than 256M. For<br /> fallocate, we use one changeset for the whole range, thus it no longer<br /> respects the 256M per extent limit, and caused the problem.<br /> <br /> The following example test script reproduces the problem:<br /> <br /> $ cat qgroup-overflow.sh<br /> #!/bin/bash<br /> <br /> DEV=/dev/sdj<br /> MNT=/mnt/sdj<br /> <br /> mkfs.btrfs -f $DEV<br /> mount $DEV $MNT<br /> <br /> # Set qgroup limit to 2GiB.<br /> btrfs quota enable $MNT<br /> btrfs qgroup limit 2G $MNT<br /> <br /> # Try to fallocate a 3GiB file. This should fail.<br /> echo<br /> echo "Try to fallocate a 3GiB file..."<br /> fallocate -l 3G $MNT/3G.file<br /> <br /> # Try to fallocate a 5GiB file.<br /> echo<br /> echo "Try to fallocate a 5GiB file..."<br /> fallocate -l 5G $MNT/5G.file<br /> <br /> # See we break the qgroup limit.<br /> echo<br /> sync<br /> btrfs qgroup show -r $MNT<br /> <br /> umount $MNT<br /> <br /> When running the test:<br /> <br /> $ ./qgroup-overflow.sh<br /> (...)<br /> <br /> Try to fallocate a 3GiB file...<br /> fallocate: fallocate failed: Disk quota exceeded<br /> <br /> Try to fallocate a 5GiB file...<br /> <br /> qgroupid         rfer         excl     max_rfer<br /> --------         ----         ----     --------<br /> 0/5           5.00GiB      5.00GiB      2.00GiB<br /> <br /> Since we have no control of how bytes_changed is used, it&amp;#39;s better to<br /> set it to u64.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: nci: add flush_workqueue to prevent uaf<br /> <br /> Our detector found a concurrent use-after-free bug when detaching an<br /> NCI device. The main reason for this bug is the unexpected scheduling<br /> between the used delayed mechanism (timer and workqueue).<br /> <br /> The race can be demonstrated below:<br /> <br /> Thread-1 Thread-2<br /> | nci_dev_up()<br /> | nci_open_device()<br /> | __nci_request(nci_reset_req)<br /> | nci_send_cmd<br /> | queue_work(cmd_work)<br /> nci_unregister_device() |<br /> nci_close_device() | ...<br /> del_timer_sync(cmd_timer)[1] |<br /> ... | Worker<br /> nci_free_device() | nci_cmd_work()<br /> kfree(ndev)[3] | mod_timer(cmd_timer)[2]<br /> <br /> In short, the cleanup routine thought that the cmd_timer has already<br /> been detached by [1] but the mod_timer can re-attach the timer [2], even<br /> it is already released [3], resulting in UAF.<br /> <br /> This UAF is easy to trigger, crash trace by POC is like below<br /> <br /> [ 66.703713] ==================================================================<br /> [ 66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490<br /> [ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33<br /> [ 66.703974]<br /> [ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5<br /> [ 66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work<br /> [ 66.703974] Call Trace:<br /> [ 66.703974] <br /> [ 66.703974] dump_stack_lvl+0x57/0x7d<br /> [ 66.703974] print_report.cold+0x5e/0x5db<br /> [ 66.703974] ? enqueue_timer+0x448/0x490<br /> [ 66.703974] kasan_report+0xbe/0x1c0<br /> [ 66.703974] ? enqueue_timer+0x448/0x490<br /> [ 66.703974] enqueue_timer+0x448/0x490<br /> [ 66.703974] __mod_timer+0x5e6/0xb80<br /> [ 66.703974] ? mark_held_locks+0x9e/0xe0<br /> [ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0<br /> [ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410<br /> [ 66.703974] ? queue_work_on+0x61/0x80<br /> [ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130<br /> [ 66.703974] process_one_work+0x8bb/0x1510<br /> [ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410<br /> [ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230<br /> [ 66.703974] ? rwlock_bug.part.0+0x90/0x90<br /> [ 66.703974] ? _raw_spin_lock_irq+0x41/0x50<br /> [ 66.703974] worker_thread+0x575/0x1190<br /> [ 66.703974] ? process_one_work+0x1510/0x1510<br /> [ 66.703974] kthread+0x2a0/0x340<br /> [ 66.703974] ? kthread_complete_and_exit+0x20/0x20<br /> [ 66.703974] ret_from_fork+0x22/0x30<br /> [ 66.703974] <br /> [ 66.703974]<br /> [ 66.703974] Allocated by task 267:<br /> [ 66.703974] kasan_save_stack+0x1e/0x40<br /> [ 66.703974] __kasan_kmalloc+0x81/0xa0<br /> [ 66.703974] nci_allocate_device+0xd3/0x390<br /> [ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0<br /> [ 66.703974] nfcmrvl_nci_uart_open+0xf2/0x1dd<br /> [ 66.703974] nci_uart_tty_ioctl+0x2c3/0x4a0<br /> [ 66.703974] tty_ioctl+0x764/0x1310<br /> [ 66.703974] __x64_sys_ioctl+0x122/0x190<br /> [ 66.703974] do_syscall_64+0x3b/0x90<br /> [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 66.703974]<br /> [ 66.703974] Freed by task 406:<br /> [ 66.703974] kasan_save_stack+0x1e/0x40<br /> [ 66.703974] kasan_set_track+0x21/0x30<br /> [ 66.703974] kasan_set_free_info+0x20/0x30<br /> [ 66.703974] __kasan_slab_free+0x108/0x170<br /> [ 66.703974] kfree+0xb0/0x330<br /> [ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0<br /> [ 66.703974] nci_uart_tty_close+0xdf/0x180<br /> [ 66.703974] tty_ldisc_kill+0x73/0x110<br /> [ 66.703974] tty_ldisc_hangup+0x281/0x5b0<br /> [ 66.703974] __tty_hangup.part.0+0x431/0x890<br /> [ 66.703974] tty_release+0x3a8/0xc80<br /> [ 66.703974] __fput+0x1f0/0x8c0<br /> [ 66.703974] task_work_run+0xc9/0x170<br /> [ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0<br /> [ 66.703974] syscall_exit_to_user_mode+0x19/0x50<br /> [ 66.703974] do_syscall_64+0x48/0x90<br /> [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0x<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: Fix NULL pointer dereference in smc_pnet_find_ib()<br /> <br /> dev_name() was called with dev.parent as argument but without to<br /> NULL-check it before.<br /> Solve this by checking the pointer before the call to dev_name().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: stmmac: fix altr_tse_pcs function when using a fixed-link<br /> <br /> When using a fixed-link, the altr_tse_pcs driver crashes<br /> due to null-pointer dereference as no phy_device is provided to<br /> tse_pcs_fix_mac_speed function. Fix this by adding a check for<br /> phy_dev before calling the tse_pcs_fix_mac_speed() function.<br /> <br /> Also clean up the tse_pcs_fix_mac_speed function a bit. There is<br /> no need to check for splitter_base and sgmii_adapter_base<br /> because the driver will fail if these 2 variables are not<br /> derived from the device tree.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: Fix KASAN slab-out-of-bounds in cachefiles_set_volume_xattr<br /> <br /> Use the actual length of volume coherency data when setting the<br /> xattr to avoid the following KASAN report.<br /> <br /> BUG: KASAN: slab-out-of-bounds in cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles]<br /> Write of size 4 at addr ffff888101e02af4 by task kworker/6:0/1347<br /> <br /> CPU: 6 PID: 1347 Comm: kworker/6:0 Kdump: loaded Not tainted 5.18.0-rc1-nfs-fscache-netfs+ #13<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-4.fc34 04/01/2014<br /> Workqueue: events fscache_create_volume_work [fscache]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x45/0x5a<br /> print_report.cold+0x5e/0x5db<br /> ? __lock_text_start+0x8/0x8<br /> ? cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles]<br /> kasan_report+0xab/0x120<br /> ? cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles]<br /> kasan_check_range+0xf5/0x1d0<br /> memcpy+0x39/0x60<br /> cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles]<br /> cachefiles_acquire_volume+0x2be/0x500 [cachefiles]<br /> ? __cachefiles_free_volume+0x90/0x90 [cachefiles]<br /> fscache_create_volume_work+0x68/0x160 [fscache]<br /> process_one_work+0x3b7/0x6a0<br /> worker_thread+0x2c4/0x650<br /> ? process_one_work+0x6a0/0x6a0<br /> kthread+0x16c/0x1a0<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br /> <br /> <br /> Allocated by task 1347:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_kmalloc+0x81/0xa0<br /> cachefiles_set_volume_xattr+0x76/0x350 [cachefiles]<br /> cachefiles_acquire_volume+0x2be/0x500 [cachefiles]<br /> fscache_create_volume_work+0x68/0x160 [fscache]<br /> process_one_work+0x3b7/0x6a0<br /> worker_thread+0x2c4/0x650<br /> kthread+0x16c/0x1a0<br /> ret_from_fork+0x22/0x30<br /> <br /> The buggy address belongs to the object at ffff888101e02af0<br /> which belongs to the cache kmalloc-8 of size 8<br /> The buggy address is located 4 bytes inside of<br /> 8-byte region [ffff888101e02af0, ffff888101e02af8)<br /> <br /> The buggy address belongs to the physical page:<br /> page:00000000a2292d70 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x101e02<br /> flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff)<br /> raw: 0017ffffc0000200 0000000000000000 dead000000000001 ffff888100042280<br /> raw: 0000000000000000 0000000080660066 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff888101e02980: fc 00 fc fc fc fc 00 fc fc fc fc 00 fc fc fc fc<br /> ffff888101e02a00: 00 fc fc fc fc 00 fc fc fc fc 00 fc fc fc fc 00<br /> &gt;ffff888101e02a80: fc fc fc fc 00 fc fc fc fc 00 fc fc fc fc 04 fc<br /> ^<br /> ffff888101e02b00: fc fc fc 00 fc fc fc fc 00 fc fc fc fc 00 fc fc<br /> ffff888101e02b80: fc fc 00 fc fc fc fc 00 fc fc fc fc 00 fc fc fc<br /> ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: arfs: fix use-after-free when freeing @rx_cpu_rmap<br /> <br /> The CI testing bots triggered the following splat:<br /> <br /> [ 718.203054] BUG: KASAN: use-after-free in free_irq_cpu_rmap+0x53/0x80<br /> [ 718.206349] Read of size 4 at addr ffff8881bd127e00 by task sh/20834<br /> [ 718.212852] CPU: 28 PID: 20834 Comm: sh Kdump: loaded Tainted: G S W IOE 5.17.0-rc8_nextqueue-devqueue-02643-g23f3121aca93 #1<br /> [ 718.219695] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0012.070720200218 07/07/2020<br /> [ 718.223418] Call Trace:<br /> [ 718.227139]<br /> [ 718.230783] dump_stack_lvl+0x33/0x42<br /> [ 718.234431] print_address_description.constprop.9+0x21/0x170<br /> [ 718.238177] ? free_irq_cpu_rmap+0x53/0x80<br /> [ 718.241885] ? free_irq_cpu_rmap+0x53/0x80<br /> [ 718.245539] kasan_report.cold.18+0x7f/0x11b<br /> [ 718.249197] ? free_irq_cpu_rmap+0x53/0x80<br /> [ 718.252852] free_irq_cpu_rmap+0x53/0x80<br /> [ 718.256471] ice_free_cpu_rx_rmap.part.11+0x37/0x50 [ice]<br /> [ 718.260174] ice_remove_arfs+0x5f/0x70 [ice]<br /> [ 718.263810] ice_rebuild_arfs+0x3b/0x70 [ice]<br /> [ 718.267419] ice_rebuild+0x39c/0xb60 [ice]<br /> [ 718.270974] ? asm_sysvec_apic_timer_interrupt+0x12/0x20<br /> [ 718.274472] ? ice_init_phy_user_cfg+0x360/0x360 [ice]<br /> [ 718.278033] ? delay_tsc+0x4a/0xb0<br /> [ 718.281513] ? preempt_count_sub+0x14/0xc0<br /> [ 718.284984] ? delay_tsc+0x8f/0xb0<br /> [ 718.288463] ice_do_reset+0x92/0xf0 [ice]<br /> [ 718.292014] ice_pci_err_resume+0x91/0xf0 [ice]<br /> [ 718.295561] pci_reset_function+0x53/0x80<br /> <br /> [ 718.393035] Allocated by task 690:<br /> [ 718.433497] Freed by task 20834:<br /> [ 718.495688] Last potentially related work creation:<br /> [ 718.568966] The buggy address belongs to the object at ffff8881bd127e00<br /> which belongs to the cache kmalloc-96 of size 96<br /> [ 718.574085] The buggy address is located 0 bytes inside of<br /> 96-byte region [ffff8881bd127e00, ffff8881bd127e60)<br /> [ 718.579265] The buggy address belongs to the page:<br /> [ 718.598905] Memory state around the buggy address:<br /> [ 718.601809] ffff8881bd127d00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> [ 718.604796] ffff8881bd127d80: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc<br /> [ 718.607794] &gt;ffff8881bd127e00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> [ 718.610811] ^<br /> [ 718.613819] ffff8881bd127e80: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc<br /> [ 718.617107] ffff8881bd127f00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> <br /> This is due to that free_irq_cpu_rmap() is always being called<br /> *after* (devm_)free_irq() and thus it tries to work with IRQ descs<br /> already freed. For example, on device reset the driver frees the<br /> rmap right before allocating a new one (the splat above).<br /> Make rmap creation and freeing function symmetrical with<br /> {request,free}_irq() calls i.e. do that on ifup/ifdown instead<br /> of device probe/remove/resume. These operations can be performed<br /> independently from the actual device aRFS configuration.<br /> Also, make sure ice_vsi_free_irq() clears IRQ affinity notifiers<br /> only when aRFS is disabled -- otherwise, CPU rmap sets and clears<br /> its own and they must not be touched manually.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: unmark inode in use in error path<br /> <br /> Unmark inode in use if error encountered. If the in-use flag leakage<br /> occurs in cachefiles_open_file(), Cachefiles will complain "Inode<br /> already in use" when later another cookie with the same index key is<br /> looked up.<br /> <br /> If the in-use flag leakage occurs in cachefiles_create_tmpfile(), though<br /> the "Inode already in use" warning won&amp;#39;t be triggered, fix the leakage<br /> anyway.