complete kernel hung on starting GUI app: kernel: v3d fec00000.v3d: [drm:v3d_reset [v3d]] *ERROR* V3D_ERR_STAT: 0x00001000

[zxmak]

Describe the bug

I recently encountered an unexpected crash of the Octave GUI, which I documented in this issue. After some investigation, I found that the problem was caused by the contents of the file ~/.local/share/octave/history which should be displayed on command history sub-window. In that case, simply deleting the file resolved the issue. However, I wanted to understand what specifically in the file caused the crash, so I began inspecting its contents.

It turns out the problem was triggered by a very long line - approximately 28'000 characters, representing an array initialization. I then tried reducing the line length to determine the threshold at which the issue occurs. I found that Octave GUI crashes somewhere between 4'000 and 5'000 characters.

More critically, while testing within that range, I encountered an even more severe issue: placing a history file with a line of a certain length causes a complete system hang, requiring a hard reboot.

The kernel completely hang, GUI stops to respond and the system didn't respond even on network connections. After reboot you can find 4 log records with error before kernel hang:

journalctl log:

May 27 11:59:10 rzx kernel: v3d fec00000.v3d: [drm:v3d_reset [v3d]] *ERROR* Resetting GPU for hang.
May 27 11:59:10 rzx kernel: v3d fec00000.v3d: [drm:v3d_reset [v3d]] *ERROR* V3D_ERR_STAT: 0x00001000
May 27 11:59:11 rzx kernel: v3d fec00000.v3d: [drm:v3d_reset [v3d]] *ERROR* Resetting GPU for hang.
May 27 11:59:11 rzx kernel: v3d fec00000.v3d: [drm:v3d_reset [v3d]] *ERROR* V3D_ERR_STAT: 0x00001000

I can stable reproduce this issue simply by placing the attached history file to ~/.local/share/octave/ folder and launching Octave GUI.

I suspect there is some issue with V3D video driver and possibly Qt5 libraries, probably some kind of security issue with buffer overflow.

The issue has been reproduced on Raspberry Pi OS Bookworm aarch64 (with all latest APT updates), running under the Wayland display server with the Labwc compositor. Based on testing for mentioned issue with octave crash, the same behavior is also observed when using the Wayfire compositor under Wayland. When running under X11, the behavior differs slightly but still results in problematic behavior.

Steps to reproduce the issyue

1. Build and install octave

2. unzip history file from attached ZIP archive to the folder ~/.local/share/octave/:

history.zip

3. Launch Octave GUI (from start menu, or just with terminal octave --gui)

Expected result: The Linux kernel continue running with no issue

Actual result: The Linux kernel completely hang and stops to work.

Device (s)

Raspberry Pi 4 Mod. B

System

$ cat /etc/rpi-issue
Raspberry Pi reference 2023-09-22
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 40f37458ae7cadea1aec913ae10b5e7008ebce0a, stage4

$ vcgencmd version
Apr 30 2025 13:33:39
Copyright (c) 2012 Broadcom
version 5560078dcc8591a00f57b9068d13e5544aeef3aa (clean) (release) (start)

$ uname -a
Linux rzx 6.12.25+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.25-1+rpt1 (2025-04-30) aarch64 GNU/Linux

Logs

May 27 11:59:10 rzx kernel: v3d fec00000.v3d: [drm:v3d_reset [v3d]] *ERROR* Resetting GPU for hang.
May 27 11:59:10 rzx kernel: v3d fec00000.v3d: [drm:v3d_reset [v3d]] *ERROR* V3D_ERR_STAT: 0x00001000
May 27 11:59:11 rzx kernel: v3d fec00000.v3d: [drm:v3d_reset [v3d]] *ERROR* Resetting GPU for hang.
May 27 11:59:11 rzx kernel: v3d fec00000.v3d: [drm:v3d_reset [v3d]] *ERROR* V3D_ERR_STAT: 0x00001000

Additional context

I can stable reproduce this issue on Octave 10.1.0 build from official sources. But since original issue also was reproduced on Octave 9.4.0, I think it should be reproducible on 9.4.0 and older versions of octave either, but I didn't tested it with older versions.

you can build and install octave in the following way:

# prerequisites
sudo apt-get install gcc g++ gfortran make libopenblas-dev liblapack-dev libpcre3-dev libarpack2-dev libcurl4-gnutls-dev epstool libfftw3-dev fig2dev libfltk1.3-dev libfontconfig1-dev libfreetype6-dev libgl2ps-dev libglpk-dev libreadline-dev gnuplot libgraphicsmagick++1-dev libhdf5-dev libsndfile1-dev llvm-dev texinfo libgl1-mesa-dev libosmesa6-dev pstoedit portaudio19-dev libjack-jackd2-dev libqhull-dev libqrupdate-dev libqt5core5a qtbase5-dev qttools5-dev qttools5-dev-tools libqscintilla2-qt5-dev libsuitesparse-dev texlive texlive-latex-extra libxft-dev zlib1g-dev autoconf automake bison flex gperf gzip icoutils librsvg2-bin libtool perl rsync tar libsundials-dev git rapidjson-dev
sudo apt-get install openjdk-17-jdk

# download source, build and install
wget https://ftp.gnu.org/gnu/octave/octave-10.1.0.tar.gz
tar -xzf octave-10.1.0.tar.gz 
cd octave-10.1.0

mkdir .build && cd .build && ./../configure
make -j2
sudo make install

I may miss some prerequisite library, so if something is missing just add.

[pelwell]

Hmm - it's working for me. Octave crashes in the blink of an eye, but there isn't a single kernel message.

[popcornmix]

Yeah - I got the same result.
Tested Octave from apt and custom built one.
Tested apt kernel (6.12.25), latest 6.12 and 6.15.
Tested on Pi4 and Pi5.

If the large history file is present Octave crashes on launch. Without the history file it loads okay.
No messages in dmesg, and system still usable.

[zxmak]

Hmmm...

when history contains line more than 5000 letters - yes, it just crash the Octave, but the kernel still working ok.

But with attached history file it leads to stable kernel crash on my machine. Hang to be more clear - all processes are stopped and kernel doesn't respond, the system don't respond even on network pings.

And stable 4 log messages in the log before hang:

May 27 11:59:10 rzx kernel: v3d fec00000.v3d: [drm:v3d_reset [v3d]] *ERROR* Resetting GPU for hang.
May 27 11:59:10 rzx kernel: v3d fec00000.v3d: [drm:v3d_reset [v3d]] *ERROR* V3D_ERR_STAT: 0x00001000
May 27 11:59:11 rzx kernel: v3d fec00000.v3d: [drm:v3d_reset [v3d]] *ERROR* Resetting GPU for hang.
May 27 11:59:11 rzx kernel: v3d fec00000.v3d: [drm:v3d_reset [v3d]] *ERROR* V3D_ERR_STAT: 0x00001000

I tried it several times and it leads to stable kernel crash on my machine

Just tried it again with history unzipped from downloaded history.zip and it again lead to stable kernel crash, but now I don't see any message in the log - the last message before I started Octave.

I am using zram as the swap backend, with traditional disk-based swap disabled. So I decided to investigate whether swap usage might be a contributing factor for kernel hangs during octave startup. To test this, I temporarily disabled swap using sudo swapoff -a.

Surprisingly, with swap disabled, Octave launched successfully on the first attempt - including loading the history file unzipped from attached archive, with only a brief startup delay and no crash! However, on the second launch octave --gui, the system experienced the same kernel hang.

This behavior is consistent after a reboot: with swap disabled, Octave launches normally on the first attempt, but a second launch causes the system to hang. In contrast, when zram swap is enabled, the kernel hang occurs immediately on the first launch of Octave.

And I don't see log records, so it appears that log records appears in the log unstable.

Also tested with different compositor:
X11 - Surprisingly octave starts ok with history file unzipped from attached archive
Wayfire - kernel hang on first Octave start even before window appears on the screen (tried twice with the same result).
Labwc - kernel hangs on first Octave start after window is rendered on the screen.

Also tried to disconnect usb devices and Ethernet, but it don't affect issue - still kernel hang happes.

Also tested with old kernel 6.6.74 by default it leads to just app crash, but I found that with ini file from machine where kernel hangs, it also hangs. So it seems that it also depends on some gui ini setting, probably sub-window size/position, need to investigate.

[zxmak]

if you cannot reproduce kernel hang behavior, try to remove ini files:

rm ~/.config/octave/octave-gui.ini ~/.config/octave/octave-gui.ini.lock

unzip attached history.zip (see issue description) to ~/.local/share/octave/

Then start Octave GUI. It will open welcome window, just press Next and finish. It will open the main window, then you notice some high mouse lags and then after 2-3 seconds it leads to a full Linux kernel hang. The kernel just doesn't respond on any input or network events, all background processes are stopped and sound playback is also stopped.

Also try to install zram swap:

sudo apt install zram-tools

and configure SIZE=1536 with sudo nano /etc/default/zramswap.

And disable disk swap: swapoff /var/swap

I tested it with Octave 10.1.0 and display resolution 1280x1024.

If it matters, I also did this to install octave packages that I use:

sudo chown -R $(whoami) /usr/local/share/octave
octave --eval "pkg rebuild -global"
octave --eval "pkg install -forge audio control signal"

the permission required because Octave 10.1.0 cannot write to /usr/local/share/octave with no sudo permission, it is required to install octave packages.

[pelwell]

With /var/swap disabled and zram swap enabled, and using the same history file, I still see no kernel crashes or misbehaviour - it's all fine.

Why don't you start from a clean installation and follow your own steps to see if you can reproduce the issue? You can work backwards on your current image, disabling zram swap and re-enabling /var/swap, until it stops killing the kernel.

Talking of ZRAM, how much RAM do you have on your PI 4?

[zxmak]

Why don't you start from a clean installation and follow your own steps to see if you can reproduce the issue?

I tested it on almost clean install on another sdcard with kernel 6.6.74 and can reproduce it either.

I will try clean install with latest kernel but it will take some time.

It’s quite unusual that I can consistently reproduce this issue on two separate SD card installations, while you’re unable to. There may be an additional package or configuration setting influencing this behavior.

Talking of ZRAM, how much RAM do you have on your PI 4?

4GB

[zxmak]

I performed a clean installation of the latest Raspberry Pi OS image using the default settings and confirmed that it results in just an Octave crash, as previously noted by @popcornmix. To further investigate, I reapplied my typical configuration and customizations incrementally, testing each step to identify the cause of the kernel crash.

Through this process, I determined that the issue is triggered by copying the Consolas font to the ~/.fonts directory. Once the font is present, launching Octave with a specific history file consistently causes a kernel crash. If the font file is removed, launching Octave results in a regular application crash only - the Linux kernel remains unaffected and continues to operate normally.

But since its not open source font, I'm not sure if its allowed to share it. As I read it is available for download and use with different products and packages, but as I understand not allowed to redistribute.

So, steps to reproduce with clean latest Raspberry Pi OS arrch64 install:

1. Build and install octave 10.1.0 (see original issue for details)

2. Copy Consolas font file to ~/.local/share/octave/ folder, the file md5sum is fe4a6c771135c7d60c684b564466e82a.

3. Unzip history file to ~/.local/share/octave/ (see archive in original issue steps-to-reproduce)

4. Remove octave ini file: rm ~/.config/octave/octave-gui.ini ~/.config/octave/octave-gui.ini.lock

5. Start octave --gui

I have omitted some additional settings that I believe are unrelated to the issue. However, if you're still unable to reproduce the problem, please let me know, and I will review those settings to determine if any of them might also contribute to the kernel crash.

At a glance it appears to be a GPU driver-related issue that occurs under specific conditions and results in a complete kernel crash. It appears that Octave uses Consolas font by default (if its present on the system) and for some unknown reason rendering it with Qt5 leads to Linux kernel crash. But since this font is displayed ok with other apps, it looks like some GPU-driver issue which is caused by some specific condition.

Interestingly, when the line length is under approximately 4000 characters, there are no issues when using the Consolas font - lines render correctly, the application remains stable, and there are no kernel crashes. However, once the line length exceeds around 4000 characters, a Linux kernel crash occurs. If the line length goes beyond approximately 5000 characters, the application crashes instead - similar to what happens when the default font is used (i.e., when Consolas is not available).

This suggests that the issue may be related to how text rendering behaves outside the visible clipping area. Probably within a certain range of line lengths, rendering with the Consolas font appears to trigger a critical failure in the GPU driver, resulting in a kernel crash. Font choice seems to influence the glyph width and overall rendered string size, and it appears that when the rendered line reaches a certain threshold, a GPU-driver fault occurs - leading either to a kernel crash or an application crash, depending on the specific size of the rendered text.

If my assumption is correct, it probably should also be possible to reproduce the kernel crash using the default font by carefully adjusting the line length in the history file to a value that triggers the same failure condition in Raspberry Pi GPU driver.

It raises the question of whether this GPU driver vulnerability could potentially be exploited for arbitrary code execution - for example, through text rendering in a web browser when displaying specially crafted content?

This issue appears to primarily affect applications built with Qt5, which somewhat limits the risk, as exploiting it would typically require the user to run a local application. However, it remains unclear whether browsers - particularly those that rely on similar rendering paths might also be affected?

[pelwell]

I downloaded a Consolas font, but the md5sum doesn't match. And the driver still doesn't crash.

[zxmak]

you need this file to reproduce kernel crash:

$ stat -c %s consola.ttf 
358256

$ md5sum consola.ttf 
fe4a6c771135c7d60c684b564466e82a  consola.ttf

$ sha256sum consola.ttf 
45c14a49e0ba2edc00b72afad9a930cad5c1b9a93323b239a8c308efc5a65e8e  consola.ttf

$ crc32 consola.ttf 
cf7d826f

FontViewer shows Version 5.22, 2008
It is present in Windows 7.

PS: Google shows that you can download it here: https://nomail.com.ua/catalog?page=8
yes, this is version that cause kernel crash. Search by md5sum, and check md5

[zxmak]

Is there any information available on why the Linux kernel crashes?
The font file that appears to trigger the kernel crash can be found here: https://nomail.com.ua/font-page/1157?name=Consolas