Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: QOS: Refactor TC_HTB_LEAF_DEL_LAST callback<br /> <br /> This patch addresses below issues,<br /> <br /> 1. Active traffic on the leaf node must be stopped before its send queue<br /> is reassigned to the parent. This patch resolves the issue by marking<br /> the node as &amp;#39;Inner&amp;#39;.<br /> <br /> 2. During a system reboot, the interface receives TC_HTB_LEAF_DEL<br /> and TC_HTB_LEAF_DEL_LAST callbacks to delete its HTB queues.<br /> In the case of TC_HTB_LEAF_DEL_LAST, although the same send queue<br /> is reassigned to the parent, the current logic still attempts to update<br /> the real number of queues, leadning to below warnings<br /> <br /> New queues can&amp;#39;t be registered after device unregistration.<br /> WARNING: CPU: 0 PID: 6475 at net/core/net-sysfs.c:1714<br /> netdev_queue_update_kobjects+0x1e4/0x200

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: pci: configure manual DAC mode via PCI config API only<br /> <br /> To support 36-bit DMA, configure chip proprietary bit via PCI config API<br /> or chip DBI interface. However, the PCI device mmap isn&amp;#39;t set yet and<br /> the DBI is also inaccessible via mmap, so only if the bit can be accessible<br /> via PCI config API, chip can support 36-bit DMA. Otherwise, fallback to<br /> 32-bit DMA.<br /> <br /> With NULL mmap address, kernel throws trace:<br /> <br /> BUG: unable to handle page fault for address: 0000000000001090<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0002 [#1] PREEMPT SMP PTI<br /> CPU: 1 UID: 0 PID: 71 Comm: irq/26-pciehp Tainted: G OE 6.14.2-061402-generic #202504101348<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> RIP: 0010:rtw89_pci_ops_write16+0x12/0x30 [rtw89_pci]<br /> RSP: 0018:ffffb0ffc0acf9d8 EFLAGS: 00010206<br /> RAX: ffffffffc158f9c0 RBX: ffff94865e702020 RCX: 0000000000000000<br /> RDX: 0000000000000718 RSI: 0000000000001090 RDI: ffff94865e702020<br /> RBP: ffffb0ffc0acf9d8 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000015<br /> R13: 0000000000000719 R14: ffffb0ffc0acfa1f R15: ffffffffc1813060<br /> FS: 0000000000000000(0000) GS:ffff9486f3480000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000001090 CR3: 0000000090440001 CR4: 00000000000626f0<br /> Call Trace:<br /> <br /> rtw89_pci_read_config_byte+0x6d/0x120 [rtw89_pci]<br /> rtw89_pci_cfg_dac+0x5b/0xb0 [rtw89_pci]<br /> rtw89_pci_probe+0xa96/0xbd0 [rtw89_pci]<br /> ? __pfx___device_attach_driver+0x10/0x10<br /> ? __pfx___device_attach_driver+0x10/0x10<br /> local_pci_probe+0x47/0xa0<br /> pci_call_probe+0x5d/0x190<br /> pci_device_probe+0xa7/0x160<br /> really_probe+0xf9/0x370<br /> ? pm_runtime_barrier+0x55/0xa0<br /> __driver_probe_device+0x8c/0x140<br /> driver_probe_device+0x24/0xd0<br /> __device_attach_driver+0xcd/0x170<br /> bus_for_each_drv+0x99/0x100<br /> __device_attach+0xb4/0x1d0<br /> device_attach+0x10/0x20<br /> pci_bus_add_device+0x59/0x90<br /> pci_bus_add_devices+0x31/0x80<br /> pciehp_configure_device+0xaa/0x170<br /> pciehp_enable_slot+0xd6/0x240<br /> pciehp_handle_presence_or_link_change+0xf1/0x180<br /> pciehp_ist+0x162/0x1c0<br /> irq_thread_fn+0x24/0x70<br /> irq_thread+0xef/0x1c0<br /> ? __pfx_irq_thread_fn+0x10/0x10<br /> ? __pfx_irq_thread_dtor+0x10/0x10<br /> ? __pfx_irq_thread+0x10/0x10<br /> kthread+0xfc/0x230<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x47/0x70<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hisi_acc_vfio_pci: bugfix live migration function without VF device driver<br /> <br /> If the VF device driver is not loaded in the Guest OS and we attempt to<br /> perform device data migration, the address of the migrated data will<br /> be NULL.<br /> The live migration recovery operation on the destination side will<br /> access a null address value, which will cause access errors.<br /> <br /> Therefore, live migration of VMs without added VF device drivers<br /> does not require device data migration.<br /> In addition, when the queue address data obtained by the destination<br /> is empty, device queue recovery processing will not be performed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: Add NULL check in mt7996_thermal_init<br /> <br /> devm_kasprintf() can return a NULL pointer on failure,but this<br /> returned value in mt7996_thermal_init() is not checked.<br /> Add NULL check in mt7996_thermal_init(), to handle kernel NULL<br /> pointer dereference error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix WARN() in get_bpf_raw_tp_regs<br /> <br /> syzkaller reported an issue:<br /> <br /> WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861<br /> Modules linked in:<br /> CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861<br /> RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c<br /> RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005<br /> RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003<br /> R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004<br /> R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900<br /> FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline]<br /> bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931<br /> bpf_prog_ec3b2eefa702d8d3+0x43/0x47<br /> bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]<br /> __bpf_prog_run include/linux/filter.h:718 [inline]<br /> bpf_prog_run include/linux/filter.h:725 [inline]<br /> __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline]<br /> bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405<br /> __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47<br /> __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47<br /> __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]<br /> trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]<br /> __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35<br /> __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline]<br /> mmap_read_trylock include/linux/mmap_lock.h:204 [inline]<br /> stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157<br /> __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483<br /> ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline]<br /> bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496<br /> ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline]<br /> bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931<br /> bpf_prog_ec3b2eefa702d8d3+0x43/0x47<br /> <br /> Tracepoint like trace_mmap_lock_acquire_returned may cause nested call<br /> as the corner case show above, which will be resolved with more general<br /> method in the future. As a result, WARN_ON_ONCE will be triggered. As<br /> Alexei suggested, remove the WARN_ON_ONCE first.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kernfs: Relax constraint in draining guard<br /> <br /> The active reference lifecycle provides the break/unbreak mechanism but<br /> the active reference is not truly active after unbreak -- callers don&amp;#39;t<br /> use it afterwards but it&amp;#39;s important for proper pairing of kn-&gt;active<br /> counting. Assuming this mechanism is in place, the WARN check in<br /> kernfs_should_drain_open_files() is too sensitive -- it may transiently<br /> catch those (rightful) callers between<br /> kernfs_unbreak_active_protection() and kernfs_put_active() as found out by Chen<br /> Ridong:<br /> <br /> kernfs_remove_by_name_ns kernfs_get_active // active=1<br /> __kernfs_remove // active=0x80000002<br /> kernfs_drain ...<br /> wait_event<br /> //waiting (active == 0x80000001)<br /> kernfs_break_active_protection<br /> // active = 0x80000001<br /> // continue<br /> kernfs_unbreak_active_protection<br /> // active = 0x80000002<br /> ...<br /> kernfs_should_drain_open_files<br /> // warning occurs<br /> kernfs_put_active<br /> <br /> To avoid the false positives (mind panic_on_warn) remove the check altogether.<br /> (This is meant as quick fix, I think active reference break/unbreak may be<br /> simplified with larger rework.)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Avoid __bpf_prog_ret0_warn when jit fails<br /> <br /> syzkaller reported an issue:<br /> <br /> WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357<br /> Modules linked in:<br /> CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 6.15.0-rc4-syzkaller-00040-g8bac8898fe39<br /> RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357<br /> Call Trace:<br /> <br /> bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]<br /> __bpf_prog_run include/linux/filter.h:718 [inline]<br /> bpf_prog_run include/linux/filter.h:725 [inline]<br /> cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105<br /> ...<br /> <br /> When creating bpf program, &amp;#39;fp-&gt;jit_requested&amp;#39; depends on bpf_jit_enable.<br /> This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not set<br /> and bpf_jit_enable is set to 1, causing the arch to attempt JIT the prog,<br /> but jit failed due to FAULT_INJECTION. As a result, incorrectly<br /> treats the program as valid, when the program runs it calls<br /> `__bpf_prog_ret0_warn` and triggers the WARN_ON_ONCE(1).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: nand: ecc-mxic: Fix use of uninitialized variable ret<br /> <br /> If ctx-&gt;steps is zero, the loop processing ECC steps is skipped,<br /> and the variable ret remains uninitialized. It is later checked<br /> and returned, which leads to undefined behavior and may cause<br /> unpredictable results in user space or kernel crashes.<br /> <br /> This scenario can be triggered in edge cases such as misconfigured<br /> geometry, ECC engine misuse, or if ctx-&gt;steps is not validated<br /> after initialization.<br /> <br /> Initialize ret to zero before the loop to ensure correct and safe<br /> behavior regardless of the ctx-&gt;steps value.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Do not include stack ptr register in precision backtracking bookkeeping<br /> <br /> Yi Lai reported an issue ([1]) where the following warning appears<br /> in kernel dmesg:<br /> [ 60.643604] verifier backtracking bug<br /> [ 60.643635] WARNING: CPU: 10 PID: 2315 at kernel/bpf/verifier.c:4302 __mark_chain_precision+0x3a6c/0x3e10<br /> [ 60.648428] Modules linked in: bpf_testmod(OE)<br /> [ 60.650471] CPU: 10 UID: 0 PID: 2315 Comm: test_progs Tainted: G OE 6.15.0-rc4-gef11287f8289-dirty #327 PREEMPT(full)<br /> [ 60.654385] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> [ 60.656682] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 60.660475] RIP: 0010:__mark_chain_precision+0x3a6c/0x3e10<br /> [ 60.662814] Code: 5a 30 84 89 ea e8 c4 d9 01 00 80 3d 3e 7d d8 04 00 0f 85 60 fa ff ff c6 05 31 7d d8 04<br /> 01 48 c7 c7 00 58 30 84 e8 c4 06 a5 ff 0b e9 46 fa ff ff 48 ...<br /> [ 60.668720] RSP: 0018:ffff888116cc7298 EFLAGS: 00010246<br /> [ 60.671075] RAX: 54d70e82dfd31900 RBX: ffff888115b65e20 RCX: 0000000000000000<br /> [ 60.673659] RDX: 0000000000000001 RSI: 0000000000000004 RDI: 00000000ffffffff<br /> [ 60.676241] RBP: 0000000000000400 R08: ffff8881f6f23bd3 R09: 1ffff1103ede477a<br /> [ 60.678787] R10: dffffc0000000000 R11: ffffed103ede477b R12: ffff888115b60ae8<br /> [ 60.681420] R13: 1ffff11022b6cbc4 R14: 00000000fffffff2 R15: 0000000000000001<br /> [ 60.684030] FS: 00007fc2aedd80c0(0000) GS:ffff88826fa8a000(0000) knlGS:0000000000000000<br /> [ 60.686837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 60.689027] CR2: 000056325369e000 CR3: 000000011088b002 CR4: 0000000000370ef0<br /> [ 60.691623] Call Trace:<br /> [ 60.692821] <br /> [ 60.693960] ? __pfx_verbose+0x10/0x10<br /> [ 60.695656] ? __pfx_disasm_kfunc_name+0x10/0x10<br /> [ 60.697495] check_cond_jmp_op+0x16f7/0x39b0<br /> [ 60.699237] do_check+0x58fa/0xab10<br /> ...<br /> <br /> Further analysis shows the warning is at line 4302 as below:<br /> <br /> 4294 /* static subprog call instruction, which<br /> 4295 * means that we are exiting current subprog,<br /> 4296 * so only r1-r5 could be still requested as<br /> 4297 * precise, r0 and r6-r10 or any stack slot in<br /> 4298 * the current frame should be zero by now<br /> 4299 */<br /> 4300 if (bt_reg_mask(bt) &amp; ~BPF_REGMASK_ARGS) {<br /> 4301 verbose(env, "BUG regs %x\n", bt_reg_mask(bt));<br /> 4302 WARN_ONCE(1, "verifier backtracking bug");<br /> 4303 return -EFAULT;<br /> 4304 }<br /> <br /> With the below test (also in the next patch):<br /> __used __naked static void __bpf_jmp_r10(void)<br /> {<br /> asm volatile (<br /> "r2 = 2314885393468386424 ll;"<br /> "goto +0;"<br /> "if r2 = -1835016 goto +0;"<br /> "if r2

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/dax: Fix "don&amp;#39;t skip locked entries when scanning entries"<br /> <br /> Commit 6be3e21d25ca ("fs/dax: don&amp;#39;t skip locked entries when scanning<br /> entries") introduced a new function, wait_entry_unlocked_exclusive(),<br /> which waits for the current entry to become unlocked without advancing<br /> the XArray iterator state.<br /> <br /> Waiting for the entry to become unlocked requires dropping the XArray<br /> lock. This requires calling xas_pause() prior to dropping the lock<br /> which leaves the xas in a suitable state for the next iteration. However<br /> this has the side-effect of advancing the xas state to the next index.<br /> Normally this isn&amp;#39;t an issue because xas_for_each() contains code to<br /> detect this state and thus avoid advancing the index a second time on<br /> the next loop iteration.<br /> <br /> However both callers of and wait_entry_unlocked_exclusive() itself<br /> subsequently use the xas state to reload the entry. As xas_pause()<br /> updated the state to the next index this will cause the current entry<br /> which is being waited on to be skipped. This caused the following<br /> warning to fire intermittently when running xftest generic/068 on an XFS<br /> filesystem with FS DAX enabled:<br /> <br /> [ 35.067397] ------------[ cut here ]------------<br /> [ 35.068229] WARNING: CPU: 21 PID: 1640 at mm/truncate.c:89 truncate_folio_batch_exceptionals+0xd8/0x1e0<br /> [ 35.069717] Modules linked in: nd_pmem dax_pmem nd_btt nd_e820 libnvdimm<br /> [ 35.071006] CPU: 21 UID: 0 PID: 1640 Comm: fstest Not tainted 6.15.0-rc7+ #77 PREEMPT(voluntary)<br /> [ 35.072613] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/204<br /> [ 35.074845] RIP: 0010:truncate_folio_batch_exceptionals+0xd8/0x1e0<br /> [ 35.075962] Code: a1 00 00 00 f6 47 0d 20 0f 84 97 00 00 00 4c 63 e8 41 39 c4 7f 0b eb 61 49 83 c5 01 45 39 ec 7e 58 42 f68<br /> [ 35.079522] RSP: 0018:ffffb04e426c7850 EFLAGS: 00010202<br /> [ 35.080359] RAX: 0000000000000000 RBX: ffff9d21e3481908 RCX: ffffb04e426c77f4<br /> [ 35.081477] RDX: ffffb04e426c79e8 RSI: ffffb04e426c79e0 RDI: ffff9d21e34816e8<br /> [ 35.082590] RBP: ffffb04e426c79e0 R08: 0000000000000001 R09: 0000000000000003<br /> [ 35.083733] R10: 0000000000000000 R11: 822b53c0f7a49868 R12: 000000000000001f<br /> [ 35.084850] R13: 0000000000000000 R14: ffffb04e426c78e8 R15: fffffffffffffffe<br /> [ 35.085953] FS: 00007f9134c87740(0000) GS:ffff9d22abba0000(0000) knlGS:0000000000000000<br /> [ 35.087346] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 35.088244] CR2: 00007f9134c86000 CR3: 000000040afff000 CR4: 00000000000006f0<br /> [ 35.089354] Call Trace:<br /> [ 35.089749] <br /> [ 35.090168] truncate_inode_pages_range+0xfc/0x4d0<br /> [ 35.091078] truncate_pagecache+0x47/0x60<br /> [ 35.091735] xfs_setattr_size+0xc7/0x3e0<br /> [ 35.092648] xfs_vn_setattr+0x1ea/0x270<br /> [ 35.093437] notify_change+0x1f4/0x510<br /> [ 35.094219] ? do_truncate+0x97/0xe0<br /> [ 35.094879] do_truncate+0x97/0xe0<br /> [ 35.095640] path_openat+0xabd/0xca0<br /> [ 35.096278] do_filp_open+0xd7/0x190<br /> [ 35.096860] do_sys_openat2+0x8a/0xe0<br /> [ 35.097459] __x64_sys_openat+0x6d/0xa0<br /> [ 35.098076] do_syscall_64+0xbb/0x1d0<br /> [ 35.098647] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 35.099444] RIP: 0033:0x7f9134d81fc1<br /> [ 35.100033] Code: 75 57 89 f0 25 00 00 41 00 3d 00 00 41 00 74 49 80 3d 2a 26 0e 00 00 74 6d 89 da 48 89 ee bf 9c ff ff ff5<br /> [ 35.102993] RSP: 002b:00007ffcd41e0d10 EFLAGS: 00000202 ORIG_RAX: 0000000000000101<br /> [ 35.104263] RAX: ffffffffffffffda RBX: 0000000000000242 RCX: 00007f9134d81fc1<br /> [ 35.105452] RDX: 0000000000000242 RSI: 00007ffcd41e1200 RDI: 00000000ffffff9c<br /> [ 35.106663] RBP: 00007ffcd41e1200 R08: 0000000000000000 R09: 0000000000000064<br /> [ 35.107923] R10: 00000000000001a4 R11: 0000000000000202 R12: 0000000000000066<br /> [ 35.109112] R13: 0000000000100000 R14: 0000000000100000 R15: 0000000000000400<br /> [ 35.110357] <br /> [ 35.110769] irq event stamp: 8415587<br /> [ 35.111486] hardirqs last enabled at (8415599): [] __up_console_se<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: exit after state insertion failure at btrfs_convert_extent_bit()<br /> <br /> If insert_state() state failed it returns an error pointer and we call<br /> extent_io_tree_panic() which will trigger a BUG() call. However if<br /> CONFIG_BUG is disabled, which is an uncommon and exotic scenario, then<br /> we fallthrough and call cache_state() which will dereference the error<br /> pointer, resulting in an invalid memory access.<br /> <br /> So jump to the &amp;#39;out&amp;#39; label after calling extent_io_tree_panic(), it also<br /> makes the code more clear besides dealing with the exotic scenario where<br /> CONFIG_BUG is disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: drv: netdevsim: don&amp;#39;t napi_complete() from netpoll<br /> <br /> netdevsim supports netpoll. Make sure we don&amp;#39;t call napi_complete()<br /> from it, since it may not be scheduled. Breno reports hitting a<br /> warning in napi_complete_done():<br /> <br /> WARNING: CPU: 14 PID: 104 at net/core/dev.c:6592 napi_complete_done+0x2cc/0x560<br /> __napi_poll+0x2d8/0x3a0<br /> handle_softirqs+0x1fe/0x710<br /> <br /> This is presumably after netpoll stole the SCHED bit prematurely.