Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soundwire: fix enumeration completion<br /> <br /> The soundwire subsystem uses two completion structures that allow<br /> drivers to wait for soundwire device to become enumerated on the bus and<br /> initialised by their drivers, respectively.<br /> <br /> The code implementing the signalling is currently broken as it does not<br /> signal all current and future waiters and also uses the wrong<br /> reinitialisation function, which can potentially lead to memory<br /> corruption if there are still waiters on the queue.<br /> <br /> Not signalling future waiters specifically breaks sound card probe<br /> deferrals as codec drivers can not tell that the soundwire device is<br /> already attached when being reprobed. Some codec runtime PM<br /> implementations suffer from similar problems as waiting for enumeration<br /> during resume can also timeout despite the device already having been<br /> enumerated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: stm32-pwr: fix of_iomap leak<br /> <br /> Smatch reports:<br /> drivers/regulator/stm32-pwr.c:166 stm32_pwr_regulator_probe() warn:<br /> &amp;#39;base&amp;#39; from of_iomap() not released on lines: 151,166.<br /> <br /> In stm32_pwr_regulator_probe(), base is not released<br /> when devm_kzalloc() fails to allocate memory or<br /> devm_regulator_register() fails to register a new regulator device,<br /> which may cause a leak.<br /> <br /> To fix this issue, replace of_iomap() with<br /> devm_platform_ioremap_resource(). devm_platform_ioremap_resource()<br /> is a specialized function for platform devices.<br /> It allows &amp;#39;base&amp;#39; to be automatically released whether the probe<br /> function succeeds or fails.<br /> <br /> Besides, use IS_ERR(base) instead of !base<br /> as the return value of devm_platform_ioremap_resource()<br /> can either be a pointer to the remapped memory or<br /> an ERR_PTR() encoded error code if the operation fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gvt: fix gvt debugfs destroy<br /> <br /> When gvt debug fs is destroyed, need to have a sane check if drm<br /> minor&amp;#39;s debugfs root is still available or not, otherwise in case like<br /> device remove through unbinding, drm minor&amp;#39;s debugfs directory has<br /> already been removed, then intel_gvt_debugfs_clean() would act upon<br /> dangling pointer like below oops.<br /> <br /> i915 0000:00:02.0: Direct firmware load for i915/gvt/vid_0x8086_did_0x1926_rid_0x0a.golden_hw_state failed with error -2<br /> i915 0000:00:02.0: MDEV: Registered<br /> Console: switching to colour dummy device 80x25<br /> i915 0000:00:02.0: MDEV: Unregistering<br /> BUG: kernel NULL pointer dereference, address: 00000000000000a0<br /> PGD 0 P4D 0<br /> Oops: 0002 [#1] PREEMPT SMP PTI<br /> CPU: 2 PID: 2486 Comm: gfx-unbind.sh Tainted: G I 6.1.0-rc8+ #15<br /> Hardware name: Dell Inc. XPS 13 9350/0JXC1H, BIOS 1.13.0 02/10/2020<br /> RIP: 0010:down_write+0x1f/0x90<br /> Code: 1d ff ff 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 53 48 89 fb e8 62 c0 ff ff bf 01 00 00 00 e8 28 5e 31 ff 31 c0 ba 01 00 00 00 48 0f b1 13 75 33 65 48 8b 04 25 c0 bd 01 00 48 89 43 08 bf 01<br /> RSP: 0018:ffff9eb3036ffcc8 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 00000000000000a0 RCX: ffffff8100000000<br /> RDX: 0000000000000001 RSI: 0000000000000064 RDI: ffffffffa48787a8<br /> RBP: ffff9eb3036ffd30 R08: ffffeb1fc45a0608 R09: ffffeb1fc45a05c0<br /> R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000<br /> R13: ffff91acc33fa328 R14: ffff91acc033f080 R15: ffff91acced533e0<br /> FS: 00007f6947bba740(0000) GS:ffff91ae36d00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000000000a0 CR3: 00000001133a2002 CR4: 00000000003706e0<br /> Call Trace:<br /> <br /> simple_recursive_removal+0x9f/0x2a0<br /> ? start_creating.part.0+0x120/0x120<br /> ? _raw_spin_lock+0x13/0x40<br /> debugfs_remove+0x40/0x60<br /> intel_gvt_debugfs_clean+0x15/0x30 [kvmgt]<br /> intel_gvt_clean_device+0x49/0xe0 [kvmgt]<br /> intel_gvt_driver_remove+0x2f/0xb0<br /> i915_driver_remove+0xa4/0xf0<br /> i915_pci_remove+0x1a/0x30<br /> pci_device_remove+0x33/0xa0<br /> device_release_driver_internal+0x1b2/0x230<br /> unbind_store+0xe0/0x110<br /> kernfs_fop_write_iter+0x11b/0x1f0<br /> vfs_write+0x203/0x3d0<br /> ksys_write+0x63/0xe0<br /> do_syscall_64+0x37/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f6947cb5190<br /> Code: 40 00 48 8b 15 71 9c 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d 51 24 0e 00 00 74 17 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89<br /> RSP: 002b:00007ffcbac45a28 EFLAGS: 00000202 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007f6947cb5190<br /> RDX: 000000000000000d RSI: 0000555e35c866a0 RDI: 0000000000000001<br /> RBP: 0000555e35c866a0 R08: 0000000000000002 R09: 0000555e358cb97c<br /> R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000001<br /> R13: 000000000000000d R14: 0000000000000000 R15: 0000555e358cb8e0<br /> <br /> Modules linked in: kvmgt<br /> CR2: 00000000000000a0<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: Protect reconfiguration of sb read-write from racing writes<br /> <br /> The reconfigure / remount code takes a lot of effort to protect<br /> filesystem&amp;#39;s reconfiguration code from racing writes on remounting<br /> read-only. However during remounting read-only filesystem to read-write<br /> mode userspace writes can start immediately once we clear SB_RDONLY<br /> flag. This is inconvenient for example for ext4 because we need to do<br /> some writes to the filesystem (such as preparation of quota files)<br /> before we can take userspace writes so we are clearing SB_RDONLY flag<br /> before we are fully ready to accept userpace writes and syzbot has found<br /> a way to exploit this [1]. Also as far as I&amp;#39;m reading the code<br /> the filesystem remount code was protected from racing writes in the<br /> legacy mount path by the mount&amp;#39;s MNT_READONLY flag so this is relatively<br /> new problem. It is actually fairly easy to protect remount read-write<br /> from racing writes using sb-&gt;s_readonly_remount flag so let&amp;#39;s just do<br /> that instead of having to workaround these races in the filesystem code.<br /> <br /> [1] https://lore.kernel.org/all/00000000000006a0df05f6667499@google.com/T/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qedi: Fix use after free bug in qedi_remove()<br /> <br /> In qedi_probe() we call __qedi_probe() which initializes<br /> &amp;qedi-&gt;recovery_work with qedi_recovery_handler() and<br /> &amp;qedi-&gt;board_disable_work with qedi_board_disable_work().<br /> <br /> When qedi_schedule_recovery_handler() is called, schedule_delayed_work()<br /> will finally start the work.<br /> <br /> In qedi_remove(), which is called to remove the driver, the following<br /> sequence may be observed:<br /> <br /> Fix this by finishing the work before cleanup in qedi_remove().<br /> <br /> CPU0 CPU1<br /> <br /> |qedi_recovery_handler<br /> qedi_remove |<br /> __qedi_remove |<br /> iscsi_host_free |<br /> scsi_host_put |<br /> //free shost |<br /> |iscsi_host_for_each_session<br /> |//use qedi-&gt;shost<br /> <br /> Cancel recovery_work and board_disable_work in __qedi_remove().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver: soc: xilinx: use _safe loop iterator to avoid a use after free<br /> <br /> The hash_for_each_possible() loop dereferences "eve_data" to get the<br /> next item on the list. However the loop frees eve_data so it leads to<br /> a use after free. Use hash_for_each_possible_safe() instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: tegra: xusb: Clear the driver reference in usb-phy dev<br /> <br /> For the dual-role port, it will assign the phy dev to usb-phy dev and<br /> use the port dev driver as the dev driver of usb-phy.<br /> <br /> When we try to destroy the port dev, it will destroy its dev driver<br /> as well. But we did not remove the reference from usb-phy dev. This<br /> might cause the use-after-free issue in KASAN.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: firewire-digi00x: prevent potential use after free<br /> <br /> This code was supposed to return an error code if init_stream()<br /> failed, but it instead freed dg00x-&gt;rx_stream and returned success.<br /> This potentially leads to a use after free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix NULL pointer dereference on fastopen early fallback<br /> <br /> In case of early fallback to TCP, subflow_syn_recv_sock() deletes<br /> the subflow context before returning the newly allocated sock to<br /> the caller.<br /> <br /> The fastopen path does not cope with the above unconditionally<br /> dereferencing the subflow context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Add preempt_count_{sub,add} into btf id deny list<br /> <br /> The recursion check in __bpf_prog_enter* and __bpf_prog_exit*<br /> leave preempt_count_{sub,add} unprotected. When attaching trampoline to<br /> them we get panic as follows,<br /> <br /> [ 867.843050] BUG: TASK stack guard page was hit at 0000000009d325cf (stack is 0000000046a46a15..00000000537e7b28)<br /> [ 867.843064] stack guard page: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 867.843067] CPU: 8 PID: 11009 Comm: trace Kdump: loaded Not tainted 6.2.0+ #4<br /> [ 867.843100] Call Trace:<br /> [ 867.843101] <br /> [ 867.843104] asm_exc_int3+0x3a/0x40<br /> [ 867.843108] RIP: 0010:preempt_count_sub+0x1/0xa0<br /> [ 867.843135] __bpf_prog_enter_recur+0x17/0x90<br /> [ 867.843148] bpf_trampoline_6442468108_0+0x2e/0x1000<br /> [ 867.843154] ? preempt_count_sub+0x1/0xa0<br /> [ 867.843157] preempt_count_sub+0x5/0xa0<br /> [ 867.843159] ? migrate_enable+0xac/0xf0<br /> [ 867.843164] __bpf_prog_exit_recur+0x2d/0x40<br /> [ 867.843168] bpf_trampoline_6442468108_0+0x55/0x1000<br /> ...<br /> [ 867.843788] preempt_count_sub+0x5/0xa0<br /> [ 867.843793] ? migrate_enable+0xac/0xf0<br /> [ 867.843829] __bpf_prog_exit_recur+0x2d/0x40<br /> [ 867.843837] BUG: IRQ stack guard page was hit at 0000000099bd8228 (stack is 00000000b23e2bc4..000000006d95af35)<br /> [ 867.843841] BUG: IRQ stack guard page was hit at 000000005ae07924 (stack is 00000000ffd69623..0000000014eb594c)<br /> [ 867.843843] BUG: IRQ stack guard page was hit at 00000000028320f0 (stack is 00000000034b6438..0000000078d1bcec)<br /> [ 867.843842] bpf_trampoline_6442468108_0+0x55/0x1000<br /> ...<br /> <br /> That is because in __bpf_prog_exit_recur, the preempt_count_{sub,add} are<br /> called after prog-&gt;active is decreased.<br /> <br /> Fixing this by adding these two functions into btf ids deny list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubi: Fix possible null-ptr-deref in ubi_free_volume()<br /> <br /> It willl cause null-ptr-deref in the following case:<br /> <br /> uif_init()<br /> ubi_add_volume()<br /> cdev_add() -&gt; if it fails, call kill_volumes()<br /> device_register()<br /> <br /> kill_volumes() -&gt; if ubi_add_volume() fails call this function<br /> ubi_free_volume()<br /> cdev_del()<br /> device_unregister() -&gt; trying to delete a not added device,<br /> it causes null-ptr-deref<br /> <br /> So in ubi_free_volume(), it delete devices whether they are added<br /> or not, it will causes null-ptr-deref.<br /> <br /> Handle the error case whlie calling ubi_add_volume() to fix this<br /> problem. If add volume fails, set the corresponding vol to null,<br /> so it can not be accessed in kill_volumes() and release the<br /> resource in ubi_add_volume() error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-cgroup: hold queue_lock when removing blkg-&gt;q_node<br /> <br /> When blkg is removed from q-&gt;blkg_list from blkg_free_workfn(), queue_lock<br /> has to be held, otherwise, all kinds of bugs(list corruption, hard lockup,<br /> ..) can be triggered from blkg_destroy_all().