Vulnerabilities

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 /> drm/panel: ili9341: fix optional regulator handling<br /> <br /> If the optional regulator lookup fails, reset the pointer to NULL.<br /> Other functions such as mipi_dbi_poweron_reset_conditional() only do<br /> a NULL pointer check and will otherwise dereference the error pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: Restrict usage of GPIO chip irq members before initialization<br /> <br /> GPIO chip irq members are exposed before they could be completely<br /> initialized and this leads to race conditions.<br /> <br /> One such issue was observed for the gc-&gt;irq.domain variable which<br /> was accessed through the I2C interface in gpiochip_to_irq() before<br /> it could be initialized by gpiochip_add_irqchip(). This resulted in<br /> Kernel NULL pointer dereference.<br /> <br /> Following are the logs for reference :-<br /> <br /> kernel: Call Trace:<br /> kernel: gpiod_to_irq+0x53/0x70<br /> kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0<br /> kernel: i2c_acpi_get_irq+0xc0/0xd0<br /> kernel: i2c_device_probe+0x28a/0x2a0<br /> kernel: really_probe+0xf2/0x460<br /> kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0<br /> <br /> To avoid such scenarios, restrict usage of GPIO chip irq members before<br /> they are completely initialized.

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 /> irqchip/gic-v3: Fix GICR_CTLR.RWP polling<br /> <br /> It turns out that our polling of RWP is totally wrong when checking<br /> for it in the redistributors, as we test the *distributor* bit index,<br /> whereas it is a different bit number in the RDs... Oopsie boo.<br /> <br /> This is embarassing. Not only because it is wrong, but also because<br /> it took *8 years* to notice the blunder...<br /> <br /> Just fix the damn thing.

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 /> 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 /> cifs: potential buffer overflow in handling symlinks<br /> <br /> Smatch printed a warning:<br /> arch/x86/crypto/poly1305_glue.c:198 poly1305_update_arch() error:<br /> __memcpy() &amp;#39;dctx-&gt;buf&amp;#39; too small (16 vs u32max)<br /> <br /> It&amp;#39;s caused because Smatch marks &amp;#39;link_len&amp;#39; as untrusted since it comes<br /> from sscanf(). Add a check to ensure that &amp;#39;link_len&amp;#39; is not larger than<br /> the size of the &amp;#39;link_str&amp;#39; buffer.

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 /> ==================================================================