Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: Fix race bug in nvme_poll_irqdisable()<br /> <br /> In the following scenario, pdev can be disabled between (1) and (3) by<br /> (2). This sets pdev-&gt;msix_enabled = 0. Then, pci_irq_vector() will<br /> return MSI-X IRQ(&gt;15) for (1) whereas return INTx IRQ(cq_vector)) ...(1)<br /> enable_irq(pci_irq_vector(pdev, nvmeq-&gt;cq_vector)) ...(3)<br /> <br /> task 2:<br /> nvme_reset_work()<br /> nvme_dev_disable()<br /> pdev-&gt;msix_enable = 0; ...(2)<br /> <br /> crash log:<br /> <br /> ------------[ cut here ]------------<br /> Unbalanced enable for IRQ 10<br /> WARNING: kernel/irq/manage.c:753 at __enable_irq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> Workqueue: kblockd blk_mq_timeout_work<br /> RIP: 0010:__enable_irq+0x107/0x190 kernel/irq/manage.c:753<br /> Code: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9<br /> RSP: 0018:ffffc900001bf550 EFLAGS: 00010046<br /> RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90<br /> RDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0<br /> RBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001<br /> R10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000<br /> R13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293<br /> FS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> enable_irq+0x121/0x1e0 kernel/irq/manage.c:797<br /> nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494<br /> nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744<br /> blk_mq_rq_timed_out block/blk-mq.c:1653 [inline]<br /> blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c:1721<br /> bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c:292<br /> __sbitmap_for_each_set include/linux/sbitmap.h:269 [inline]<br /> sbitmap_for_each_set include/linux/sbitmap.h:290 [inline]<br /> bt_for_each block/blk-mq-tag.c:324 [inline]<br /> blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c:536<br /> blk_mq_timeout_work+0x627/0x870 block/blk-mq.c:1763<br /> process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqueue.c:3340 [inline]<br /> worker_thread+0x65c/0xe60 kernel/workqueue.c:3421<br /> kthread+0x41a/0x930 kernel/kthread.c:463<br /> ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> irq event stamp: 74478<br /> hardirqs last enabled at (74477): [] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:159 [inline]<br /> hardirqs last enabled at (74477): [] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c:202<br /> hardirqs last disabled at (74478): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]<br /> hardirqs last disabled at (74478): [] _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:162<br /> softirqs last enabled at (74304): [] __do_softirq kernel/softirq.c:656 [inline]<br /> softirqs last enabled at (74304): [] invoke_softirq kernel/softirq.c:496 [inline]<br /> softirqs last enabled at (74304): [] __irq_exit_rcu+0xdc/0x120<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_set<br /> <br /> dev-&gt;online_queues is a count incremented in nvme_init_queue. Thus,<br /> valid indices are 0 through dev-&gt;online_queues − 1.<br /> <br /> This patch fixes the loop condition to ensure the index stays within the<br /> valid range. Index 0 is excluded because it is the admin queue.<br /> <br /> KASAN splat:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline]<br /> BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404<br /> Read of size 2 at addr ffff88800592a574 by task kworker/u8:5/74<br /> <br /> CPU: 0 UID: 0 PID: 74 Comm: kworker/u8:5 Not tainted 6.19.0-dirty #10 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> Workqueue: nvme-reset-wq nvme_reset_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0xea/0x150 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xce/0x5d0 mm/kasan/report.c:482<br /> kasan_report+0xdc/0x110 mm/kasan/report.c:595<br /> __asan_report_load2_noabort+0x18/0x20 mm/kasan/report_generic.c:379<br /> nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline]<br /> nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404<br /> nvme_reset_work+0x36b/0x8c0 drivers/nvme/host/pci.c:3252<br /> process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqueue.c:3340 [inline]<br /> worker_thread+0x65c/0xe60 kernel/workqueue.c:3421<br /> kthread+0x41a/0x930 kernel/kthread.c:463<br /> ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> <br /> Allocated by task 34 on cpu 1 at 4.241550s:<br /> kasan_save_stack+0x2c/0x60 mm/kasan/common.c:57<br /> kasan_save_track+0x1c/0x70 mm/kasan/common.c:78<br /> kasan_save_alloc_info+0x3c/0x50 mm/kasan/generic.c:570<br /> poison_kmalloc_redzone mm/kasan/common.c:398 [inline]<br /> __kasan_kmalloc+0xb5/0xc0 mm/kasan/common.c:415<br /> kasan_kmalloc include/linux/kasan.h:263 [inline]<br /> __do_kmalloc_node mm/slub.c:5657 [inline]<br /> __kmalloc_node_noprof+0x2bf/0x8d0 mm/slub.c:5663<br /> kmalloc_array_node_noprof include/linux/slab.h:1075 [inline]<br /> nvme_pci_alloc_dev drivers/nvme/host/pci.c:3479 [inline]<br /> nvme_probe+0x2f1/0x1820 drivers/nvme/host/pci.c:3534<br /> local_pci_probe+0xef/0x1c0 drivers/pci/pci-driver.c:324<br /> pci_call_probe drivers/pci/pci-driver.c:392 [inline]<br /> __pci_device_probe drivers/pci/pci-driver.c:417 [inline]<br /> pci_device_probe+0x743/0x920 drivers/pci/pci-driver.c:451<br /> call_driver_probe drivers/base/dd.c:583 [inline]<br /> really_probe+0x29b/0xb70 drivers/base/dd.c:661<br /> __driver_probe_device+0x3b0/0x4a0 drivers/base/dd.c:803<br /> driver_probe_device+0x56/0x1f0 drivers/base/dd.c:833<br /> __driver_attach_async_helper+0x155/0x340 drivers/base/dd.c:1159<br /> async_run_entry_fn+0xa6/0x4b0 kernel/async.c:129<br /> process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqueue.c:3340 [inline]<br /> worker_thread+0x65c/0xe60 kernel/workqueue.c:3421<br /> kthread+0x41a/0x930 kernel/kthread.c:463<br /> ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> The buggy address belongs to the object at ffff88800592a000<br /> which belongs to the cache kmalloc-2k of size 2048<br /> The buggy address is located 244 bytes to the right of<br /> allocated 1152-byte region [ffff88800592a000, ffff88800592a480)<br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5928<br /> head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0<br /> anon flags: 0xfffffc0000040(head|node=0|zone=1|lastcpupid=0x1fffff)<br /> page_type: f5(slab)<br /> raw: 000fffffc0000040 ffff888001042000 0000000000000000 dead000000000001<br /> raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000<br /> head: 000fffffc0000040 ffff888001042000 00000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table()<br /> <br /> nfnl_cthelper_dump_table() has a &amp;#39;goto restart&amp;#39; that jumps to a label<br /> inside the for loop body. When the "last" helper saved in cb-&gt;args[1]<br /> is deleted between dump rounds, every entry fails the (cur != last)<br /> check, so cb-&gt;args[1] is never cleared. The for loop finishes with<br /> cb-&gt;args[0] == nf_ct_helper_hsize, and the &amp;#39;goto restart&amp;#39; jumps back<br /> into the loop body bypassing the bounds check, causing an 8-byte<br /> out-of-bounds read on nf_ct_helper_hash[nf_ct_helper_hsize].<br /> <br /> The &amp;#39;goto restart&amp;#39; block was meant to re-traverse the current bucket<br /> when "last" is no longer found, but it was placed after the for loop<br /> instead of inside it. Move the block into the for loop body so that<br /> the restart only occurs while cb-&gt;args[0] is still within bounds.<br /> <br /> BUG: KASAN: slab-out-of-bounds in nfnl_cthelper_dump_table+0x9f/0x1b0<br /> Read of size 8 at addr ffff888104ca3000 by task poc_cthelper/131<br /> Call Trace:<br /> nfnl_cthelper_dump_table+0x9f/0x1b0<br /> netlink_dump+0x333/0x880<br /> netlink_recvmsg+0x3e2/0x4b0<br /> sock_recvmsg+0xde/0xf0<br /> __sys_recvfrom+0x150/0x200<br /> __x64_sys_recvfrom+0x76/0x90<br /> do_syscall_64+0xc3/0x6e0<br /> <br /> Allocated by task 1:<br /> __kvmalloc_node_noprof+0x21b/0x700<br /> nf_ct_alloc_hashtable+0x65/0xd0<br /> nf_conntrack_helper_init+0x21/0x60<br /> nf_conntrack_init_start+0x18d/0x300<br /> nf_conntrack_standalone_init+0x12/0xc0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_queue: fix entry leak in bridge verdict error path<br /> <br /> nfqnl_recv_verdict() calls find_dequeue_entry() to remove the queue<br /> entry from the queue data structures, taking ownership of the entry.<br /> For PF_BRIDGE packets, it then calls nfqa_parse_bridge() to parse VLAN<br /> attributes. If nfqa_parse_bridge() returns an error (e.g. NFQA_VLAN<br /> present but NFQA_VLAN_TCI missing), the function returns immediately<br /> without freeing the dequeued entry or its sk_buff.<br /> <br /> This leaks the nf_queue_entry, its associated sk_buff, and all held<br /> references (net_device refcounts, struct net refcount). Repeated<br /> triggering exhausts kernel memory.<br /> <br /> Fix this by dropping the entry via nfqnl_reinject() with NF_DROP verdict<br /> on the error path, consistent with other error handling in this file.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: x_tables: guard option walkers against 1-byte tail reads<br /> <br /> When the last byte of options is a non-single-byte option kind, walkers<br /> that advance with i += op[i + 1] ? : 1 can read op[i + 1] past the end<br /> of the option area.<br /> <br /> Add an explicit i == optlen - 1 check before dereferencing op[i + 1]<br /> in xt_tcpudp and xt_dccp option walkers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain()<br /> <br /> In the drain loop, the local variable &amp;#39;runtime&amp;#39; is reassigned to a<br /> linked stream&amp;#39;s runtime (runtime = s-&gt;runtime at line 2157). After<br /> releasing the stream lock at line 2169, the code accesses<br /> runtime-&gt;no_period_wakeup, runtime-&gt;rate, and runtime-&gt;buffer_size<br /> (lines 2170-2178) — all referencing the linked stream&amp;#39;s runtime without<br /> any lock or refcount protecting its lifetime.<br /> <br /> A concurrent close() on the linked stream&amp;#39;s fd triggers<br /> snd_pcm_release_substream() → snd_pcm_drop() → pcm_release_private()<br /> → snd_pcm_unlink() → snd_pcm_detach_substream() → kfree(runtime).<br /> No synchronization prevents kfree(runtime) from completing while the<br /> drain path dereferences the stale pointer.<br /> <br /> Fix by caching the needed runtime fields (no_period_wakeup, rate,<br /> buffer_size) into local variables while still holding the stream lock,<br /> and using the cached values after the lock is released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Remove redundant css_put() in scx_cgroup_init()<br /> <br /> The iterator css_for_each_descendant_pre() walks the cgroup hierarchy<br /> under cgroup_lock(). It does not increment the reference counts on<br /> yielded css structs.<br /> <br /> According to the cgroup documentation, css_put() should only be used<br /> to release a reference obtained via css_get() or css_tryget_online().<br /> Since the iterator does not use either of these to acquire a reference,<br /> calling css_put() in the error path of scx_cgroup_init() causes a<br /> refcount underflow.<br /> <br /> Remove the unbalanced css_put() to prevent a potential Use-After-Free<br /> (UAF) vulnerability.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup: fix race between task migration and iteration<br /> <br /> When a task is migrated out of a css_set, cgroup_migrate_add_task()<br /> first moves it from cset-&gt;tasks to cset-&gt;mg_tasks via:<br /> <br /> list_move_tail(&amp;task-&gt;cg_list, &amp;cset-&gt;mg_tasks);<br /> <br /> If a css_task_iter currently has it-&gt;task_pos pointing to this task,<br /> css_set_move_task() calls css_task_iter_skip() to keep the iterator<br /> valid. However, since the task has already been moved to -&gt;mg_tasks,<br /> the iterator is advanced relative to the mg_tasks list instead of the<br /> original tasks list. As a result, remaining tasks on cset-&gt;tasks, as<br /> well as tasks queued on cset-&gt;mg_tasks, can be skipped by iteration.<br /> <br /> Fix this by calling css_set_skip_task_iters() before unlinking<br /> task-&gt;cg_list from cset-&gt;tasks. This advances all active iterators to<br /> the next task on cset-&gt;tasks, so iteration continues correctly even<br /> when a task is concurrently being migrated.<br /> <br /> This race is hard to hit in practice without instrumentation, but it<br /> can be reproduced by artificially slowing down cgroup_procs_show().<br /> For example, on an Android device a temporary<br /> /sys/kernel/cgroup/cgroup_test knob can be added to inject a delay<br /> into cgroup_procs_show(), and then:<br /> <br /> 1) Spawn three long-running tasks (PIDs 101, 102, 103).<br /> 2) Create a test cgroup and move the tasks into it.<br /> 3) Enable a large delay via /sys/kernel/cgroup/cgroup_test.<br /> 4) In one shell, read cgroup.procs from the test cgroup.<br /> 5) Within the delay window, in another shell migrate PID 102 by<br /> writing it to a different cgroup.procs file.<br /> <br /> Under this setup, cgroup.procs can intermittently show only PID 101<br /> while skipping PID 103. Once the migration completes, reading the<br /> file again shows all tasks as expected.<br /> <br /> Note that this change does not allow removing the existing<br /> css_set_skip_task_iters() call in css_set_move_task(). The new call<br /> in cgroup_migrate_add_task() only handles iterators that are racing<br /> with migration while the task is still on cset-&gt;tasks. Iterators may<br /> also start after the task has been moved to cset-&gt;mg_tasks. If we<br /> dropped css_set_skip_task_iters() from css_set_move_task(), such<br /> iterators could keep task_pos pointing to a migrating task, causing<br /> css_task_iter_advance() to malfunction on the destination css_set,<br /> up to and including crashes or infinite loops.<br /> <br /> The race window between migration and iteration is very small, and<br /> css_task_iter is not on a hot path. In the worst case, when an<br /> iterator is positioned on the first thread of the migrating process,<br /> cgroup_migrate_add_task() may have to skip multiple tasks via<br /> css_set_skip_task_iters(). However, this only happens when migration<br /> and iteration actually race, so the performance impact is negligible<br /> compared to the correctness fix provided here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mana: Null service_wq on setup error to prevent double destroy<br /> <br /> In mana_gd_setup() error path, set gc-&gt;service_wq to NULL after<br /> destroy_workqueue() to match the cleanup in mana_gd_cleanup().<br /> This prevents a use-after-free if the workqueue pointer is checked<br /> after a failed setup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bonding: Fix nd_tbl NULL dereference when IPv6 is disabled<br /> <br /> When booting with the &amp;#39;ipv6.disable=1&amp;#39; parameter, the nd_tbl is never<br /> initialized because inet6_init() exits before ndisc_init() is called<br /> which initializes it. If bonding ARP/NS validation is enabled, an IPv6<br /> NS/NA packet received on a slave can reach bond_validate_na(), which<br /> calls bond_has_this_ip6(). That path calls ipv6_chk_addr() and can<br /> crash in __ipv6_chk_addr_and_flags().<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000005d8<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> RIP: 0010:__ipv6_chk_addr_and_flags+0x69/0x170<br /> Call Trace:<br /> <br /> ipv6_chk_addr+0x1f/0x30<br /> bond_validate_na+0x12e/0x1d0 [bonding]<br /> ? __pfx_bond_handle_frame+0x10/0x10 [bonding]<br /> bond_rcv_validate+0x1a0/0x450 [bonding]<br /> bond_handle_frame+0x5e/0x290 [bonding]<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> __netif_receive_skb_core.constprop.0+0x3e8/0xe50<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? update_cfs_rq_load_avg+0x1a/0x240<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __enqueue_entity+0x5e/0x240<br /> __netif_receive_skb_one_core+0x39/0xa0<br /> process_backlog+0x9c/0x150<br /> __napi_poll+0x30/0x200<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> net_rx_action+0x338/0x3b0<br /> handle_softirqs+0xc9/0x2a0<br /> do_softirq+0x42/0x60<br /> <br /> <br /> __local_bh_enable_ip+0x62/0x70<br /> __dev_queue_xmit+0x2d3/0x1000<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? packet_parse_headers+0x10a/0x1a0<br /> packet_sendmsg+0x10da/0x1700<br /> ? kick_pool+0x5f/0x140<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __queue_work+0x12d/0x4f0<br /> __sys_sendto+0x1f3/0x220<br /> __x64_sys_sendto+0x24/0x30<br /> do_syscall_64+0x101/0xf80<br /> ? exc_page_fault+0x6e/0x170<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> Fix this by checking ipv6_mod_enabled() before dispatching IPv6 packets to<br /> bond_na_rcv(). If IPv6 is disabled, return early from bond_rcv_validate()<br /> and avoid the path to ipv6_chk_addr().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: fix physical SQE bounds check for SQE_MIXED 128-byte ops<br /> <br /> When IORING_SETUP_SQE_MIXED is used without IORING_SETUP_NO_SQARRAY,<br /> the boundary check for 128-byte SQE operations in io_init_req()<br /> validated the logical SQ head position rather than the physical SQE<br /> index.<br /> <br /> The existing check:<br /> <br /> !(ctx-&gt;cached_sq_head &amp; (ctx-&gt;sq_entries - 1))<br /> <br /> ensures the logical position isn&amp;#39;t at the end of the ring, which is<br /> correct for NO_SQARRAY rings where physical == logical. However, when<br /> sq_array is present, an unprivileged user can remap any logical<br /> position to an arbitrary physical index via sq_array. Setting<br /> sq_array[N] = sq_entries - 1 places a 128-byte operation at the last<br /> physical SQE slot, causing the 128-byte memcpy in<br /> io_uring_cmd_sqe_copy() to read 64 bytes past the end of the SQE<br /> array.<br /> <br /> Replace the cached_sq_head alignment check with a direct validation<br /> of the physical SQE index, which correctly handles both sq_array and<br /> NO_SQARRAY cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: amd: acp-mach-common: Add missing error check for clock acquisition<br /> <br /> The acp_card_rt5682_init() and acp_card_rt5682s_init() functions did not<br /> check the return values of clk_get(). This could lead to a kernel crash<br /> when the invalid pointers are later dereferenced by clock core<br /> functions.<br /> <br /> Fix this by:<br /> 1. Changing clk_get() to the device-managed devm_clk_get().<br /> 2. Adding IS_ERR() checks immediately after each clock acquisition.