Vulnerabilidades

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: prevent soft lockup while flush writes<br /> <br /> Currently, there is no limit for raid1/raid10 plugged bio. While flushing<br /> writes, raid1 has cond_resched() while raid10 doesn&amp;#39;t, and too many<br /> writes can cause soft lockup.<br /> <br /> Follow up soft lockup can be triggered easily with writeback test for<br /> raid10 with ramdisks:<br /> <br /> watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]<br /> Call Trace:<br /> <br /> call_rcu+0x16/0x20<br /> put_object+0x41/0x80<br /> __delete_object+0x50/0x90<br /> delete_object_full+0x2b/0x40<br /> kmemleak_free+0x46/0xa0<br /> slab_free_freelist_hook.constprop.0+0xed/0x1a0<br /> kmem_cache_free+0xfd/0x300<br /> mempool_free_slab+0x1f/0x30<br /> mempool_free+0x3a/0x100<br /> bio_free+0x59/0x80<br /> bio_put+0xcf/0x2c0<br /> free_r10bio+0xbf/0xf0<br /> raid_end_bio_io+0x78/0xb0<br /> one_write_done+0x8a/0xa0<br /> raid10_end_write_request+0x1b4/0x430<br /> bio_endio+0x175/0x320<br /> brd_submit_bio+0x3b9/0x9b7 [brd]<br /> __submit_bio+0x69/0xe0<br /> submit_bio_noacct_nocheck+0x1e6/0x5a0<br /> submit_bio_noacct+0x38c/0x7e0<br /> flush_pending_writes+0xf0/0x240<br /> raid10d+0xac/0x1ed0<br /> <br /> Fix the problem by adding cond_resched() to raid10 like what raid1 did.<br /> <br /> Note that unlimited plugged bio still need to be optimized, for example,<br /> in the case of lots of dirty pages writeback, this will take lots of<br /> memory and io will spend a long time in plug, hence io latency is bad.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix calltrace warning in amddrm_buddy_fini<br /> <br /> The following call trace is observed when removing the amdgpu driver, which<br /> is caused by that BOs allocated for psp are not freed until removing.<br /> <br /> [61811.450562] RIP: 0010:amddrm_buddy_fini.cold+0x29/0x47 [amddrm_buddy]<br /> [61811.450577] Call Trace:<br /> [61811.450577] <br /> [61811.450579] amdgpu_vram_mgr_fini+0x135/0x1c0 [amdgpu]<br /> [61811.450728] amdgpu_ttm_fini+0x207/0x290 [amdgpu]<br /> [61811.450870] amdgpu_bo_fini+0x27/0xa0 [amdgpu]<br /> [61811.451012] gmc_v9_0_sw_fini+0x4a/0x60 [amdgpu]<br /> [61811.451166] amdgpu_device_fini_sw+0x117/0x520 [amdgpu]<br /> [61811.451306] amdgpu_driver_release_kms+0x16/0x30 [amdgpu]<br /> [61811.451447] devm_drm_dev_init_release+0x4d/0x80 [drm]<br /> [61811.451466] devm_action_release+0x15/0x20<br /> [61811.451469] release_nodes+0x40/0xb0<br /> [61811.451471] devres_release_all+0x9b/0xd0<br /> [61811.451473] __device_release_driver+0x1bb/0x2a0<br /> [61811.451476] driver_detach+0xf3/0x140<br /> [61811.451479] bus_remove_driver+0x6c/0xf0<br /> [61811.451481] driver_unregister+0x31/0x60<br /> [61811.451483] pci_unregister_driver+0x40/0x90<br /> [61811.451486] amdgpu_exit+0x15/0x447 [amdgpu]<br /> <br /> For smu v13_0_2, if the GPU supports xgmi, refer to<br /> <br /> commit f5c7e7797060 ("drm/amdgpu: Adjust removal control flow for smu v13_0_2"),<br /> <br /> it will run gpu recover in AMDGPU_RESET_FOR_DEVICE_REMOVE mode when removing,<br /> which makes all devices in hive list have hw reset but no resume except the<br /> basic ip blocks, then other ip blocks will not call .hw_fini according to<br /> ip_block.status.hw.<br /> <br /> Since psp_free_shared_bufs just includes some software operations, so move<br /> it to psp_sw_fini.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: Fix use after free for wext<br /> <br /> Key information in wext.connect is not reset on (re)connect and can hold<br /> data from a previous connection.<br /> <br /> Reset key data to avoid that drivers or mac80211 incorrectly detect a<br /> WEP connection request and access the freed or already reused memory.<br /> <br /> Additionally optimize cfg80211_sme_connect() and avoid an useless<br /> schedule of conn_work.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: don&amp;#39;t hold ni_lock when calling truncate_setsize()<br /> <br /> syzbot is reporting hung task at do_user_addr_fault() [1], for there is<br /> a silent deadlock between PG_locked bit and ni_lock lock.<br /> <br /> Since filemap_update_page() calls filemap_read_folio() after calling<br /> folio_trylock() which will set PG_locked bit, ntfs_truncate() must not<br /> call truncate_setsize() which will wait for PG_locked bit to be cleared<br /> when holding ni_lock lock.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.