Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/ti-sci: Fix refcount leak in ti_sci_intr_irq_domain_probe<br /> <br /> of_irq_find_parent() returns a node pointer with refcount incremented,<br /> We should use of_node_put() on it when not needed anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Fix uninitialized array access for some pathnames<br /> <br /> For filenames that begin with . and are between 2 and 5 characters long,<br /> UDF charset conversion code would read uninitialized memory in the<br /> output buffer. The only practical impact is that the name may be prepended a<br /> "unification hash" when it is not actually needed but still it is good<br /> to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: bq25890: Fix external_power_changed race<br /> <br /> bq25890_charger_external_power_changed() dereferences bq-&gt;charger,<br /> which gets sets in bq25890_power_supply_init() like this:<br /> <br /> bq-&gt;charger = devm_power_supply_register(bq-&gt;dev, &amp;bq-&gt;desc, &amp;psy_cfg);<br /> <br /> As soon as devm_power_supply_register() has called device_add()<br /> the external_power_changed callback can get called. So there is a window<br /> where bq25890_charger_external_power_changed() may get called while<br /> bq-&gt;charger has not been set yet leading to a NULL pointer dereference.<br /> <br /> This race hits during boot sometimes on a Lenovo Yoga Book 1 yb1-x90f<br /> when the cht_wcove_pwrsrc (extcon) power_supply is done with detecting<br /> the connected charger-type which happens to exactly hit the small window:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000018<br /> <br /> RIP: 0010:__power_supply_is_supplied_by+0xb/0xb0<br /> <br /> Call Trace:<br /> <br /> __power_supply_get_supplier_property+0x19/0x50<br /> class_for_each_device+0xb1/0xe0<br /> power_supply_get_property_from_supplier+0x2e/0x50<br /> bq25890_charger_external_power_changed+0x38/0x1b0 [bq25890_charger]<br /> __power_supply_changed_work+0x30/0x40<br /> class_for_each_device+0xb1/0xe0<br /> power_supply_changed_work+0x5f/0xe0<br /> <br /> <br /> Fixing this is easy. The external_power_changed callback gets passed<br /> the power_supply which will eventually get stored in bq-&gt;charger,<br /> so bq25890_charger_external_power_changed() can simply directly use<br /> the passed in psy argument which is always valid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix null pointer dereference in tracing_err_log_open()<br /> <br /> Fix an issue in function &amp;#39;tracing_err_log_open&amp;#39;.<br /> The function doesn&amp;#39;t call &amp;#39;seq_open&amp;#39; if the file is opened only with<br /> write permissions, which results in &amp;#39;file-&gt;private_data&amp;#39; being left as null.<br /> If we then use &amp;#39;lseek&amp;#39; on that opened file, &amp;#39;seq_lseek&amp;#39; dereferences<br /> &amp;#39;file-&gt;private_data&amp;#39; in &amp;#39;mutex_lock(&amp;m-&gt;lock)&amp;#39;, resulting in a kernel panic.<br /> Writing to this node requires root privileges, therefore this bug<br /> has very little security impact.<br /> <br /> Tracefs node: /sys/kernel/tracing/error_log<br /> <br /> Example Kernel panic:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038<br /> Call trace:<br /> mutex_lock+0x30/0x110<br /> seq_lseek+0x34/0xb8<br /> __arm64_sys_lseek+0x6c/0xb8<br /> invoke_syscall+0x58/0x13c<br /> el0_svc_common+0xc4/0x10c<br /> do_el0_svc+0x24/0x98<br /> el0_svc+0x24/0x88<br /> el0t_64_sync_handler+0x84/0xe4<br /> el0t_64_sync+0x1b4/0x1b8<br /> Code: d503201f aa0803e0 aa1f03e1 aa0103e9 (c8e97d02)<br /> ---[ end trace 561d1b49c12cf8a5 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: ucsi_acpi: Increase the command completion timeout<br /> <br /> Commit 130a96d698d7 ("usb: typec: ucsi: acpi: Increase command<br /> completion timeout value") increased the timeout from 5 seconds<br /> to 60 seconds due to issues related to alternate mode discovery.<br /> <br /> After the alternate mode discovery switch to polled mode<br /> the timeout was reduced, but instead of being set back to<br /> 5 seconds it was reduced to 1 second.<br /> <br /> This is causing problems when using a Lenovo ThinkPad X1 yoga gen7<br /> connected over Type-C to a LG 27UL850-W (charging DP over Type-C).<br /> <br /> When the monitor is already connected at boot the following error<br /> is logged: "PPM init failed (-110)", /sys/class/typec is empty and<br /> on unplugging the NULL pointer deref fixed earlier in this series<br /> happens.<br /> <br /> When the monitor is connected after boot the following error<br /> is logged instead: "GET_CONNECTOR_STATUS failed (-110)".<br /> <br /> Setting the timeout back to 5 seconds fixes both cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/resctrl: Clear staged_config[] before and after it is used<br /> <br /> As a temporary storage, staged_config[] in rdt_domain should be cleared<br /> before and after it is used. The stale value in staged_config[] could<br /> cause an MSR access error.<br /> <br /> Here is a reproducer on a system with 16 usable CLOSIDs for a 15-way L3<br /> Cache (MBA should be disabled if the number of CLOSIDs for MB is less than<br /> 16.) :<br /> mount -t resctrl resctrl -o cdp /sys/fs/resctrl<br /> mkdir /sys/fs/resctrl/p{1..7}<br /> umount /sys/fs/resctrl/<br /> mount -t resctrl resctrl /sys/fs/resctrl<br /> mkdir /sys/fs/resctrl/p{1..8}<br /> <br /> An error occurs when creating resource group named p8:<br /> unchecked MSR access error: WRMSR to 0xca0 (tried to write 0x00000000000007ff) at rIP: 0xffffffff82249142 (cat_wrmsr+0x32/0x60)<br /> Call Trace:<br /> <br /> __flush_smp_call_function_queue+0x11d/0x170<br /> __sysvec_call_function+0x24/0xd0<br /> sysvec_call_function+0x89/0xc0<br /> <br /> <br /> asm_sysvec_call_function+0x16/0x20<br /> <br /> When creating a new resource control group, hardware will be configured<br /> by the following process:<br /> rdtgroup_mkdir()<br /> rdtgroup_mkdir_ctrl_mon()<br /> rdtgroup_init_alloc()<br /> resctrl_arch_update_domains()<br /> <br /> resctrl_arch_update_domains() iterates and updates all resctrl_conf_type<br /> whose have_new_ctrl is true. Since staged_config[] holds the same values as<br /> when CDP was enabled, it will continue to update the CDP_CODE and CDP_DATA<br /> configurations. When group p8 is created, get_config_index() called in<br /> resctrl_arch_update_domains() will return 16 and 17 as the CLOSIDs for<br /> CDP_CODE and CDP_DATA, which will be translated to an invalid register -<br /> 0xca0 in this scenario.<br /> <br /> Fix it by clearing staged_config[] before and after it is used.<br /> <br /> [reinette: re-order commit tags]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: Removed unneeded of_node_put in felix_parse_ports_node<br /> <br /> Remove unnecessary of_node_put from the continue path to prevent<br /> child node from being released twice, which could avoid resource<br /> leak or other unexpected issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/type1: prevent underflow of locked_vm via exec()<br /> <br /> When a vfio container is preserved across exec, the task does not change,<br /> but it gets a new mm with locked_vm=0, and loses the count from existing<br /> dma mappings. If the user later unmaps a dma mapping, locked_vm underflows<br /> to a large unsigned value, and a subsequent dma map request fails with<br /> ENOMEM in __account_locked_vm.<br /> <br /> To avoid underflow, grab and save the mm at the time a dma is mapped.<br /> Use that mm when adjusting locked_vm, rather than re-acquiring the saved<br /> task&amp;#39;s mm, which may have changed. If the saved mm is dead, do nothing.<br /> <br /> locked_vm is incremented for existing mappings in a subsequent patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: add NULL check in xfrm_update_ae_params<br /> <br /> Normally, x-&gt;replay_esn and x-&gt;preplay_esn should be allocated at<br /> xfrm_alloc_replay_state_esn(...) in xfrm_state_construct(...), hence the<br /> xfrm_update_ae_params(...) is okay to update them. However, the current<br /> implementation of xfrm_new_ae(...) allows a malicious user to directly<br /> dereference a NULL pointer and crash the kernel like below.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0<br /> Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774deaf1 #8<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4<br /> RIP: 0010:memcpy_orig+0xad/0x140<br /> Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c<br /> RSP: 0018:ffff888008f57658 EFLAGS: 00000202<br /> RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571<br /> RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818<br /> R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> ? __die+0x1f/0x70<br /> ? page_fault_oops+0x1e8/0x500<br /> ? __pfx_is_prefetch.constprop.0+0x10/0x10<br /> ? __pfx_page_fault_oops+0x10/0x10<br /> ? _raw_spin_unlock_irqrestore+0x11/0x40<br /> ? fixup_exception+0x36/0x460<br /> ? _raw_spin_unlock_irqrestore+0x11/0x40<br /> ? exc_page_fault+0x5e/0xc0<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? xfrm_update_ae_params+0xd1/0x260<br /> ? memcpy_orig+0xad/0x140<br /> ? __pfx__raw_spin_lock_bh+0x10/0x10<br /> xfrm_update_ae_params+0xe7/0x260<br /> xfrm_new_ae+0x298/0x4e0<br /> ? __pfx_xfrm_new_ae+0x10/0x10<br /> ? __pfx_xfrm_new_ae+0x10/0x10<br /> xfrm_user_rcv_msg+0x25a/0x410<br /> ? __pfx_xfrm_user_rcv_msg+0x10/0x10<br /> ? __alloc_skb+0xcf/0x210<br /> ? stack_trace_save+0x90/0xd0<br /> ? filter_irq_stacks+0x1c/0x70<br /> ? __stack_depot_save+0x39/0x4e0<br /> ? __kasan_slab_free+0x10a/0x190<br /> ? kmem_cache_free+0x9c/0x340<br /> ? netlink_recvmsg+0x23c/0x660<br /> ? sock_recvmsg+0xeb/0xf0<br /> ? __sys_recvfrom+0x13c/0x1f0<br /> ? __x64_sys_recvfrom+0x71/0x90<br /> ? do_syscall_64+0x3f/0x90<br /> ? entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> ? copyout+0x3e/0x50<br /> netlink_rcv_skb+0xd6/0x210<br /> ? __pfx_xfrm_user_rcv_msg+0x10/0x10<br /> ? __pfx_netlink_rcv_skb+0x10/0x10<br /> ? __pfx_sock_has_perm+0x10/0x10<br /> ? mutex_lock+0x8d/0xe0<br /> ? __pfx_mutex_lock+0x10/0x10<br /> xfrm_netlink_rcv+0x44/0x50<br /> netlink_unicast+0x36f/0x4c0<br /> ? __pfx_netlink_unicast+0x10/0x10<br /> ? netlink_recvmsg+0x500/0x660<br /> netlink_sendmsg+0x3b7/0x700<br /> <br /> This Null-ptr-deref bug is assigned CVE-2023-3772. And this commit<br /> adds additional NULL check in xfrm_update_ae_params to fix the NPD.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: Fix igb_down hung on surprise removal<br /> <br /> In a setup where a Thunderbolt hub connects to Ethernet and a display<br /> through USB Type-C, users may experience a hung task timeout when they<br /> remove the cable between the PC and the Thunderbolt hub.<br /> This is because the igb_down function is called multiple times when<br /> the Thunderbolt hub is unplugged. For example, the igb_io_error_detected<br /> triggers the first call, and the igb_remove triggers the second call.<br /> The second call to igb_down will block at napi_synchronize.<br /> Here&amp;#39;s the call trace:<br /> __schedule+0x3b0/0xddb<br /> ? __mod_timer+0x164/0x5d3<br /> schedule+0x44/0xa8<br /> schedule_timeout+0xb2/0x2a4<br /> ? run_local_timers+0x4e/0x4e<br /> msleep+0x31/0x38<br /> igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4]<br /> __igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4]<br /> igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4]<br /> __dev_close_many+0x95/0xec<br /> dev_close_many+0x6e/0x103<br /> unregister_netdevice_many+0x105/0x5b1<br /> unregister_netdevice_queue+0xc2/0x10d<br /> unregister_netdev+0x1c/0x23<br /> igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4]<br /> pci_device_remove+0x3f/0x9c<br /> device_release_driver_internal+0xfe/0x1b4<br /> pci_stop_bus_device+0x5b/0x7f<br /> pci_stop_bus_device+0x30/0x7f<br /> pci_stop_bus_device+0x30/0x7f<br /> pci_stop_and_remove_bus_device+0x12/0x19<br /> pciehp_unconfigure_device+0x76/0xe9<br /> pciehp_disable_slot+0x6e/0x131<br /> pciehp_handle_presence_or_link_change+0x7a/0x3f7<br /> pciehp_ist+0xbe/0x194<br /> irq_thread_fn+0x22/0x4d<br /> ? irq_thread+0x1fd/0x1fd<br /> irq_thread+0x17b/0x1fd<br /> ? irq_forced_thread_fn+0x5f/0x5f<br /> kthread+0x142/0x153<br /> ? __irq_get_irqchip_state+0x46/0x46<br /> ? kthread_associate_blkcg+0x71/0x71<br /> ret_from_fork+0x1f/0x30<br /> <br /> In this case, igb_io_error_detected detaches the network interface<br /> and requests a PCIE slot reset, however, the PCIE reset callback is<br /> not being invoked and thus the Ethernet connection breaks down.<br /> As the PCIE error in this case is a non-fatal one, requesting a<br /> slot reset can be avoided.<br /> This patch fixes the task hung issue and preserves Ethernet<br /> connection by ignoring non-fatal PCIE errors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid deadlock in fs reclaim with page writeback<br /> <br /> Ext4 has a filesystem wide lock protecting ext4_writepages() calls to<br /> avoid races with switching of journalled data flag or inode format. This<br /> lock can however cause a deadlock like:<br /> <br /> CPU0 CPU1<br /> <br /> ext4_writepages()<br /> percpu_down_read(sbi-&gt;s_writepages_rwsem);<br /> ext4_change_inode_journal_flag()<br /> percpu_down_write(sbi-&gt;s_writepages_rwsem);<br /> - blocks, all readers block from now on<br /> ext4_do_writepages()<br /> ext4_init_io_end()<br /> kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)<br /> fs_reclaim frees dentry...<br /> dentry_unlink_inode()<br /> iput() - last ref =&gt;<br /> iput_final() - inode dirty =&gt;<br /> write_inode_now()...<br /> ext4_writepages() tries to acquire sbi-&gt;s_writepages_rwsem<br /> and blocks forever<br /> <br /> Make sure we cannot recurse into filesystem reclaim from writeback code<br /> to avoid the deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Pointer may be dereferenced<br /> <br /> Klocwork tool reported pointer &amp;#39;rport&amp;#39; returned from call to function<br /> fc_bsg_to_rport() may be NULL and will be dereferenced.<br /> <br /> Add a fix to validate rport before dereferencing.