Mikrotik.moscow [тема: Результат теста: Ядро CCR выдало ошибку (Kernel panic) 6.8rc1 (обновлено: 11-01-2014)]

Результат теста: Ядро CCR выдало ошибку (Kernel panic) 6.8rc1 (обновлено: 11-01-2014)

Sat, 11 Jan 2014 05:03:00 -0500

Результат теста: Ядро CCR выдало ошибку (Kernel panic) 6.8rc1 (обновлено: 11-01-2014) RouterOS в форуме RouterOS.
Okay, let's break down the provided crash dump information. This looks like a kernel crash dump related to a driver or system call within a Linux-based system (likely Android, given the CPU architecture and stack traces). Here's a structured analysis of the errors and what it likely indicates, focusing on interpreting the most important parts:

**1. The Error: Kernel Panic & `strnlen` Failure**

* **`Kernel Panic`**: This is the ultimate sign of a serious system error. The kernel is unable to continue operating safely.
* **`strnlen` Failure**: The core problem seems to stem from a call to the `strnlen` function, which calculates the length of a null-terminated string. `strnlen` is crucial for preventing buffer overflows. The fact that it's failing strongly suggests an invalid string being passed to it, or a calculation leading to an out-of-bounds access.

**2. Trace of Function Calls Leading to the Error**

The stack trace shows the sequence of function calls that ultimately resulted in the `strnlen` failure. Let's follow it from the bottom up (which is how stacks are organized):

* **`... (Bottom of Stack)`:** (Implied, these are lower-level system calls)
* **`vfs_read`:** A kernel function for reading data from a virtual filesystem. This implies that the problem originated during a read operation.
* **`SyS_read`:** The system call interface for `read`. This is the function that user-space applications (like the `net` process in this case) call to request data from the kernel.
* **`handle_syscall`:** The kernel's entry point for system calls.
* **`seq_read`**: This function likely handles sequential reading, possibly from a driver or character device.
* **`seq_printf`**: A function often used within kernel modules for formatted output to a sequence file. This is a *very* significant clue. It suggests that an attempt was made to print a string within the kernel's code, but something went wrong with the string's construction or length calculation.
* **`show_interrupts`**: A function used to display interrupt information. Interrupts are signals triggered by hardware.
* **`handle_syscall`:** Again, the system call handler.
* **`SyS_read`:** The system call interface.
* **`vfs_read`:** The virtual filesystem read function.
* **`strnlen`**: The point of failure. It's clear that a string of an unexpected length or containing invalid characters was provided as input to `strnlen`.
* **`string.isra.2`**: This is an optimization function. It does not provide helpful details, but confirms that `strnlen` is called from an optimized context.

**3. Processes Involved**

* **`tid 279, pid 279 (net)`**: The crash originated within a process with ID 279. The name "net" indicates it's likely related to network functionality (networking driver, network manager, etc.). This is a primary suspect.
* **`tid 279`**: Indicates the crash is happening on the context of the `net` thread/process.

**4. Key Suspect Areas**

* **Networking Driver/Stack**: The most probable source is a networking driver or a networking-related stack within the kernel. This could be the driver for a network interface card (NIC), a wireless adapter, or a virtual network adapter.
* **`seq_printf`**: This points to an area within the kernel where formatted output is being generated. It suggests a driver or module is trying to log or display information, and the string being constructed for output is the problem. The fact that it is using sequence files is also important. This is related to tracing and debugging facilities within the kernel.
* **Kernel Log Output**: A driver or module might be attempting to print debugging information to the kernel log, and the string it is trying to output is malformed.

**5. Interpreting the Cycle Number**

The "cycle" numbers provided in the crash dump are hardware-specific timers. They are mostly irrelevant for debugging.

**6. Possible Causes and Debugging Steps**

* **Buffer Overflow**: The most likely cause is a buffer overflow. A buffer allocated to hold a string is either too small or is being overwritten, leading to an out-of-bounds access when calculating the string's length.
* **Incorrect String Length Calculation**: The code might be incorrectly calculating the length of a string, leading `strnlen` to receive an invalid value.
* **Null Pointer or Uninitialized String**: A null pointer or an uninitialized string might be passed to `strnlen`.
* **Hardware Interaction:** The bug might be related to the interaction between the kernel and a hardware device. Perhaps a device is providing unexpected data, leading to an invalid string being constructed.
* **Race Condition:** A race condition is possible, but less probable given the stack trace.

**Debugging Suggestions:**

1. **Examine the Networking Driver Code:** Start by thoroughly examining the code for the networking driver, especially any code that handles string manipulation or formatted output (using `seq_printf`).
2. **Kernel Logs and Traces:** Analyze the kernel logs for any related errors or warnings. You can use tools like `dmesg` to view the kernel log. Consider enabling more verbose kernel logging to capture more information.
3. **Kernel Debugger**: Use a kernel debugger (like GDB with QEMU) to step through the code and examine the values of variables at the time of the crash.
4. **Static Analysis Tools**: Use static analysis tools to scan the code for potential vulnerabilities, such as buffer overflows.
5. **Hardware Testing:** If the bug is hardware-related, try testing with different hardware configurations.
6. **Reproducible Test Case**: Attempt to create a reproducible test case that triggers the crash. This will make it much easier to debug the problem.
7. **Sequence File Debugging**: Investigate the sequence file associated with the driver or module. Sequence files are often used to provide runtime information about the driver.

**In Summary:**

This crash dump strongly suggests a bug in the kernel's networking stack, likely related to string manipulation within a driver or module and the use of `seq_printf` to generate kernel log output. The most probable cause is a buffer overflow or an incorrect string length calculation. Careful examination of the networking driver code and thorough debugging with a kernel debugger are the best approaches to pinpointing the root cause.
11.01.2014 05:03:00, evharten.

Результат теста: Ядро CCR выдало ошибку (Kernel panic) 6.8rc1 (обновлено: 11-01-2014)

Fri, 10 Jan 2014 13:44:00 -0500

Результат теста: Ядро CCR выдало ошибку (Kernel panic) 6.8rc1 (обновлено: 11-01-2014) RouterOS в форуме RouterOS.
Мы решили эту проблему, можете скачать v6.8rc1 заново.
10.01.2014 13:44:00, uldis.

Результат теста: Ядро CCR выдало ошибку (Kernel panic) 6.8rc1 (обновлено: 11-01-2014)

Thu, 09 Jan 2014 05:36:00 -0500

Результат теста: Ядро CCR выдало ошибку (Kernel panic) 6.8rc1 (обновлено: 11-01-2014) RouterOS в форуме RouterOS.
Обновлено до 6.8rc1 _ 2014-01-08 14:00:28: Pid: 277, comm: net, CPU: 13
r0 : 0xfffffff710791240 r1 : 0xfffffff71079123f r2 : 0xfffffff710791240
r3 : 0x0000000000000000 r4 : 0xffffffffffffffff r5 : 0xffffffffffffffff
r6 : 0xffffffffffffffff r7 : 0x0000000000000000 r8 : 0x0000000000000000
r9 : 0x0000000000000000 r10: 0xfffffff710791240 r11: 0xfffffff710791240
r12: 0x0000000000000000 r13: 0x0000000000000000 r14: 0x0000000000000000
r15: 0x0000000000000050 r16: 0x000000000000000a r17: 0x0000000000000000
r18: 0x0000000000000000 r19: 0x0000000000000000 r20: 0xfffffe40fdd4faf0
r21: 0xfffffe40fdd4faa0 r22: 0xfffffe40fdd4faf8 r23: 0xfffffe40fdd4faa8
r24: 0xfffffe40fdd4fb00 r25: 0xfffffe40fdd4fab0 r26: 0xfffffe40fdd4fa98
r27: 0xfffffe40fdd4fab8 r28: 0xfffffe40fdd4fa90 r29: 0xfffffe40fdd4fac0
r30: 0xfffffe00f9f804ad r31: 0xfffffff710791240 r32: 0xffffffffffffffff
r33: 0xfffffe00f9f90000 r34: 0xfffffe40fdd4fa10 r35: 0xfffffe00f9441011
r36: 0xfffffe00fdab3820 r37: 0xfffffff70016a020 r38: 0xfffffe40fdd4f9f0
r39: 0xfffffe40fdd4fa10 r40: 0xfffffe40fdd4fc48 r41: 0xfffffe40fdd4fc80
r42: 0xfffffe40fdd4fc50 r43: 0xfffffe40fdd4f9c8 r44: 0x0000000000000000
r45: 0xfffffe40ff011000 r46: 0xfffffff500c24d18 r47: 0xfffffff7001df800
r48: 0xfffffe40fdd4fa08 r49: 0xfffffe00fc3025c0 r50: 0xfffffe00006e2440
r51: 0xfffffff500c24d18 r52: 0xfffffe40fdd4fcc0 tp : 0x000001f4ffb90000
sp : 0xfffffe40fdd4fa88 lr : 0xfffffff7002d8eb0
pc : 0xfffffff7002d68d8 ex1: 1 faultnum: 18
Dump инструкций:
28060800d107f00a 283bf945d01c128c 1400018151483000 286a6ee0514402c0
<5c66400000a0128a> 17bff99e51483000 27fffffed1483000 283bf8055107f00b

Начало дампа стека для tid 277, pid 277 (net) на cpu 13 в цикле 24090235803
frame 0: 0xfffffff7002d68d8 strnlen+0x20/0x38 (sp 0xfffffe40fdd4fa88)
frame 1: 0xfffffff7002d8eb0 string.isra.2+0x78/0x180 (sp 0xfffffe40fdd4fa88)
frame 2: 0xfffffff7002da210 vsnprintf+0x3b0/0x7d0 (sp 0xfffffe40fdd4fac0)
frame 3: 0xfffffff70018f9e8 seq_printf+0xb8/0x138 (sp 0xfffffe40fdd4fb90)
frame 4: 0xfffffff7000cbc38 show_interrupts+0x488/0x538 (sp 0xfffffe40fdd4fc08)
frame 5: 0xfffffff7001900f0 seq_read+0x4e0/0x7a0 (sp 0xfffffe40fdd4fa10)
frame 6: 0xfffffff70018b128 openat+0x128/0x2a0 (sp 0xfffffe40fdd4fa10)
frame 7: 0xfffffff70018ae90 __libc_read+0xe0/0x260 (sp 0xfffffe40fdd4fa10)
frame 8: 0xfffffff70018a978 read+0x78/0x90 (sp 0xfffffe40fdd4fa10)
frame 9: 0xfffffff700189e80 kill+0x680/0x920 (sp 0xfffffe40fdd4fa10)
frame 10: 0x77c3ea40 0x77c3ea40 (sp 0x7ff5f440)
frame 11: 0x77bb5140 0x77bb5140 (sp 0x7ff5f440)
frame 12: 0x77bb6fb8 0x77bb6fb8 (sp 0x7ff5f4a0)
frame 13: 0x77bb6cb8 0x77bb6cb8 (sp 0x7ff5f4b8)
frame 14: 0x77b9f7e0 0x77b9f7e0 (sp 0x7ff5f4e0)
frame 15: 0x77b9d508 0x77b9d508 (sp 0x7ff5f558)
frame 16: 0x83e70 0x83e70 (sp 0x7ff5f5a0)
frame 17: 0x102660 0x102660 (sp 0x7ff5fa10)
frame 18: 0x102fe8 0x102fe8 (sp 0x7ff5fac0)
frame 19: 0x103050 0x103050 (sp 0x7ff5fad8)
frame 20: 0xcd9b8 0xcd9b8 (sp 0x7ff5faf0)
frame 21: 0x1b890 0x1b890 (sp 0x7ff5fc20)
frame 22: 0x77b2a830 0x77b2a830 (sp 0x7ff5fcb0)
Конец дампа стека
---[ end trace e56dcc5de9db7e27 ]---
09.01.2014 05:36:00, evharten.

Результат теста: Ядро CCR выдало ошибку (Kernel panic) 6.8rc1 (обновлено: 11-01-2014)

Fri, 03 Jan 2014 05:34:00 -0500

Результат теста: Ядро CCR выдало ошибку (Kernel panic) 6.8rc1 (обновлено: 11-01-2014) RouterOS в форуме RouterOS.
RB: CCR1016-12G (8GB ram) Pid: 278, comm: net, CPU: 8
r0 : 0xfffffff710791240 r1 : 0xfffffff71079123f r2 : 0xfffffff710791240
r3 : 0x0000000000000000 r4 : 0xffffffffffffffff r5 : 0xffffffffffffffff
r6 : 0xffffffffffffffff r7 : 0x0000000000000000 r8 : 0x0000000000000000
r9 : 0x0000000000000000 r10: 0xfffffff710791240 r11: 0xfffffff710791240
r12: 0x0000000000000000 r13: 0x0000000000000000 r14: 0x0000000000000000
r15: 0x0000000000000050 r16: 0x000000000000000a r17: 0x0000000000000000
r18: 0x0000000000000000 r19: 0x0000000000000000 r20: 0xfffffe00fbdffaf0
r21: 0xfffffe00fbdffaa0 r22: 0xfffffe00fbdffaf8 r23: 0xfffffe00fbdffaa8
r24: 0xfffffe00fbdffb00 r25: 0xfffffe00fbdffab0 r26: 0xfffffe00fbdffa98
r27: 0xfffffe00fbdffab8 r28: 0xfffffe00fbdffa90 r29: 0xfffffe00fbdffac0
r30: 0xfffffe00f98804ad r31: 0xfffffff710791240 r32: 0xffffffffffffffff
r33: 0xfffffe00f9890000 r34: 0xfffffe00fbdffa10 r35: 0xfffffe00f9344011
r36: 0xfffffe40ff903820 r37: 0xfffffff70016a020 r38: 0xfffffe00fbdff9f0
r39: 0xfffffe00fbdffa10 r40: 0xfffffe00fbdffa18 r41: 0xfffffe00006e2540
r42: 0x0000000000000000 r43: 0xfffffe00fbdff9c8 r44: 0x0000000000000000
r45: 0xfffffe40ff011000 r46: 0xfffffff500c24d18 r47: 0xfffffff7001df800
r48: 0xfffffe00fbdffa08 r49: 0xfffffe00fc251eb8 r50: 0xfffffe00006e2440
r51: 0xfffffff500c24d18 r52: 0xfffffe00fbdffcc0 tp : 0x000001f4ffb40000
sp : 0xfffffe00fbdffa88 lr : 0xfffffff7002d8eb0
pc : 0xfffffff7002d68d8 ex1: 1 faultnum: 18
Instruction dump:
28060800d107f00a 283bf945d01c128c 1400018151483000 286a6ee0514402c0
<5c66400000a0128a> 17bff99e51483000 27fffffed1483000 283bf8055107f00b

Starting stack dump of tid 278, pid 278 (net) on cpu 8 at cycle 24922148319
frame 0: 0xfffffff7002d68d8 strnlen+0x20/0x38 (sp 0xfffffe00fbdffa88)
frame 1: 0xfffffff7002d8eb0 string.isra.2+0x78/0x180 (sp 0xfffffe00fbdffa88)
frame 2: 0xfffffff7002da210 vsnprintf+0x3b0/0x7d0 (sp 0xfffffe00fbdffac0)
frame 3: 0xfffffff70018f9e8 seq_printf+0xb8/0x138 (sp 0xfffffe00fbdffb90)
frame 4: 0xfffffff7000cfe20 show_stacklogs+0x0/0x0 (sp 0xfffffe00fbdffce0)
frame 5: 0xfffffff70017d460 kthread_park+0x0/0x0 (sp 0xfffffe00fbdffd50)
frame 6: 0xfffffff70008c478 __kthread_create+0x168/0x480 (sp 0xfffffe00fbdffd50)
frame 7: 0xfffffff700089e80 kthread_create_on_cpu+0x180/0x340 (sp 0xfffffe00fbdffd50)
frame 8: 0xfffffff700089a60 kthread_create+0x0/0x0 (sp 0xfffffe00fbdffd50)
frame 8: 0xfffffff700089a60 kthread_create+0x0/0x0 (sp 0xfffffe00fbdffd50)
frame 9: 0xfffffff700089a60 kthread_create+0x0/0x0 (sp 0xfffffe00fbdffd50)
frame 10: 0xfffffff700089a60 kthread_create+0x0/0x0 (sp 0xfffffe00fbdffd50)
frame 11: 0xfffffff700089a60 kthread_create+0x0/0x0 (sp 0xfffffe00fbdffd50)
frame 12: 0xfffffff700089a60 kthread_create+0x0/0x0 (sp 0xfffffe00fbdffd50)
frame 13: 0xfffffff700089a60 kthread_create+0x0/0x0 (sp 0xfffffe00fbdffd50)
frame 14: 0xfffffff700089a60 kthread_create+0x0/0x0 (sp 0xfffffe00fbdffd50)
frame 15: 0xfffffff700089a60 kthread_create+0x0/0x0 (sp 0xfffffe00fbdffd50)
frame 16: 0x922c8 0x922c8 (sp 0x7fc5f558)
frame 17: 0xbdde0 0xbdde0 (sp 0x7fc5fa10)
frame 18: 0xbe768 0xbe768 (sp 0x7fc5fac0)
frame 19: 0xbe7d0 0xbe7d0 (sp 0x7fc5fad8)
frame 20: 0xd37a0 0xd37a0 (sp 0x7fc5faf0)
frame 21: 0x1b890 0x1b890 (sp 0x7fc5fc20)
frame 22: 0x77a7a830 0x77a7a830 (sp 0x7fc5fcb0)
Stack dump complete
---[ end trace 35e00ef426c7e435 ]---
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
tilegx-ohci tilegx-ohci.0: Tile-Gx OHCI
tilegx-ohci tilegx-ohci.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected System is in a reboot loop after this.
03.01.2014 05:34:00, evharten.