Kernel panic in fq_codel_enqueue/mq_append under shaped traffic on 26.1.11_6

[AusAgentSmith]

Kernel panic in fq_codel_enqueue during normal shaped traffic on 26.1.11_6

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/src/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/src/issues?q=is%3Aissue

Describe the bug

OPNsense experienced a kernel page-fault panic and hard reboot while FQ_CODEL was enqueueing a packet received through an Intel I226-V interface.

The panic occurred on 2026-07-14 at approximately 04:17:47 UTC during normal network traffic. No traffic-shaper configuration change was being made at the time.

Current version:

• OPNsense 26.1.11_6 (amd64/OpenSSL)
• FreeBSD 14.3-RELEASE-p16

The last version observed without this particular panic was OPNsense 26.1.10 / FreeBSD 14.3-RELEASE-p15. This has not been confirmed by rollback testing, so I cannot establish that the update introduced the problem.

This appears related to closed issue #84, which had a similar fq_codel_enqueue -> dummynet_io -> ipfw_check_packet -> iflib_rxeof backtrace. This report concerns a recurrence on the current release, with the faulting instruction resolved to an invalid queue-tail write.

To Reproduce

The problem is not currently reproducible on demand.

The active configuration when it occurred was:

1. Open Firewall -> Shaper -> Pipes.
2. Configure two pipes using FQ_CODEL:
   • Upload: 400 Mbit/s
   • Download: 1000 Mbit/s
3. Configure FQ_CODEL with:
   • Flows: 1024
   • Limit: 1024
   • Quantum: 1514
   • ECN enabled
4. Configure two weighted child queues per direction, with weights 90 and 10.
5. Use catch-all shaper rules to direct traffic through the pipes.
6. Allow normal network traffic to pass.

The panic occurred after several hours of operation.

Expected behavior

Traffic should continue to be shaped without a kernel panic or reboot.

Describe alternatives you considered

Disabling FQ_CODEL or changing to another scheduler is being considered as an operational workaround. This has not yet been tested because the existing crash evidence was preserved first.

Screenshots

Not applicable. The complete kernel textdump can be attached.

Relevant log files

The relevant crash section is:

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x1f5c9f6d7648
fault code            = supervisor write data, page not present
instruction pointer   = 0x20:0xffffffff83236c21
current process       = 0 (if_io_tqg_0)

rax: 00001f5c9f6d7648

fq_codel_enqueue() at fq_codel_enqueue+0x1c1
dummynet_io() at dummynet_io+0x277
ipfw_check_packet() at ipfw_check_packet+0x1fd
pfil_mbuf_in()
ip_input()
iflib_rxeof()

I compared the fault against the unstripped dummynet.ko from the official OPNsense 26.1.11 kernel set.

The instruction at fq_codel_enqueue+0x1c1 is:

mov QWORD PTR [rax], r14

RAX exactly matches the reported fault address. This maps to the inlined mq_append() queue-tail write:

if (q->head == NULL)
    q->head = m;
else
    q->tail->m_nextpkt = m;

This shows that the immediate failure occurred while writing through an invalid or corrupt queue-tail pointer. It does not establish what originally corrupted that pointer.

The complete textdump was saved as:

/var/crash/textdump.tar.0

Additional context

Traffic-shaper statistics were being queried by monitoring approximately every 15 seconds.

Four Python 3.13 processes also received SIGSEGV before the kernel panic. Hardware memory testing has not yet been completed, so faulty RAM or wider memory corruption has not been excluded.

No resource exhaustion was evident after reboot: there were no mbuf allocation failures, swap exhaustion, excessive temperatures, or high system load.

Environment

• OPNsense 26.1.11_6 (amd64/OpenSSL)
• FreeBSD 14.3-RELEASE-p16
• Intel N100, four cores
• 8 GiB RAM
• Four Intel I226-V interfaces using the igc driver
• Bare-metal installation

AI assistance disclosure

• Model: OpenAI Codex, GPT-5
• Extent: Assisted with crash-log analysis, mapping the faulting instruction to the OPNsense dummynet source, searching historical issues, and editing this report. The human submitter reviewed and validated the report and is responsible for its contents.