Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> audit: Fix data races of skb_queue_len() readers on audit_queue<br /> <br /> Multiple readers access audit_queue.qlen via skb_queue_len() without<br /> holding the queue lock or using READ_ONCE(), while kauditd writes to<br /> this field via the skb_dequeue() → __skb_unlink() path with WRITE_ONCE()<br /> protected by a spinlock. This constitutes data races.<br /> <br /> All affected skb_queue_len(&amp;audit_queue) call sites:<br /> - kauditd_thread() wait_event_freezable() condition<br /> - audit_receive_msg() AUDIT_GET handler (s.backlog assignment)<br /> - audit_receive() backlog check<br /> - audit_log_start() backlog check and pr_warn()<br /> <br /> KCSAN reports the following conflicting access pattern (one example):<br /> ==================================================================<br /> BUG: KCSAN: data-race in audit_log_start / skb_dequeue<br /> <br /> write (marked) to 0xffffffff8512ee20 of 4 bytes by task 661 on cpu 57:<br /> skb_dequeue+0x70/0xf0<br /> kauditd_send_queue+0x71/0x220<br /> kauditd_thread+0x1cb/0x430<br /> kthread+0x1c2/0x210<br /> ret_from_fork+0x162/0x1a0<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> read to 0xffffffff8512ee20 of 4 bytes by task 36586 on cpu 1:<br /> audit_log_start+0x2a0/0x6b0<br /> audit_core_dumps+0x64/0xa0<br /> do_coredump+0x14b/0x1260<br /> get_signal+0xeb2/0xf70<br /> arch_do_signal_or_restart+0x41/0x170<br /> exit_to_user_mode_loop+0xa2/0x1c0<br /> do_syscall_64+0x1a3/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0xe0<br /> <br /> value changed: 0x00000001 -&gt; 0x00000000<br /> ==================================================================<br /> <br /> Resolve the race by switching to lockless helper skb_queue_len_lockless(),<br /> which internally uses READ_ONCE() and properly pairs with the WRITE_ONCE()<br /> write accesses already present on the writer side.<br /> <br /> [PM: line length tweak]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: eic-sprd: use raw_spinlock_t in the irq startup path<br /> <br /> sprd_eic_irq_unmask() enables the GPIO IRQ and then updates controller<br /> state through sprd_eic_update(), which takes sprd_eic-&gt;lock with<br /> spin_lock_irqsave(). The callback can be reached from irq_startup()<br /> while setting up a requested IRQ. That path is not sleepable, but on<br /> PREEMPT_RT a regular spinlock_t becomes a sleeping lock.<br /> <br /> This issue was found by our static analysis tool and then manually<br /> reviewed against the current tree.<br /> <br /> The grounded PoC kept the request_threaded_irq() -&gt; __setup_irq() -&gt;<br /> irq_startup() -&gt; sprd_eic_irq_unmask() -&gt; sprd_eic_update() carrier and<br /> used the original spin_lock_irqsave(&amp;sprd_eic-&gt;lock) edge. Lockdep<br /> <br /> BUG: sleeping function called from invalid context<br /> hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv]<br /> sprd_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv]<br /> sprd_eic_update.constprop.0+0x48/0x90 [vuln_msv]<br /> sprd_eic_irq_unmask.constprop.0+0x35/0x50 [vuln_msv]<br /> __setup_irq.constprop.0+0xd/0x30 [vuln_msv]<br /> <br /> Convert the Spreadtrum EIC controller lock to raw_spinlock_t. The<br /> locked section only serializes MMIO register updates and does not contain<br /> sleepable operations, so keeping it non-sleeping is appropriate for the<br /> irqchip callbacks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: Fix UAF of hci_conn_params in add_device_complete<br /> <br /> add_device_complete() runs from the hci_cmd_sync_work kworker, which<br /> holds only hci_req_sync_lock and *not* hci_dev_lock. It calls<br /> hci_conn_params_lookup() and then dereferences the returned object<br /> (params-&gt;flags) without taking hci_dev_lock:<br /> <br /> params = hci_conn_params_lookup(hdev, &amp;cp-&gt;addr.bdaddr,<br /> le_addr_type(cp-&gt;addr.type));<br /> ...<br /> device_flags_changed(NULL, hdev, &amp;cp-&gt;addr.bdaddr,<br /> cp-&gt;addr.type, hdev-&gt;conn_flags,<br /> params ? params-&gt;flags : 0);<br /> <br /> hci_conn_params_lookup() walks hdev-&gt;le_conn_params and is documented to<br /> require hdev-&gt;lock. A concurrent MGMT_OP_REMOVE_DEVICE<br /> (remove_device()), which does run under hci_dev_lock, can call<br /> hci_conn_params_free() to list_del() and kfree() the very object the<br /> lookup returned, so the subsequent params-&gt;flags read touches freed<br /> memory [0].<br /> <br /> Hold hci_dev_lock() across the hci_conn_params_lookup() and the read of<br /> params-&gt;flags (and the matching event emission) so the lookup result<br /> cannot be freed by a concurrent remove_device() before it is used,<br /> honouring the locking contract of hci_conn_params_lookup().<br /> <br /> [0]: (trailing page/memory-state dump trimmed)<br /> BUG: KASAN: slab-use-after-free in add_device_complete+0x358/0x3d8 net/bluetooth/mgmt.c:7671<br /> Read of size 1 at addr ffff000017ab26c1 by task kworker/u9:8/388<br /> <br /> CPU: 1 UID: 0 PID: 388 Comm: kworker/u9:8 Not tainted 7.0.11 #20 PREEMPT<br /> Hardware name: linux,dummy-virt (DT)<br /> Workqueue: hci0 hci_cmd_sync_work<br /> Call trace:<br /> show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:499 (C)<br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0xb4/0xd4 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x118/0x5d8 mm/kasan/report.c:482<br /> kasan_report+0xb0/0xf4 mm/kasan/report.c:595<br /> __asan_report_load1_noabort+0x20/0x2c mm/kasan/report_generic.c:378<br /> add_device_complete+0x358/0x3d8 net/bluetooth/mgmt.c:7671<br /> hci_cmd_sync_work+0x14c/0x240 net/bluetooth/hci_sync.c:334<br /> process_one_work+0x628/0xd38 kernel/workqueue.c:3289<br /> process_scheduled_works kernel/workqueue.c:3372 [inline]<br /> worker_thread+0x7a8/0xac0 kernel/workqueue.c:3453<br /> kthread+0x39c/0x444 kernel/kthread.c:436<br /> ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860<br /> <br /> Allocated by task 3401:<br /> kasan_save_stack+0x3c/0x64 mm/kasan/common.c:57<br /> kasan_save_track+0x20/0x3c mm/kasan/common.c:78<br /> kasan_save_alloc_info+0x40/0x54 mm/kasan/generic.c:570<br /> poison_kmalloc_redzone mm/kasan/common.c:398 [inline]<br /> __kasan_kmalloc+0xd4/0xd8 mm/kasan/common.c:415<br /> kasan_kmalloc include/linux/kasan.h:263 [inline]<br /> __kmalloc_cache_noprof+0x1b0/0x458 mm/slub.c:5385<br /> kmalloc_noprof include/linux/slab.h:950 [inline]<br /> kzalloc_noprof include/linux/slab.h:1188 [inline]<br /> hci_conn_params_add+0x10c/0x4b0 net/bluetooth/hci_core.c:2279<br /> hci_conn_params_set net/bluetooth/mgmt.c:5162 [inline]<br /> add_device+0x5b4/0xa54 net/bluetooth/mgmt.c:7755<br /> hci_mgmt_cmd net/bluetooth/hci_sock.c:1721 [inline]<br /> hci_sock_sendmsg+0x10b4/0x1dd0 net/bluetooth/hci_sock.c:1841<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg+0xe0/0x128 net/socket.c:742<br /> sock_write_iter+0x250/0x390 net/socket.c:1195<br /> new_sync_write fs/read_write.c:595 [inline]<br /> vfs_write+0x66c/0xab0 fs/read_write.c:688<br /> ksys_write+0x1fc/0x24c fs/read_write.c:740<br /> __do_sys_write fs/read_write.c:751 [inline]<br /> __se_sys_write fs/read_write.c:748 [inline]<br /> __arm64_sys_write+0x70/0xa4 fs/read_write.c:748<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x84/0x2a8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common.constprop.0+0xe4/0x294 arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x44/0x5c arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x38/0xac arch/arm64/kernel/entry-common.c:724<br /> el0t_64_sync_handler+0xa0/0xe4 arch/arm64/kernel/entry-common.c:743<br /> el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:596<br /> <br /> Freed by task 3740:<br /> kasan_save_stack+0x3c/0x64 <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes<br /> <br /> Reject invalid `net.ipv4.tcp_reordering` values before they reach TCP<br /> socket state. The sysctl is stored as an `int` but copied into the<br /> `u32` `tp-&gt;reordering` field for new sockets, so negative writes wrap<br /> to large values.<br /> <br /> With `tcp_mtu_probing=2`, the wrapped value can overflow the<br /> `tcp_mtu_probe()` size calculation and drive the MTU probing path into<br /> an out-of-bounds read. Route `tcp_reordering` writes through<br /> `proc_dointvec_minmax()` and require it to be at least 1. Also require<br /> `tcp_max_reordering` to be at least 1 so the configured maximum cannot<br /> become negative either.<br /> <br /> When registering the table for a non-init network namespace, relocate<br /> `extra2` pointers that refer into `init_net.ipv4` so the<br /> `tcp_reordering` upper bound follows that namespace&amp;#39;s<br /> `tcp_max_reordering`.<br /> <br /> Harden `tcp_mtu_probe()` itself by computing `size_needed` as `u64`.<br /> This keeps the send queue and window checks from being bypassed through<br /> signed integer overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: igmp: remove multicast group from hash table on device destruction<br /> <br /> When a device is destroyed under RTNL, ip_mc_destroy_dev() iterates through<br /> the multicast list and calls ip_ma_put() on each membership, scheduling<br /> them for RCU reclamation. However, they are not unlinked from the device&amp;#39;s<br /> multicast hash table (mc_hash).<br /> <br /> Since the device remains published in dev-&gt;ip_ptr until after<br /> ip_mc_destroy_dev() completes, concurrent RCU readers traversing mc_hash<br /> can still locate and access the multicast group after its refcount is<br /> decremented. If the RCU callback runs and frees the group while a reader is<br /> accessing it, a use-after-free occurs.<br /> <br /> Fix this by unlinking the multicast group from mc_hash using<br /> ip_mc_hash_remove() before scheduling it for reclamation.<br /> <br /> BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x149/0x3f0<br /> Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x67/0x90<br /> print_report+0x175/0x7c0<br /> kasan_report+0x147/0x180<br /> ip_check_mc_rcu+0x149/0x3f0<br /> udp_v4_early_demux+0x36d/0x12d0<br /> ip_rcv_finish_core+0xb8b/0x1390<br /> ip_rcv_finish+0x54/0x120<br /> NF_HOOK+0x213/0x2b0<br /> __netif_receive_skb+0x126/0x340<br /> process_backlog+0x4f2/0xf00<br /> __napi_poll+0x92/0x2c0<br /> net_rx_action+0x583/0xc60<br /> handle_softirqs+0x236/0x7f0<br /> do_softirq+0x57/0x80<br /> <br /> <br /> Allocated by task 2239:<br /> kasan_save_track+0x3e/0x80<br /> __kasan_kmalloc+0x72/0x90<br /> ____ip_mc_inc_group+0x31a/0xa40<br /> __ip_mc_join_group+0x334/0x3f0<br /> do_ip_setsockopt+0x16fa/0x2010<br /> ip_setsockopt+0x3f/0x90<br /> do_sock_setsockopt+0x1ad/0x300<br /> <br /> Freed by task 0:<br /> kasan_save_track+0x3e/0x80<br /> kasan_save_free_info+0x40/0x50<br /> __kasan_slab_free+0x3a/0x60<br /> __rcu_free_sheaf_prepare+0xd4/0x220<br /> rcu_free_sheaf+0x36/0x190<br /> rcu_core+0x8d9/0x12f0<br /> handle_softirqs+0x236/0x7f0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: nxp: imx8-isi: Fix use-after-free on remove<br /> <br /> KASAN reports a slab-use-after-free in __media_entity_remove_link()<br /> during rmmod of imx8_isi:<br /> <br /> BUG: KASAN: slab-use-after-free in __media_entity_remove_link+0x608/0x650<br /> Read of size 2 at addr ffff0000d47cb02a by task rmmod/724<br /> <br /> Call trace:<br /> __media_entity_remove_link+0x608/0x650<br /> __media_entity_remove_links+0x78/0x144<br /> __media_device_unregister_entity+0x150/0x280<br /> media_device_unregister_entity+0x48/0x68<br /> v4l2_device_unregister_subdev+0x158/0x300<br /> v4l2_async_unbind_subdev_one+0x22c/0x358<br /> v4l2_async_nf_unbind_all_subdevs+0xfc/0x1c0<br /> v4l2_async_nf_unregister+0x5c/0x14c<br /> mxc_isi_remove+0x124/0x2a0 [imx8_isi]<br /> <br /> Allocated by task 249:<br /> __kmalloc_noprof+0x27c/0x690<br /> mxc_isi_crossbar_init+0x22c/0x560 [imx8_isi]<br /> <br /> Freed by task 724:<br /> kfree+0x1e4/0x5b0<br /> mxc_isi_crossbar_cleanup+0x34/0x80 [imx8_isi]<br /> mxc_isi_remove+0x11c/0x2a0 [imx8_isi]<br /> <br /> The problem is that mxc_isi_remove() calls mxc_isi_crossbar_cleanup()<br /> before mxc_isi_v4l2_cleanup(). The crossbar cleanup frees the media<br /> entity pads, but the subsequent v4l2 cleanup still tries to remove<br /> media links that reference those pads.<br /> <br /> Fix this by calling mxc_isi_v4l2_cleanup() before<br /> mxc_isi_crossbar_cleanup() to ensure all media entities are properly<br /> unregistered while the pads are still valid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netpoll: fix a use-after-free on shutdown path<br /> <br /> There is a use-after-free error on netpoll, which is clearly detected by<br /> KASAN.<br /> <br /> BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0x3b/0x80<br /> Read of size 1 at addr ... by task kworker/9:1<br /> Workqueue: events queue_process<br /> Call Trace:<br /> skb_dequeue+0x1e/0xb0<br /> queue_process+0x2c/0x600<br /> process_scheduled_works+0x4b6/0x850<br /> worker_thread+0x414/0x5a0<br /> Allocated by task 242:<br /> __netpoll_setup+0x201/0x4a0<br /> netpoll_setup+0x249/0x550<br /> enabled_store+0x32f/0x380<br /> Freed by task 0:<br /> kfree+0x1b7/0x540<br /> rcu_core+0x3f8/0x7a0<br /> <br /> The problem happens when there is a pending TX worker running in<br /> parallel with the cleanup path.<br /> <br /> This is what happens on netpoll shutdown path:<br /> <br /> 1) __netpoll_cleanup() is called<br /> 2) set dev-&gt;npinfo to NULL<br /> 3) call_rcu() with rcu_cleanup_netpoll_info()<br /> 3.1) rcu_cleanup_netpoll_info() tries to cancel all workers with<br /> cancel_delayed_work(), but doesn&amp;#39;t wait for the worker to finish<br /> 4) and kfree(npinfo);<br /> <br /> Because 3.1) doesn&amp;#39;t really cancel the work, as the comment says "we<br /> can&amp;#39;t call cancel_delayed_work_sync here, as we are in softirq", the TX<br /> worker can run after 4).<br /> <br /> Tl;DR: queue_process() is not an RCU reader, it reaches npinfo through<br /> the work item via container_of().<br /> <br /> Use disable_delayed_work_sync() to ensure the worker is completely<br /> stopped and prevent any future re-arming attempts. Once npinfo is set<br /> to NULL, senders will bail out and not queue new work. The disable flag<br /> ensures any in-flight re-arming attempts also fail silently.<br /> <br /> In the future, we can do the cleanup inline here without needing the<br /> npinfo-&gt;rcu rcu_head, but that is net-next material.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item<br /> <br /> commit 10dc95939817 ("io_uring/io-wq: check IO_WQ_BIT_EXIT inside work<br /> run loop") fixed the obvious case where io_worker_handle_work() took one<br /> exit-bit snapshot before draining pending work, but the fix stops one<br /> level too early.<br /> <br /> io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work<br /> run loop, yet it still snapshots that bit once before processing a whole<br /> dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT<br /> after the first linked item has started, the remaining linked items can<br /> still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue<br /> running after exit has begun.<br /> <br /> Move the check further inside, so it covers linked items too. Note: this<br /> is a syzbot special as it loves setting up tons of slow linked work on<br /> weird devices like msr that take forever to read, and immediately close<br /> the ring. Exit then takes a long time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/nop: fix file reference leak with IOSQE_FIXED_FILE<br /> <br /> NOP file-acquisition support choses between a fixed (registered) file and<br /> a normal fget()&amp;#39;d file based on its own IORING_NOP_FIXED_FILE flag in<br /> sqe-&gt;nop_flags. However, a request&amp;#39;s REQ_F_FIXED_FILE is set<br /> independently from the generic IOSQE_FIXED_FILE sqe flag during request<br /> init, before the issue handler runs.<br /> <br /> If a NOP is submitted with IOSQE_FIXED_FILE set (so REQ_F_FIXED_FILE is<br /> set) but without IORING_NOP_FIXED_FILE, io_nop() takes the normal path<br /> and grabs a real reference via io_file_get_normal(). On completion,<br /> io_put_file() only drops the reference when REQ_F_FIXED_FILE is clear,<br /> so the fget()&amp;#39;d file is never released and leaks:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff88800f42c240 (size 176):<br /> kmem_cache_alloc_noprof+0x358/0x440<br /> alloc_empty_file+0x57/0x180<br /> path_openat+0x44/0x1e50<br /> do_file_open+0x121/0x200<br /> do_sys_openat2+0xa7/0x150<br /> __x64_sys_openat+0x82/0xf0<br /> <br /> Decide between fixed and normal file acquisition from REQ_F_FIXED_FILE,<br /> the same way io_assign_file() does for every other opcode, and fold<br /> IORING_NOP_FIXED_FILE into REQ_F_FIXED_FILE at prep time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: logitech-dj: Fix maxfield check in DJ short report validation<br /> <br /> Commit b6a57912854e ("HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT<br /> related user initiated OOB write") added validation for the DJ short<br /> output report, but the error path dereferences rep-&gt;field[0] even when<br /> rep-&gt;maxfield is zero.<br /> <br /> Commit 8b9a097eb2fc ("HID: logitech-dj: fix wrong detection of bad<br /> DJ_SHORT output report") made the check conditional on rep being present,<br /> but a crafted descriptor can still create report ID 0x20 with only padding<br /> output items. hid-core registers the report, ignores the padding field,<br /> and leaves rep-&gt;maxfield as zero.<br /> <br /> In that case the validation enters the rep-&gt;maxfield field[0]-&gt;report_count while printing the error message,<br /> causing a NULL pointer dereference during probe. This is reproducible with<br /> uhid by emulating a Logitech receiver with a padding-only DJ short output<br /> report:<br /> <br /> BUG: KASAN: null-ptr-deref in logi_dj_probe+0xb1/0x754 [hid_logitech_dj]<br /> Read of size 4 at addr 0000000000000028 by task kworker/4:1/129<br /> ...<br /> Call Trace:<br /> logi_dj_probe+0xb1/0x754 [hid_logitech_dj]<br /> hid_device_probe+0x329/0x3f0 [hid]<br /> really_probe+0x162/0x570<br /> __device_attach+0x137/0x2c0<br /> bus_probe_device+0x38/0xc0<br /> device_add+0xa56/0xce0<br /> hid_add_device+0x19c/0x280 [hid]<br /> uhid_device_add_worker+0x2c/0xb0 [uhid]<br /> <br /> Reject the zero-field report before printing the field report_count.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: sch: use raw_spinlock_t in the irq startup path<br /> <br /> sch_irq_unmask() enables the GPIO IRQ and then updates the controller<br /> state through sch_irq_mask_unmask(), which takes sch-&gt;lock with<br /> spin_lock_irqsave(). The callback can be reached from irq_startup()<br /> while setting up a requested IRQ. That path is not sleepable, but on<br /> PREEMPT_RT a regular spinlock_t becomes a sleeping lock.<br /> <br /> This issue was found by our static analysis tool and then manually<br /> reviewed against the current tree.<br /> <br /> The grounded PoC kept the request_threaded_irq() -&gt; __setup_irq() -&gt;<br /> irq_startup() -&gt; sch_irq_unmask() -&gt; sch_irq_mask_unmask() carrier and<br /> used the original spin_lock_irqsave(&amp;sch-&gt;lock) edge. Lockdep reported:<br /> <br /> BUG: sleeping function called from invalid context<br /> hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv]<br /> sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv]<br /> sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv]<br /> __setup_irq.constprop.0+0xd/0x30 [vuln_msv]<br /> <br /> Convert the SCH controller lock to raw_spinlock_t. The same lock is<br /> also used by the GPIO direction and value callbacks, but those critical<br /> sections only update MMIO-backed GPIO registers and do not contain<br /> sleepable operations. Keeping this register lock non-sleeping is<br /> therefore appropriate for the irqchip callbacks and does not change the<br /> GPIO-side locking contract.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ebtables: zero chainstack array<br /> <br /> sashiko reports:<br /> looking at ebtables table<br /> translation, could a sparse cpu_possible_mask lead to an uninitialized pointer<br /> free?<br /> <br /> If cpu_possible_mask is sparse (for example, CPU 0 and CPU 2 are possible,<br /> but CPU 1 is not), the allocation loop skips CPU 1. If vmalloc_node() fails at<br /> CPU 2, the cleanup loop will blindly decrement and call vfree() on<br /> newinfo-&gt;chainstack[1].<br /> <br /> Not a real-world bug, such allocation isn&amp;#39;t expected to fail<br /> in the first place.