Permanent brightness issue after just reading `/dev/mem`

For no reason, I've tried to read /dev/mem on a Linux x86_64 laptop using

cat /dev/mem > /dev/null

Under the root user, and my kernel was built without any restrictions on /dev/mem. I knew that /dev/mem's driver provides access to physical memory. And physical memory addresses can be mapped to different hardware and peripherals, so it may be unsafe to write to them. But I thought that read is fine.
But something went wrong, I saw few traces dumped to TTY (VT's), and the last line was saying note: cat[THE_PID] exited with irqs disabled.
After one or two seconds, it rebooted automatically, I don't know why (there was likely no kernel panic, and anyway I had kernel.panic=0 in sysctl, so it shouldn't have rebooted by itself).
I firstly ofc thought it was absolutely fine (just a crash, as always after "experiments"). **But then it turned out that a permanent issue was introduced by these actions**.
On the next boot, after loading of i915 driver for the iGPU, screen brightness automatically went to zero. I had to manually increase /sys/class/backlight/intel_backlight/brightness in the sysctl, for the brightness to be restored. Now, **on every boot, when the iGPU driver gets loaded, brightness goes zero, requiring an intervention**.
I have tried:
- Resetting EFI/BIOS - Deleting all efivars and booting the firmware cleanly - Zeroing out /dev/nvram and booting the firmware cleanly - Booting from a different disk (where there was a different Linux installation, different kernel version). None of these helped. Everything else works, but the brightness issue remains. I have to blindly set the brightness every boot, or using a script to run on boot, after modprobe i915 takes place. It's fine then, but I really want to know why that happened. Not exactly to fix it, but just because I'm really curious about how such thing could happen.
As I suppose, there was some physical address in /dev/mem which was mapped to the iGPU's non-volatile memory with some brightness preferences? But I have only done a read, not write.
Unfortunately I don't have the traces and regs which were dumped to TTY when cat died (because the machine rebooted nearly immediately, nothing was saved anywhere).
Thanks for any insights!