Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: sf-pdma: pdma_desc memory leak fix<br /> <br /> Commit b2cc5c465c2c ("dmaengine: sf-pdma: Add multithread support for a<br /> DMA channel") changed sf_pdma_prep_dma_memcpy() to unconditionally<br /> allocate a new sf_pdma_desc each time it is called.<br /> <br /> The driver previously recycled descs, by checking the in_use flag, only<br /> allocating additional descs if the existing one was in use. This logic<br /> was removed in commit b2cc5c465c2c ("dmaengine: sf-pdma: Add multithread<br /> support for a DMA channel"), but sf_pdma_free_desc() was not changed to<br /> handle the new behaviour.<br /> <br /> As a result, each time sf_pdma_prep_dma_memcpy() is called, the previous<br /> descriptor is leaked, over time leading to memory starvation:<br /> <br /> unreferenced object 0xffffffe008447300 (size 192):<br /> comm "irq/39-mchp_dsc", pid 343, jiffies 4294906910 (age 981.200s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 ff 00 00 00 00 b8 c1 00 00 00 00 00 00 ................<br /> 00 00 70 08 10 00 00 00 00 00 00 c0 00 00 00 00 ..p.............<br /> backtrace:<br /> [] kmemleak_alloc+0x1e/0x28<br /> [] kmem_cache_alloc+0x11e/0x178<br /> [] sf_pdma_prep_dma_memcpy+0x40/0x112<br /> <br /> Add the missing kfree() to sf_pdma_free_desc(), and remove the redundant<br /> in_use flag.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: set goal start correctly in ext4_mb_normalize_request<br /> <br /> We need to set ac_g_ex to notify the goal start used in<br /> ext4_mb_find_by_goal. Set ac_g_ex instead of ac_f_ex in<br /> ext4_mb_normalize_request.<br /> Besides we should assure goal start is in range [first_data_block,<br /> blocks_count) as ext4_mb_initialize_context does.<br /> <br /> [ Added a check to make sure size is less than ar-&gt;pright; otherwise<br /> we could end up passing an underflowed value of ar-&gt;pright - size to<br /> ext4_get_group_no_and_offset(), which will trigger a BUG_ON later on.<br /> - TYT ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Fix potential memory leaks at error path for UMP open<br /> <br /> The allocation and initialization errors at alloc_midi_urbs() that is<br /> called at MIDI 2.0 / UMP device are supposed to be handled at the<br /> caller side by invoking free_midi_urbs(). However, free_midi_urbs()<br /> loops only for ep-&gt;num_urbs entries, and since ep-&gt;num_entries wasn&amp;#39;t<br /> updated yet at the allocation / init error in alloc_midi_urbs(), this<br /> entry won&amp;#39;t be released.<br /> <br /> The intention of free_midi_urbs() is to release the whole elements, so<br /> change the loop size to NUM_URBS to scan over all elements for fixing<br /> the missed releases.<br /> <br /> Also, the call of free_midi_urbs() is missing at<br /> snd_usb_midi_v2_open(). Although it&amp;#39;ll be released later at<br /> reopen/close or disconnection, it&amp;#39;s better to release immediately at<br /> the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix race between balance and cancel/pause<br /> <br /> Syzbot reported a panic that looks like this:<br /> <br /> assertion failed: fs_info-&gt;exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED, in fs/btrfs/ioctl.c:465<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/messages.c:259!<br /> RIP: 0010:btrfs_assertfail+0x2c/0x30 fs/btrfs/messages.c:259<br /> Call Trace:<br /> <br /> btrfs_exclop_balance fs/btrfs/ioctl.c:465 [inline]<br /> btrfs_ioctl_balance fs/btrfs/ioctl.c:3564 [inline]<br /> btrfs_ioctl+0x531e/0x5b30 fs/btrfs/ioctl.c:4632<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl fs/ioctl.c:856 [inline]<br /> __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The reproducer is running a balance and a cancel or pause in parallel.<br /> The way balance finishes is a bit wonky, if we were paused we need to<br /> save the balance_ctl in the fs_info, but clear it otherwise and cleanup.<br /> However we rely on the return values being specific errors, or having a<br /> cancel request or no pause request. If balance completes and returns 0,<br /> but we have a pause or cancel request we won&amp;#39;t do the appropriate<br /> cleanup, and then the next time we try to start a balance we&amp;#39;ll trip<br /> this ASSERT.<br /> <br /> The error handling is just wrong here, we always want to clean up,<br /> unless we got -ECANCELLED and we set the appropriate pause flag in the<br /> exclusive op. With this patch the reproducer ran for an hour without<br /> tripping, previously it would trip in less than a few minutes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Destroy target device if coalesced MMIO unregistration fails<br /> <br /> Destroy and free the target coalesced MMIO device if unregistering said<br /> device fails. As clearly noted in the code, kvm_io_bus_unregister_dev()<br /> does not destroy the target device.<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff888112a54880 (size 64):<br /> comm "syz-executor.2", pid 5258, jiffies 4297861402 (age 14.129s)<br /> hex dump (first 32 bytes):<br /> 38 c7 67 15 00 c9 ff ff 38 c7 67 15 00 c9 ff ff 8.g.....8.g.....<br /> e0 c7 e1 83 ff ff ff ff 00 30 67 15 00 c9 ff ff .........0g.....<br /> backtrace:<br /> [] kmalloc include/linux/slab.h:556 [inline]<br /> [] kzalloc include/linux/slab.h:690 [inline]<br /> [] kvm_vm_ioctl_register_coalesced_mmio+0x8e/0x3d0 arch/x86/kvm/../../../virt/kvm/coalesced_mmio.c:150<br /> [] kvm_vm_ioctl+0x47d/0x1600 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3323<br /> [] vfs_ioctl fs/ioctl.c:46 [inline]<br /> [] file_ioctl fs/ioctl.c:509 [inline]<br /> [] do_vfs_ioctl+0xbab/0x1160 fs/ioctl.c:696<br /> [] ksys_ioctl+0x76/0xa0 fs/ioctl.c:713<br /> [] __do_sys_ioctl fs/ioctl.c:720 [inline]<br /> [] __se_sys_ioctl fs/ioctl.c:718 [inline]<br /> [] __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718<br /> [] do_syscall_64+0x9f/0x4e0 arch/x86/entry/common.c:290<br /> [] entry_SYSCALL_64_after_hwframe+0x49/0xbe<br /> <br /> BUG: leak checking failed

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rsi: Do not configure WoWlan in shutdown hook if not enabled<br /> <br /> In case WoWlan was never configured during the operation of the system,<br /> the hw-&gt;wiphy-&gt;wowlan_config will be NULL. rsi_config_wowlan() checks<br /> whether wowlan_config is non-NULL and if it is not, then WARNs about it.<br /> The warning is valid, as during normal operation the rsi_config_wowlan()<br /> should only ever be called with non-NULL wowlan_config. In shutdown this<br /> rsi_config_wowlan() should only ever be called if WoWlan was configured<br /> before by the user.<br /> <br /> Add checks for non-NULL wowlan_config into the shutdown hook. While at it,<br /> check whether the wiphy is also non-NULL before accessing wowlan_config .<br /> Drop the single-use wowlan_config variable, just inline it into function<br /> call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> opp: Fix use-after-free in lazy_opp_tables after probe deferral<br /> <br /> When dev_pm_opp_of_find_icc_paths() in _allocate_opp_table() returns<br /> -EPROBE_DEFER, the opp_table is freed again, to wait until all the<br /> interconnect paths are available.<br /> <br /> However, if the OPP table is using required-opps then it may already<br /> have been added to the global lazy_opp_tables list. The error path<br /> does not remove the opp_table from the list again.<br /> <br /> This can cause crashes later when the provider of the required-opps<br /> is added, since we will iterate over OPP tables that have already been<br /> freed. E.g.:<br /> <br /> Unable to handle kernel NULL pointer dereference when read<br /> CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.4.0-rc3<br /> PC is at _of_add_opp_table_v2 (include/linux/of.h:949<br /> drivers/opp/of.c:98 drivers/opp/of.c:344 drivers/opp/of.c:404<br /> drivers/opp/of.c:1032) -&gt; lazy_link_required_opp_table()<br /> <br /> Fix this by calling _of_clear_opp_table() to remove the opp_table from<br /> the list and clear other allocated resources. While at it, also add the<br /> missing mutex_destroy() calls in the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: core: Prevent invalid memory access when there is no parent<br /> <br /> Commit 813665564b3d ("iio: core: Convert to use firmware node handle<br /> instead of OF node") switched the kind of nodes to use for label<br /> retrieval in device registration. Probably an unwanted change in that<br /> commit was that if the device has no parent then NULL pointer is<br /> accessed. This is what happens in the stock IIO dummy driver when a<br /> new entry is created in configfs:<br /> <br /> # mkdir /sys/kernel/config/iio/devices/dummy/foo<br /> BUG: kernel NULL pointer dereference, address: ...<br /> ...<br /> Call Trace:<br /> __iio_device_register<br /> iio_dummy_probe<br /> <br /> Since there seems to be no reason to make a parent device of an IIO<br /> dummy device mandatory, let’s prevent the invalid memory access in<br /> __iio_device_register when the parent device is NULL. With this<br /> change, the IIO dummy driver works fine with configfs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix the error "trying to register non-static key in rxe_cleanup_task"<br /> <br /> In the function rxe_create_qp(), rxe_qp_from_init() is called to<br /> initialize qp, internally things like rxe_init_task are not setup until<br /> rxe_qp_init_req().<br /> <br /> If an error occurred before this point then the unwind will call<br /> rxe_cleanup() and eventually to rxe_qp_do_cleanup()/rxe_cleanup_task()<br /> which will oops when trying to access the uninitialized spinlock.<br /> <br /> If rxe_init_task is not executed, rxe_cleanup_task will not be called.

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 /> scsi: mpi3mr: Fix an issue found by KASAN<br /> <br /> Write only correct size (32 instead of 64 bytes).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix stack overflow when LRO is disabled for virtual interfaces<br /> <br /> When the virtual interface&amp;#39;s feature is updated, it synchronizes the<br /> updated feature for its own lower interface.<br /> This propagation logic should be worked as the iteration, not recursively.<br /> But it works recursively due to the netdev notification unexpectedly.<br /> This problem occurs when it disables LRO only for the team and bonding<br /> interface type.<br /> <br /> team0<br /> |<br /> +------+------+-----+-----+<br /> | | | | |<br /> team1 team2 team3 ... team200<br /> <br /> If team0&amp;#39;s LRO feature is updated, it generates the NETDEV_FEAT_CHANGE<br /> event to its own lower interfaces(team1 ~ team200).<br /> It is worked by netdev_sync_lower_features().<br /> So, the NETDEV_FEAT_CHANGE notification logic of each lower interface<br /> work iteratively.<br /> But generated NETDEV_FEAT_CHANGE event is also sent to the upper<br /> interface too.<br /> upper interface(team0) generates the NETDEV_FEAT_CHANGE event for its own<br /> lower interfaces again.<br /> lower and upper interfaces receive this event and generate this<br /> event again and again.<br /> So, the stack overflow occurs.<br /> <br /> But it is not the infinite loop issue.<br /> Because the netdev_sync_lower_features() updates features before<br /> generating the NETDEV_FEAT_CHANGE event.<br /> Already synchronized lower interfaces skip notification logic.<br /> So, it is just the problem that iteration logic is changed to the<br /> recursive unexpectedly due to the notification mechanism.<br /> <br /> Reproducer:<br /> <br /> ip link add team0 type team<br /> ethtool -K team0 lro on<br /> for i in {1..200}<br /> do<br /> ip link add team$i master team0 type team<br /> ethtool -K team$i lro on<br /> done<br /> <br /> ethtool -K team0 lro off<br /> <br /> In order to fix it, the notifier_ctx member of bonding/team is introduced.