Vulnerabilities

With the aim of informing, warning and helping professionals with the latest security vulnerabilities in technology systems, we have made a database available for users interested in this information, which is in Spanish and includes all of the latest documented and recognised vulnerabilities.

This repository, with over 75,000 registers, is based on the information from the NVD (National Vulnerability Database) – by virtue of a partnership agreement – through which INCIBE translates the included information into Spanish.

On occasions this list will show vulnerabilities that have still not been translated, as they are added while the INCIBE team is still carrying out the translation process. The CVE  (Common Vulnerabilities and Exposures) Standard for Information Security Vulnerability Names is used with the aim to support the exchange of information between different tools and databases.

All vulnerabilities collected are linked to different information sources, as well as available patches or solutions provided by manufacturers and developers. It is possible to carry out advanced searches, as there is the option to select different criteria to narrow down the results, some examples being vulnerability types, manufacturers and impact levels, among others.

Through RSS feeds or Newsletters we can be informed daily about the latest vulnerabilities added to the repository. Below there is a list, updated daily, where you can discover the latest vulnerabilities.

CVE-2025-21909

Publication date:
01/04/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: nl80211: reject cooked mode if it is set along with other flags<br /> <br /> It is possible to set both MONITOR_FLAG_COOK_FRAMES and MONITOR_FLAG_ACTIVE<br /> flags simultaneously on the same monitor interface from the userspace. This<br /> causes a sub-interface to be created with no IEEE80211_SDATA_IN_DRIVER bit<br /> set because the monitor interface is in the cooked state and it takes<br /> precedence over all other states. When the interface is then being deleted<br /> the kernel calls WARN_ONCE() from check_sdata_in_driver() because of missing<br /> that bit.<br /> <br /> Fix this by rejecting MONITOR_FLAG_COOK_FRAMES if it is set along with<br /> other flags.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Severity CVSS v4.0: Pending analysis
Last modification:
01/04/2025

CVE-2025-21910

Publication date:
01/04/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: regulatory: improve invalid hints checking<br /> <br /> Syzbot keeps reporting an issue [1] that occurs when erroneous symbols<br /> sent from userspace get through into user_alpha2[] via<br /> regulatory_hint_user() call. Such invalid regulatory hints should be<br /> rejected.<br /> <br /> While a sanity check from commit 47caf685a685 ("cfg80211: regulatory:<br /> reject invalid hints") looks to be enough to deter these very cases,<br /> there is a way to get around it due to 2 reasons.<br /> <br /> 1) The way isalpha() works, symbols other than latin lower and<br /> upper letters may be used to determine a country/domain.<br /> For instance, greek letters will also be considered upper/lower<br /> letters and for such characters isalpha() will return true as well.<br /> However, ISO-3166-1 alpha2 codes should only hold latin<br /> characters.<br /> <br /> 2) While processing a user regulatory request, between<br /> reg_process_hint_user() and regulatory_hint_user() there happens to<br /> be a call to queue_regulatory_request() which modifies letters in<br /> request-&gt;alpha2[] with toupper(). This works fine for latin symbols,<br /> less so for weird letter characters from the second part of _ctype[].<br /> <br /> Syzbot triggers a warning in is_user_regdom_saved() by first sending<br /> over an unexpected non-latin letter that gets malformed by toupper()<br /> into a character that ends up failing isalpha() check.<br /> <br /> Prevent this by enhancing is_an_alpha2() to ensure that incoming<br /> symbols are latin letters and nothing else.<br /> <br /> [1] Syzbot report:<br /> ------------[ cut here ]------------<br /> Unexpected user alpha2: A�<br /> WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 is_user_regdom_saved net/wireless/reg.c:440 [inline]<br /> WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_alpha2 net/wireless/reg.c:3424 [inline]<br /> WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 964 Comm: kworker/1:2 Not tainted 6.12.0-rc5-syzkaller-00044-gc1e939a21eb1 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Workqueue: events_power_efficient crda_timeout_work<br /> RIP: 0010:is_user_regdom_saved net/wireless/reg.c:440 [inline]<br /> RIP: 0010:restore_alpha2 net/wireless/reg.c:3424 [inline]<br /> RIP: 0010:restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516<br /> ...<br /> Call Trace:<br /> <br /> crda_timeout_work+0x27/0x50 net/wireless/reg.c:542<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310<br /> worker_thread+0x870/0xd30 kernel/workqueue.c:3391<br /> kthread+0x2f2/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br />
Severity CVSS v4.0: Pending analysis
Last modification:
01/04/2025

CVE-2025-21913

Publication date:
01/04/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/amd_nb: Use rdmsr_safe() in amd_get_mmconfig_range()<br /> <br /> Xen doesn&amp;#39;t offer MSR_FAM10H_MMIO_CONF_BASE to all guests. This results<br /> in the following warning:<br /> <br /> unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xen_do_read_msr+0x7f/0xa0)<br /> Call Trace:<br /> xen_read_msr+0x1e/0x30<br /> amd_get_mmconfig_range+0x2b/0x80<br /> quirk_amd_mmconfig_area+0x28/0x100<br /> pnp_fixup_device+0x39/0x50<br /> __pnp_add_device+0xf/0x150<br /> pnp_add_device+0x3d/0x100<br /> pnpacpi_add_device_handler+0x1f9/0x280<br /> acpi_ns_get_device_callback+0x104/0x1c0<br /> acpi_ns_walk_namespace+0x1d0/0x260<br /> acpi_get_devices+0x8a/0xb0<br /> pnpacpi_init+0x50/0x80<br /> do_one_initcall+0x46/0x2e0<br /> kernel_init_freeable+0x1da/0x2f0<br /> kernel_init+0x16/0x1b0<br /> ret_from_fork+0x30/0x50<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> based on quirks for a "PNP0c01" device. Treating MMCFG as disabled is the<br /> right course of action, so no change is needed there.<br /> <br /> This was most likely exposed by fixing the Xen MSR accessors to not be<br /> silently-safe.
Severity CVSS v4.0: Pending analysis
Last modification:
01/04/2025

CVE-2025-21914

Publication date:
01/04/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slimbus: messaging: Free transaction ID in delayed interrupt scenario<br /> <br /> In case of interrupt delay for any reason, slim_do_transfer()<br /> returns timeout error but the transaction ID (TID) is not freed.<br /> This results into invalid memory access inside<br /> qcom_slim_ngd_rx_msgq_cb() due to invalid TID.<br /> <br /> Fix the issue by freeing the TID in slim_do_transfer() before<br /> returning timeout error to avoid invalid memory access.<br /> <br /> Call trace:<br /> __memcpy_fromio+0x20/0x190<br /> qcom_slim_ngd_rx_msgq_cb+0x130/0x290 [slim_qcom_ngd_ctrl]<br /> vchan_complete+0x2a0/0x4a0<br /> tasklet_action_common+0x274/0x700<br /> tasklet_action+0x28/0x3c<br /> _stext+0x188/0x620<br /> run_ksoftirqd+0x34/0x74<br /> smpboot_thread_fn+0x1d8/0x464<br /> kthread+0x178/0x238<br /> ret_from_fork+0x10/0x20<br /> Code: aa0003e8 91000429 f100044a 3940002b (3800150b)<br /> ---[ end trace 0fe00bec2b975c99 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception in interrupt.
Severity CVSS v4.0: Pending analysis
Last modification:
01/04/2025

CVE-2025-21908

Publication date:
01/04/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: fix nfs_release_folio() to not deadlock via kcompactd writeback<br /> <br /> Add PF_KCOMPACTD flag and current_is_kcompactd() helper to check for it so<br /> nfs_release_folio() can skip calling nfs_wb_folio() from kcompactd.<br /> <br /> Otherwise NFS can deadlock waiting for kcompactd enduced writeback which<br /> recurses back to NFS (which triggers writeback to NFSD via NFS loopback<br /> mount on the same host, NFSD blocks waiting for XFS&amp;#39;s call to<br /> __filemap_get_folio):<br /> <br /> 6070.550357] INFO: task kcompactd0:58 blocked for more than 4435 seconds.<br /> <br /> {---<br /> [58] "kcompactd0"<br /> [] folio_wait_bit+0xe8/0x200<br /> [] folio_wait_writeback+0x2b/0x80<br /> [] nfs_wb_folio+0x80/0x1b0 [nfs]<br /> [] nfs_release_folio+0x68/0x130 [nfs]<br /> [] split_huge_page_to_list_to_order+0x362/0x840<br /> [] migrate_pages_batch+0x43d/0xb90<br /> [] migrate_pages_sync+0x9a/0x240<br /> [] migrate_pages+0x93c/0x9f0<br /> [] compact_zone+0x8e2/0x1030<br /> [] compact_node+0xdb/0x120<br /> [] kcompactd+0x121/0x2e0<br /> [] kthread+0xcf/0x100<br /> [] ret_from_fork+0x31/0x40<br /> [] ret_from_fork_asm+0x1a/0x30<br /> ---}<br /> <br /> [akpm@linux-foundation.org: fix build]
Severity CVSS v4.0: Pending analysis
Last modification:
15/04/2025

CVE-2025-21911

Publication date:
01/04/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: avoid deadlock on fence release<br /> <br /> Do scheduler queue fence release processing on a workqueue, rather<br /> than in the release function itself.<br /> <br /> Fixes deadlock issues such as the following:<br /> <br /> [ 607.400437] ============================================<br /> [ 607.405755] WARNING: possible recursive locking detected<br /> [ 607.415500] --------------------------------------------<br /> [ 607.420817] weston:zfq0/24149 is trying to acquire lock:<br /> [ 607.426131] ffff000017d041a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: pvr_gem_object_vunmap+0x40/0xc0 [powervr]<br /> [ 607.436728]<br /> but task is already holding lock:<br /> [ 607.442554] ffff000017d105a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: dma_buf_ioctl+0x250/0x554<br /> [ 607.451727]<br /> other info that might help us debug this:<br /> [ 607.458245] Possible unsafe locking scenario:<br /> <br /> [ 607.464155] CPU0<br /> [ 607.466601] ----<br /> [ 607.469044] lock(reservation_ww_class_mutex);<br /> [ 607.473584] lock(reservation_ww_class_mutex);<br /> [ 607.478114]<br /> *** DEADLOCK ***
Severity CVSS v4.0: Pending analysis
Last modification:
15/04/2025

CVE-2025-21912

Publication date:
01/04/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: rcar: Use raw_spinlock to protect register access<br /> <br /> Use raw_spinlock in order to fix spurious messages about invalid context<br /> when spinlock debugging is enabled. The lock is only used to serialize<br /> register access.<br /> <br /> [ 4.239592] =============================<br /> [ 4.239595] [ BUG: Invalid wait context ]<br /> [ 4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 Not tainted<br /> [ 4.239603] -----------------------------<br /> [ 4.239606] kworker/u8:5/76 is trying to lock:<br /> [ 4.239609] ffff0000091898a0 (&amp;p-&gt;lock){....}-{3:3}, at: gpio_rcar_config_interrupt_input_mode+0x34/0x164<br /> [ 4.239641] other info that might help us debug this:<br /> [ 4.239643] context-{5:5}<br /> [ 4.239646] 5 locks held by kworker/u8:5/76:<br /> [ 4.239651] #0: ffff0000080fb148 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x190/0x62c<br /> [ 4.250180] OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property &amp;#39;frame-master&amp;#39; with a value.<br /> [ 4.254094] #1: ffff80008299bd80 ((work_completion)(&amp;entry-&gt;work)){+.+.}-{0:0}, at: process_one_work+0x1b8/0x62c<br /> [ 4.254109] #2: ffff00000920c8f8<br /> [ 4.258345] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property &amp;#39;bitclock-master&amp;#39; with a value.<br /> [ 4.264803] (&amp;dev-&gt;mutex){....}-{4:4}, at: __device_attach_async_helper+0x3c/0xdc<br /> [ 4.264820] #3: ffff00000a50ca40 (request_class#2){+.+.}-{4:4}, at: __setup_irq+0xa0/0x690<br /> [ 4.264840] #4:<br /> [ 4.268872] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property &amp;#39;frame-master&amp;#39; with a value.<br /> [ 4.273275] ffff00000a50c8c8 (lock_class){....}-{2:2}, at: __setup_irq+0xc4/0x690<br /> [ 4.296130] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at 0x00000000ee100000, max clock rate 200 MHz<br /> [ 4.304082] stack backtrace:<br /> [ 4.304086] CPU: 1 UID: 0 PID: 76 Comm: kworker/u8:5 Not tainted 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35<br /> [ 4.304092] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)<br /> [ 4.304097] Workqueue: async async_run_entry_fn<br /> [ 4.304106] Call trace:<br /> [ 4.304110] show_stack+0x14/0x20 (C)<br /> [ 4.304122] dump_stack_lvl+0x6c/0x90<br /> [ 4.304131] dump_stack+0x14/0x1c<br /> [ 4.304138] __lock_acquire+0xdfc/0x1584<br /> [ 4.426274] lock_acquire+0x1c4/0x33c<br /> [ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80<br /> [ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164<br /> [ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8<br /> [ 4.444422] __irq_set_trigger+0x5c/0x178<br /> [ 4.448435] __setup_irq+0x2e4/0x690<br /> [ 4.452012] request_threaded_irq+0xc4/0x190<br /> [ 4.456285] devm_request_threaded_irq+0x7c/0xf4<br /> [ 4.459398] ata1: link resume succeeded after 1 retries<br /> [ 4.460902] mmc_gpiod_request_cd_irq+0x68/0xe0<br /> [ 4.470660] mmc_start_host+0x50/0xac<br /> [ 4.474327] mmc_add_host+0x80/0xe4<br /> [ 4.477817] tmio_mmc_host_probe+0x2b0/0x440<br /> [ 4.482094] renesas_sdhi_probe+0x488/0x6f4<br /> [ 4.486281] renesas_sdhi_internal_dmac_probe+0x60/0x78<br /> [ 4.491509] platform_probe+0x64/0xd8<br /> [ 4.495178] really_probe+0xb8/0x2a8<br /> [ 4.498756] __driver_probe_device+0x74/0x118<br /> [ 4.503116] driver_probe_device+0x3c/0x154<br /> [ 4.507303] __device_attach_driver+0xd4/0x160<br /> [ 4.511750] bus_for_each_drv+0x84/0xe0<br /> [ 4.515588] __device_attach_async_helper+0xb0/0xdc<br /> [ 4.520470] async_run_entry_fn+0x30/0xd8<br /> [ 4.524481] process_one_work+0x210/0x62c<br /> [ 4.528494] worker_thread+0x1ac/0x340<br /> [ 4.532245] kthread+0x10c/0x110<br /> [ 4.535476] ret_from_fork+0x10/0x20
Severity CVSS v4.0: Pending analysis
Last modification:
15/04/2025

CVE-2025-21907

Publication date:
01/04/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: memory-failure: update ttu flag inside unmap_poisoned_folio<br /> <br /> Patch series "mm: memory_failure: unmap poisoned folio during migrate<br /> properly", v3.<br /> <br /> Fix two bugs during folio migration if the folio is poisoned.<br /> <br /> <br /> This patch (of 3):<br /> <br /> Commit 6da6b1d4a7df ("mm/hwpoison: convert TTU_IGNORE_HWPOISON to<br /> TTU_HWPOISON") introduce TTU_HWPOISON to replace TTU_IGNORE_HWPOISON in<br /> order to stop send SIGBUS signal when accessing an error page after a<br /> memory error on a clean folio. However during page migration, anon folio<br /> must be set with TTU_HWPOISON during unmap_*(). For pagecache we need<br /> some policy just like the one in hwpoison_user_mappings to set this flag. <br /> So move this policy from hwpoison_user_mappings to unmap_poisoned_folio to<br /> handle this warning properly.<br /> <br /> Warning will be produced during unamp poison folio with the following log:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 365 at mm/rmap.c:1847 try_to_unmap_one+0x8fc/0xd3c<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 365 Comm: bash Tainted: G W 6.13.0-rc1-00018-gacdb4bbda7ab #42<br /> Tainted: [W]=WARN<br /> Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015<br /> pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : try_to_unmap_one+0x8fc/0xd3c<br /> lr : try_to_unmap_one+0x3dc/0xd3c<br /> Call trace:<br /> try_to_unmap_one+0x8fc/0xd3c (P)<br /> try_to_unmap_one+0x3dc/0xd3c (L)<br /> rmap_walk_anon+0xdc/0x1f8<br /> rmap_walk+0x3c/0x58<br /> try_to_unmap+0x88/0x90<br /> unmap_poisoned_folio+0x30/0xa8<br /> do_migrate_range+0x4a0/0x568<br /> offline_pages+0x5a4/0x670<br /> memory_block_action+0x17c/0x374<br /> memory_subsys_offline+0x3c/0x78<br /> device_offline+0xa4/0xd0<br /> state_store+0x8c/0xf0<br /> dev_attr_store+0x18/0x2c<br /> sysfs_kf_write+0x44/0x54<br /> kernfs_fop_write_iter+0x118/0x1a8<br /> vfs_write+0x3a8/0x4bc<br /> ksys_write+0x6c/0xf8<br /> __arm64_sys_write+0x1c/0x28<br /> invoke_syscall+0x44/0x100<br /> el0_svc_common.constprop.0+0x40/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x30/0xd0<br /> el0t_64_sync_handler+0xc8/0xcc<br /> el0t_64_sync+0x198/0x19c<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> [mawupeng1@huawei.com: unmap_poisoned_folio(): remove shadowed local `mapping&amp;#39;, per Miaohe]
Severity CVSS v4.0: Pending analysis
Last modification:
16/04/2025

CVE-2025-21897

Publication date:
01/04/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Fix pick_task_scx() picking non-queued tasks when it&amp;#39;s called without balance()<br /> <br /> a6250aa251ea ("sched_ext: Handle cases where pick_task_scx() is called<br /> without preceding balance_scx()") added a workaround to handle the cases<br /> where pick_task_scx() is called without prececing balance_scx() which is due<br /> to a fair class bug where pick_taks_fair() may return NULL after a true<br /> return from balance_fair().<br /> <br /> The workaround detects when pick_task_scx() is called without preceding<br /> balance_scx() and emulates SCX_RQ_BAL_KEEP and triggers kicking to avoid<br /> stalling. Unfortunately, the workaround code was testing whether @prev was<br /> on SCX to decide whether to keep the task running. This is incorrect as the<br /> task may be on SCX but no longer runnable.<br /> <br /> This could lead to a non-runnable task to be returned from pick_task_scx()<br /> which cause interesting confusions and failures. e.g. A common failure mode<br /> is the task ending up with (!on_rq &amp;&amp; on_cpu) state which can cause<br /> potential wakers to busy loop, which can easily lead to deadlocks.<br /> <br /> Fix it by testing whether @prev has SCX_TASK_QUEUED set. This makes<br /> @prev_on_scx only used in one place. Open code the usage and improve the<br /> comment while at it.
Severity CVSS v4.0: Pending analysis
Last modification:
01/04/2025

CVE-2025-21899

Publication date:
01/04/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix bad hist from corrupting named_triggers list<br /> <br /> The following commands causes a crash:<br /> <br /> ~# cd /sys/kernel/tracing/events/rcu/rcu_callback<br /> ~# echo &amp;#39;hist:name=bad:keys=common_pid:onmax(bogus).save(common_pid)&amp;#39; &gt; trigger<br /> bash: echo: write error: Invalid argument<br /> ~# echo &amp;#39;hist:name=bad:keys=common_pid&amp;#39; &gt; trigger<br /> <br /> Because the following occurs:<br /> <br /> event_trigger_write() {<br /> trigger_process_regex() {<br /> event_hist_trigger_parse() {<br /> <br /> data = event_trigger_alloc(..);<br /> <br /> event_trigger_register(.., data) {<br /> cmd_ops-&gt;reg(.., data, ..) [hist_register_trigger()] {<br /> data-&gt;ops-&gt;init() [event_hist_trigger_init()] {<br /> save_named_trigger(name, data) {<br /> list_add(&amp;data-&gt;named_list, &amp;named_triggers);<br /> }<br /> }<br /> }<br /> }<br /> <br /> ret = create_actions(); (return -EINVAL)<br /> if (ret)<br /> goto out_unreg;<br /> [..]<br /> ret = hist_trigger_enable(data, ...) {<br /> list_add_tail_rcu(&amp;data-&gt;list, &amp;file-&gt;triggers); free) name)<br /> del_named_trigger(data) {<br /> list_del(&amp;data-&gt;named_list);
Severity CVSS v4.0: Pending analysis
Last modification:
01/04/2025

CVE-2025-21902

Publication date:
01/04/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> acpi: typec: ucsi: Introduce a -&gt;poll_cci method<br /> <br /> For the ACPI backend of UCSI the UCSI "registers" are just a memory copy<br /> of the register values in an opregion. The ACPI implementation in the<br /> BIOS ensures that the opregion contents are synced to the embedded<br /> controller and it ensures that the registers (in particular CCI) are<br /> synced back to the opregion on notifications. While there is an ACPI call<br /> that syncs the actual registers to the opregion there is rarely a need to<br /> do this and on some ACPI implementations it actually breaks in various<br /> interesting ways.<br /> <br /> The only reason to force a sync from the embedded controller is to poll<br /> CCI while notifications are disabled. Only the ucsi core knows if this<br /> is the case and guessing based on the current command is suboptimal, i.e.<br /> leading to the following spurious assertion splat:<br /> <br /> WARNING: CPU: 3 PID: 76 at drivers/usb/typec/ucsi/ucsi.c:1388 ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]<br /> CPU: 3 UID: 0 PID: 76 Comm: kworker/3:0 Not tainted 6.12.11-200.fc41.x86_64 #1<br /> Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN45WW 03/17/2023<br /> Workqueue: events_long ucsi_init_work [typec_ucsi]<br /> RIP: 0010:ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]<br /> Call Trace:<br /> <br /> ucsi_init_work+0x3c/0xac0 [typec_ucsi]<br /> process_one_work+0x179/0x330<br /> worker_thread+0x252/0x390<br /> kthread+0xd2/0x100<br /> ret_from_fork+0x34/0x50<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Thus introduce a -&gt;poll_cci() method that works like -&gt;read_cci() with an<br /> additional forced sync and document that this should be used when polling<br /> with notifications disabled. For all other backends that presumably don&amp;#39;t<br /> have this issue use the same implementation for both methods.
Severity CVSS v4.0: Pending analysis
Last modification:
01/04/2025

CVE-2025-21903

Publication date:
01/04/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp i3c: handle NULL header address<br /> <br /> daddr can be NULL if there is no neighbour table entry present,<br /> in that case the tx packet should be dropped.<br /> <br /> saddr will usually be set by MCTP core, but check for NULL in case a<br /> packet is transmitted by a different protocol.
Severity CVSS v4.0: Pending analysis
Last modification:
01/04/2025