Vulnerabilities

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 /> vxlan: Annotate FDB data races<br /> <br /> The &amp;#39;used&amp;#39; and &amp;#39;updated&amp;#39; fields in the FDB entry structure can be<br /> accessed concurrently by multiple threads, leading to reports such as<br /> [1]. Can be reproduced using [2].<br /> <br /> Suppress these reports by annotating these accesses using<br /> READ_ONCE() / WRITE_ONCE().<br /> <br /> [1]<br /> BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmit<br /> <br /> write to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0:<br /> vxlan_xmit+0xb29/0x2380<br /> dev_hard_start_xmit+0x84/0x2f0<br /> __dev_queue_xmit+0x45a/0x1650<br /> packet_xmit+0x100/0x150<br /> packet_sendmsg+0x2114/0x2ac0<br /> __sys_sendto+0x318/0x330<br /> __x64_sys_sendto+0x76/0x90<br /> x64_sys_call+0x14e8/0x1c00<br /> do_syscall_64+0x9e/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> read to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2:<br /> vxlan_xmit+0xadf/0x2380<br /> dev_hard_start_xmit+0x84/0x2f0<br /> __dev_queue_xmit+0x45a/0x1650<br /> packet_xmit+0x100/0x150<br /> packet_sendmsg+0x2114/0x2ac0<br /> __sys_sendto+0x318/0x330<br /> __x64_sys_sendto+0x76/0x90<br /> x64_sys_call+0x14e8/0x1c00<br /> do_syscall_64+0x9e/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> value changed: 0x00000000fffbac6e -&gt; 0x00000000fffbac6f<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014<br /> <br /> [2]<br /> #!/bin/bash<br /> <br /> set +H<br /> echo whitelist &gt; /sys/kernel/debug/kcsan<br /> echo !vxlan_xmit &gt; /sys/kernel/debug/kcsan<br /> <br /> ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1<br /> bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1<br /> taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &amp;<br /> taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &amp;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: amd-pstate: Remove unnecessary driver_lock in set_boost<br /> <br /> set_boost is a per-policy function call, hence a driver wide lock is<br /> unnecessary. Also this mutex_acquire can collide with the mutex_acquire<br /> from the mode-switch path in status_store(), which can lead to a<br /> deadlock. So, remove it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled<br /> <br /> When attempting to enable MQPRIO while HTB offload is already<br /> configured, the driver currently returns `-EINVAL` and triggers a<br /> `WARN_ON`, leading to an unnecessary call trace.<br /> <br /> Update the code to handle this case more gracefully by returning<br /> `-EOPNOTSUPP` instead, while also providing a helpful user message.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: mctrl_gpio: split disable_ms into sync and no_sync APIs<br /> <br /> The following splat has been observed on a SAMA5D27 platform using<br /> atmel_serial:<br /> <br /> BUG: sleeping function called from invalid context at kernel/irq/manage.c:738<br /> in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0<br /> preempt_count: 1, expected: 0<br /> INFO: lockdep is turned off.<br /> irq event stamp: 0<br /> hardirqs last enabled at (0): [] 0x0<br /> hardirqs last disabled at (0): [] copy_process+0x1c4c/0x7bec<br /> softirqs last enabled at (0): [] copy_process+0x1ca0/0x7bec<br /> softirqs last disabled at (0): [] 0x0<br /> CPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74<br /> Hardware name: Atmel SAMA5<br /> Workqueue: hci0 hci_power_on [bluetooth]<br /> Call trace:<br /> unwind_backtrace from show_stack+0x18/0x1c<br /> show_stack from dump_stack_lvl+0x44/0x70<br /> dump_stack_lvl from __might_resched+0x38c/0x598<br /> __might_resched from disable_irq+0x1c/0x48<br /> disable_irq from mctrl_gpio_disable_ms+0x74/0xc0<br /> mctrl_gpio_disable_ms from atmel_disable_ms.part.0+0x80/0x1f4<br /> atmel_disable_ms.part.0 from atmel_set_termios+0x764/0x11e8<br /> atmel_set_termios from uart_change_line_settings+0x15c/0x994<br /> uart_change_line_settings from uart_set_termios+0x2b0/0x668<br /> uart_set_termios from tty_set_termios+0x600/0x8ec<br /> tty_set_termios from ttyport_set_flow_control+0x188/0x1e0<br /> ttyport_set_flow_control from wilc_setup+0xd0/0x524 [hci_wilc]<br /> wilc_setup [hci_wilc] from hci_dev_open_sync+0x330/0x203c [bluetooth]<br /> hci_dev_open_sync [bluetooth] from hci_dev_do_open+0x40/0xb0 [bluetooth]<br /> hci_dev_do_open [bluetooth] from hci_power_on+0x12c/0x664 [bluetooth]<br /> hci_power_on [bluetooth] from process_one_work+0x998/0x1a38<br /> process_one_work from worker_thread+0x6e0/0xfb4<br /> worker_thread from kthread+0x3d4/0x484<br /> kthread from ret_from_fork+0x14/0x28<br /> <br /> This warning is emitted when trying to toggle, at the highest level,<br /> some flow control (with serdev_device_set_flow_control) in a device<br /> driver. At the lowest level, the atmel_serial driver is using<br /> serial_mctrl_gpio lib to enable/disable the corresponding IRQs<br /> accordingly. The warning emitted by CONFIG_DEBUG_ATOMIC_SLEEP is due to<br /> disable_irq (called in mctrl_gpio_disable_ms) being possibly called in<br /> some atomic context (some tty drivers perform modem lines configuration<br /> in regions protected by port lock).<br /> <br /> Split mctrl_gpio_disable_ms into two differents APIs, a non-blocking one<br /> and a blocking one. Replace mctrl_gpio_disable_ms calls with the<br /> relevant version depending on whether the call is protected by some port<br /> lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: sunxi-ng: h616: Reparent GPU clock during frequency changes<br /> <br /> The H616 manual does not state that the GPU PLL supports<br /> dynamic frequency configuration, so we must take extra care when changing<br /> the frequency. Currently any attempt to do device DVFS on the GPU lead<br /> to panfrost various ooops, and GPU hangs.<br /> <br /> The manual describes the algorithm for changing the PLL<br /> frequency, which the CPU PLL notifier code already support, so we reuse<br /> that to reparent the GPU clock to GPU1 clock during frequency<br /> changes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ti: k3-udma-glue: Drop skip_fdq argument from k3_udma_glue_reset_rx_chn<br /> <br /> The user of k3_udma_glue_reset_rx_chn() e.g. ti_am65_cpsw_nuss can<br /> run on multiple platforms having different DMA architectures.<br /> On some platforms there can be one FDQ for all flows in the RX channel<br /> while for others there is a separate FDQ for each flow in the RX channel.<br /> <br /> So far we have been relying on the skip_fdq argument of<br /> k3_udma_glue_reset_rx_chn().<br /> <br /> Instead of relying on the user to provide this information, infer it<br /> based on DMA architecture during k3_udma_glue_request_rx_chn() and save it<br /> in an internal flag &amp;#39;single_fdq&amp;#39;. Use that flag at<br /> k3_udma_glue_reset_rx_chn() to deicide if the FDQ needs<br /> to be cleared for every flow or just for flow 0.<br /> <br /> Fixes the below issue on ti_am65_cpsw_nuss driver on AM62-SK.<br /> <br /> &gt; ip link set eth1 down<br /> &gt; ip link set eth0 down<br /> &gt; ethtool -L eth0 rx 8<br /> &gt; ip link set eth0 up<br /> &gt; modprobe -r ti_am65_cpsw_nuss<br /> <br /> [ 103.045726] ------------[ cut here ]------------<br /> [ 103.050505] k3_knav_desc_pool size 512000 != avail 64000<br /> [ 103.050703] WARNING: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]<br /> [ 103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcas<br /> p drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 r<br /> fkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool]<br /> [ 103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011<br /> [ 103.119968] Hardware name: Texas Instruments AM625 SK (DT)<br /> [ 103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]<br /> [ 103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]<br /> [ 103.154709] sp : ffff8000826ebbc0<br /> [ 103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000<br /> [ 103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0<br /> [ 103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88<br /> [ 103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000<br /> [ 103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde<br /> [ 103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000<br /> [ 103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20<br /> [ 103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100<br /> [ 103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000<br /> [ 103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000<br /> [ 103.229274] Call trace:<br /> [ 103.231714] k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P)<br /> [ 103.238408] am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss]<br /> [ 103.244942] devm_action_release+0x14/0x20<br /> [ 103.249040] release_nodes+0x3c/0x68<br /> [ 103.252610] devres_release_all+0x8c/0xdc<br /> [ 103.256614] device_unbind_cleanup+0x18/0x60<br /> [ 103.260876] device_release_driver_internal+0xf8/0x178<br /> [ 103.266004] driver_detach+0x50/0x9c<br /> [ 103.269571] bus_remove_driver+0x6c/0xbc<br /> [ 103.273485] driver_unregister+0x30/0x60<br /> [ 103.277401] platform_driver_unregister+0x14/0x20<br /> [ 103.282096] am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss]<br /> [ 103.288620] __arm64_sys_delete_module+0x17c/0x25c<br /> [ 103.293404] invoke_syscall+0x44/0x100<br /> [ 103.297149] el0_svc_common.constprop.0+0xc0/0xe0<br /> [ 103.301845] do_el0_svc+0x1c/0x28<br /> [ 103.305155] el0_svc+0x28/0x98<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_ffa: Set dma_mask for ffa devices<br /> <br /> Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer<br /> lead to following warning:<br /> <br /> WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cx231xx: set device_caps for 417<br /> <br /> The video_device for the MPEG encoder did not set device_caps.<br /> <br /> Add this, otherwise the video device can&amp;#39;t be registered (you get a<br /> WARN_ON instead).<br /> <br /> Not seen before since currently 417 support is disabled, but I found<br /> this while experimenting with it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> padata: do not leak refcount in reorder_work<br /> <br /> A recent patch that addressed a UAF introduced a reference count leak:<br /> the parallel_data refcount is incremented unconditionally, regardless<br /> of the return value of queue_work(). If the work item is already queued,<br /> the incremented refcount is never decremented.<br /> <br /> Fix this by checking the return value of queue_work() and decrementing<br /> the refcount when necessary.<br /> <br /> Resolves:<br /> <br /> Unreferenced object 0xffff9d9f421e3d80 (size 192):<br /> comm "cryptomgr_probe", pid 157, jiffies 4294694003<br /> hex dump (first 32 bytes):<br /> 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............<br /> d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#.<br /> backtrace (crc 838fb36):<br /> __kmalloc_cache_noprof+0x284/0x320<br /> padata_alloc_pd+0x20/0x1e0<br /> padata_alloc_shell+0x3b/0xa0<br /> 0xffffffffc040a54d<br /> cryptomgr_probe+0x43/0xc0<br /> kthread+0xf6/0x1f0<br /> ret_from_fork+0x2f/0x50<br /> ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mr: consolidate the ipmr_can_free_table() checks.<br /> <br /> Guoyu Yin reported a splat in the ipmr netns cleanup path:<br /> <br /> WARNING: CPU: 2 PID: 14564 at net/ipv4/ipmr.c:440 ipmr_free_table net/ipv4/ipmr.c:440 [inline]<br /> WARNING: CPU: 2 PID: 14564 at net/ipv4/ipmr.c:440 ipmr_rules_exit+0x135/0x1c0 net/ipv4/ipmr.c:361<br /> Modules linked in:<br /> CPU: 2 UID: 0 PID: 14564 Comm: syz.4.838 Not tainted 6.14.0 #1<br /> Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:ipmr_free_table net/ipv4/ipmr.c:440 [inline]<br /> RIP: 0010:ipmr_rules_exit+0x135/0x1c0 net/ipv4/ipmr.c:361<br /> Code: ff df 48 c1 ea 03 80 3c 02 00 75 7d 48 c7 83 60 05 00 00 00 00 00 00 5b 5d 41 5c 41 5d 41 5e e9 71 67 7f 00 e8 4c 2d 8a fd 90 0b 90 eb 93 e8 41 2d 8a fd 0f b6 2d 80 54 ea 01 31 ff 89 ee e8<br /> RSP: 0018:ffff888109547c58 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff888108c12dc0 RCX: ffffffff83e09868<br /> RDX: ffff8881022b3300 RSI: ffffffff83e098d4 RDI: 0000000000000005<br /> RBP: ffff888104288000 R08: 0000000000000000 R09: ffffed10211825c9<br /> R10: 0000000000000001 R11: ffff88801816c4a0 R12: 0000000000000001<br /> R13: ffff888108c13320 R14: ffff888108c12dc0 R15: fffffbfff0b74058<br /> FS: 00007f84f39316c0(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f84f3930f98 CR3: 0000000113b56000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> ipmr_net_exit_batch+0x50/0x90 net/ipv4/ipmr.c:3160<br /> ops_exit_list+0x10c/0x160 net/core/net_namespace.c:177<br /> setup_net+0x47d/0x8e0 net/core/net_namespace.c:394<br /> copy_net_ns+0x25d/0x410 net/core/net_namespace.c:516<br /> create_new_namespaces+0x3f6/0xaf0 kernel/nsproxy.c:110<br /> unshare_nsproxy_namespaces+0xc3/0x180 kernel/nsproxy.c:228<br /> ksys_unshare+0x78d/0x9a0 kernel/fork.c:3342<br /> __do_sys_unshare kernel/fork.c:3413 [inline]<br /> __se_sys_unshare kernel/fork.c:3411 [inline]<br /> __x64_sys_unshare+0x31/0x40 kernel/fork.c:3411<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xa6/0x1a0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f84f532cc29<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f84f3931038 EFLAGS: 00000246 ORIG_RAX: 0000000000000110<br /> RAX: ffffffffffffffda RBX: 00007f84f5615fa0 RCX: 00007f84f532cc29<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000400<br /> RBP: 00007f84f53fba18 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00007f84f5615fa0 R15: 00007fff51c5f328<br /> <br /> <br /> The running kernel has CONFIG_IP_MROUTE_MULTIPLE_TABLES disabled, and<br /> the sanity check for such build is still too loose.<br /> <br /> Address the issue consolidating the relevant sanity check in a single<br /> helper regardless of the kernel configuration. Also share it between<br /> the ipv4 and ipv6 code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/Kconfig: make CFI_AUTO_DEFAULT depend on !RUST or Rust &gt;= 1.88<br /> <br /> Calling core::fmt::write() from rust code while FineIBT is enabled<br /> results in a kernel panic:<br /> <br /> [ 4614.199779] kernel BUG at arch/x86/kernel/cet.c:132!<br /> [ 4614.205343] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 4614.211781] CPU: 2 UID: 0 PID: 6057 Comm: dmabuf_dump Tainted: G U O 6.12.17-android16-0-g6ab38c534a43 #1 9da040f27673ec3945e23b998a0f8bd64c846599<br /> [ 4614.227832] Tainted: [U]=USER, [O]=OOT_MODULE<br /> [ 4614.241247] RIP: 0010:do_kernel_cp_fault+0xea/0xf0<br /> ...<br /> [ 4614.398144] RIP: 0010:_RNvXs5_NtNtNtCs3o2tGsuHyou_4core3fmt3num3impyNtB9_7Display3fmt+0x0/0x20<br /> [ 4614.407792] Code: 48 f7 df 48 0f 48 f9 48 89 f2 89 c6 5d e9 18 fd ff ff 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 41 81 ea 14 61 af 2c 74 03 0f 0b 90 0f 1f 00 55 48 89 e5 48 89 f2 48 8b 3f be 01 00 00 00 5d e9 e7<br /> [ 4614.428775] RSP: 0018:ffffb95acfa4ba68 EFLAGS: 00010246<br /> [ 4614.434609] RAX: 0000000000000000 RBX: 0000000000000010 RCX: 0000000000000000<br /> [ 4614.442587] RDX: 0000000000000007 RSI: ffffb95acfa4ba70 RDI: ffffb95acfa4bc88<br /> [ 4614.450557] RBP: ffffb95acfa4bae0 R08: ffff0a00ffffff05 R09: 0000000000000070<br /> [ 4614.458527] R10: 0000000000000000 R11: ffffffffab67eaf0 R12: ffffb95acfa4bcc8<br /> [ 4614.466493] R13: ffffffffac5d50f0 R14: 0000000000000000 R15: 0000000000000000<br /> [ 4614.474473] ? __cfi__RNvXs5_NtNtNtCs3o2tGsuHyou_4core3fmt3num3impyNtB9_7Display3fmt+0x10/0x10<br /> [ 4614.484118] ? _RNvNtCs3o2tGsuHyou_4core3fmt5write+0x1d2/0x250<br /> <br /> This happens because core::fmt::write() calls<br /> core::fmt::rt::Argument::fmt(), which currently has CFI disabled:<br /> <br /> library/core/src/fmt/rt.rs:<br /> 171 // FIXME: Transmuting formatter in new and indirectly branching to/calling<br /> 172 // it here is an explicit CFI violation.<br /> 173 #[allow(inline_no_sanitize)]<br /> 174 #[no_sanitize(cfi, kcfi)]<br /> 175 #[inline]<br /> 176 pub(super) unsafe fn fmt(&amp;self, f: &amp;mut Formatter) -&gt; Result {<br /> <br /> This causes a Control Protection exception, because FineIBT has sealed<br /> off the original function&amp;#39;s endbr64.<br /> <br /> This makes rust currently incompatible with FineIBT. Add a Kconfig<br /> dependency that prevents FineIBT from getting turned on by default<br /> if rust is enabled.<br /> <br /> [ Rust 1.88.0 (scheduled for 2025-06-26) should have this fixed [1],<br /> and thus we relaxed the condition with Rust &gt;= 1.88.<br /> <br /> When `objtool` lands checking for this with e.g. [2], the plan is<br /> to ideally run that in upstream Rust&amp;#39;s CI to prevent regressions<br /> early [3], since we do not control `core`&amp;#39;s source code.<br /> <br /> Alice tested the Rust PR backported to an older compiler.<br /> <br /> Peter would like that Rust provides a stable `core` which can be<br /> pulled into the kernel: "Relying on that much out of tree code is<br /> &amp;#39;unfortunate&amp;#39;".<br /> <br /> - Miguel ]<br /> <br /> [ Reduced splat. - Miguel ]