Based on the technical write-ups published this week by Imperva, Upwind and the Node.js project, plus CISA’s Oct 27 KEV alert, here is the architectural impact.

The bug is in DecodeBlockTypeAndLength(). It returned a boolean, so “malformed” and “need more input” were indistinguishable, and the fast path ignored the result. Exposure depends on whether attacker-controlled bytes reach the decoder. That means request bodies with Content-Encoding: br, responses your service fetches (webhooks, link previews), or direct decompression of uploads. A WAF only covers the first.

Imperva has code execution on stock Node.js 24.22.0 arm64, not on every attempt. Others argue DoS only. CISA hasn’t said which outcome it saw.

For people running Envoy, Python requests/httpx or Node fetch() in prod: how are you inventorying bundled Brotli copies? Version strings don’t help, since one analysis says Node 24.22.0 and the fixed 24.22.1 both report Brotli 1.2.0.

Background on the same failure class: https://www.techgines.com/post/lmcache-vulnerability-cve-2026-105192

I inherited about a dozen small Postgres instances on VPSes between 4 and 16GB. The settings are all over the place: one has shared_buffers at 50% and swap off, which explains the OOM kills.

Current plan is shared_buffers at 25%, effective_cache_size at 70%, work_mem tuned per box, and 2GB of swap with swappiness at 10.

Does that hold up on budget VPSes where disk IO is slower than you'd like? Has anyone gone the other way and kept swapping off entirely? What do you change when the storage is network attached rather than local NVMe?

Back in January 2025 I shared a small script here that printed a table of MySQL status counters. I run it on most servers I look after, and over the past few weeks it grew into a full rewrite.

What it does now:

- Live dashboard with per-second rates measured between refreshes (not just totals since boot), sparklines, and usage bars against limits like `max_connections` and `table_open_cache`

- ✓/⚠/✗ marks and an alerts box that names the setting to look at

- `h` health checks with suggested settings, `p` process list with kill and recent-query history, `t` top queries from `performance_schema` statement digests (this catches the millisecond queries `SHOW PROCESSLIST` never shows)

- Fits any terminal size, and `--once` prints a snapshot for ssh or cron

- Pressing "r" also shows the original raw version.

It's one Bash file. It needs only awk (gawk, mawk or busybox) and the MySQL client tools. It only reads status, variables, the process list and `performance_schema`, so it's safe on production (the only write is an optional kill, which asks first). Works with MySQL 5.7/8.0 and MariaDB.

GitHub: https://github.com/haydenjames/mysqlmonitor-script

The linked blog post explains each metric and what to do about it.

New video: cgroup v2 cpuset and memory limits 🐧

Why does one container get OOM killed while the rest of the machine is fine?

In this part of my cgroup v2 series I cover:

🔹 cpuset: pinning workloads to CPUs and NUMA nodes

🔹 memory.high vs memory.max: a soft ceiling that throttles and reclaims, against a hard ceiling that ends in an OOM kill

🔹 The kernel's allocation flow, step by step

🔹 A hands-on "memory hog" lab with stress-ng

The one-line summary is easy. The details (who does the reclaim, what you see in the counters) are where performance engineering gets interesting.

#Linux #cgroups #PerformanceEngineering #SRE #DevOps #Kubernetes

[ Removed by Reddit on account of violating the content policy. ]

I’ve been working on cetrafs, a shared-disk clustered filesystem for Linux aimed at the VMFS use case: multiple hosts accessing the same block storage concurrently.

The core is working and I’m now looking to expand the test base — different storage backends, kernels, workloads and failure scenarios.

If this sounds relevant to your setup and you’re willing to try it, I’d really appreciate feedback, bug reports, and attempts to break it.

hXXps://cetrafs.com/

Quick summary for anyone who missed it. ZDI copied public lists on six reports last week. ZDI-CAN-33367 is a gap in the Dirty Frag fix: skb_zerocopy() doesn't carry the shared-frag marker across, so ESP decrypts in place over page-cache pages. TuxCare reproduced root on AlmaLinux 8 to 10, Debian 12/13 and Ubuntu 24.04/26.04. The PoC needs unprivileged user namespaces plus modules like nlmon and act_pedit. A kernel that only has the CVE-2026-90049 fix is still exposed. AlmaLinux has kernels in testing (AlmaLinux), and Sysdig has a good breakdown of mitigations, including seccomp RuntimeDefault for Kubernetes and a note that Ubuntu's AppArmor userns restriction was bypassed (Sysdig). For anyone who has set user.max_user_namespaces=0 fleet-wide: what broke? Rootless containers, browsers, CI?

What resources would you recommend to me for delving deeper into Linux operations while maintaining the fundamentals?
By that I mean I’ve been using Linux for a few years now - Ubuntu, Fedora, Ubuntu Server and recently playing with Omarchy. So I’m kind of comfortable with basic commands, navigating a file system, finding reading moving files etc. I’m not scared of a terminal 😀 but I find I still go to Google search or AI for more intermediate or advanced commands and I’d like to have a better wholistic understanding and how to administer linux system properly and troubleshoot better.
A focus of mine is network operations.
I saw the CompTia Linux+ but it seems to get some mixed reviews, is Linux System Administration Essentials (LFS207) worth the cost?
I bounce around between various YouTube videos but am chasing something more concise and structured
Any suggestions welcomed!
Cheers

I was helping our intern set up an internal wiki on a serverspace vm and explaining why we should deny everything except the ports we actually use. Very calm and professional. I enabled ufw, checked that the site still worked and said something like - see, nothing complicated. Then I closed my SSH session.

Our ssh service was running on a custom port. Guess which port I had forgotten to allow. I tried reconnecting three times, apparently hoping the firewall would reconsider. The intern just sat there watching me become less professional by the second.

Luckily, I could still open the web console from serverspace control panel. I added the missing rule and got back in within a few minutes. The only thing I successfully protected that afternoon was the server from its own administrator.

I run a small Linux learning site and made a roadmap: 13 stages in 3 phases, from shell basics and permissions to boot, services, networking, storage and security. Each stage lists the skills and a small project to prove you can do it.

The roadmap is free. Most linked tutorials are free too. It's also available in Dutch, German, French, Spanish and Portuguese.

I like to get feedback from experienced sysadmins: what's missing, is it in the right order, what would you cut?

Based on GitLab's own critical patch release notes (Oct 21) and Rapid7's analysis of the sibling Oct 12 bug, here is the operational picture as I read it.

What GitLab states: an integer overflow when compiling a crafted regular expression can, under certain conditions, let an unauthenticated user run arbitrary code on a self-managed server. CVSS 10.0. Fixed in 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. No workaround is listed.

Why it reaches back to 7.0: the compiler is Onigmo, Ruby's regex engine, which GitLab bundles. The changelog shows GitLab patching its own Ruby (a repeat ID overflow patch for 3.3, 3.4 and 4.0 on the newer branches).

Why your Oct 12 upgrade doesn't count: CVE-2026-97229 was fixed in 19.2.8, 19.3.5 and 19.4.2. Those are now one patch behind. The Hacker News counts this as the fourth code-execution bug in this engine from one reporter in a month.

What is not public: the conditions. GitLab's two detections, "Onigmo native worker crash" and "Org mode render error burst," suggest Org mode rendering is involved. One secondary report names a specific org-ruby path; I couldn't confirm it twice. Rapid7's repro on the Oct 12 bug needed a way to plant a malicious CI config, which open self-registration removes. Whether that carries over here is unknown.

As of Oct 22 GitLab reported no exploitation and CISA KEV didn't list it. I haven't re-checked since.

Upgrade note: 19.4.3 and 19.3.6 run migrations, so single-node installs take downtime.

Question: For those running single-node Omnibus with open self-registration or public projects, how are you handling this one: emergency maintenance window, a replica you can cut over to, or locking down registration first and patching on the normal cycle?

Background: https://www.techgines.com/post/gitlab-ai-gateway-vulnerability-cve-2026-90970 (earlier GitLab sandbox-escape write-up, for context). Full breakdown of this one: https://www.techgines.com/post/gitlab-vulnerability-cve-2026-110264

Hi guys, I am looking for any online opportunity to get an internship in Linux administration, I have 3+ years experience as self-employed, studying, practicing labs, documenting, and building projects.

I am so obsessed with Linux and managing this system and the hardware consuming, tracking each task and process to keep everything under control in front of my eyes..

If you know where I can find and get those internships opportunities since I need to add experience to get a full job for this position ..

Thank you so much

I don't know if it's acceptable to share github account link though :")

Hello,

I have a raspberry PI 4 with Debian Trixie and all the latest package versions.

Sometimes, I use it with a cable attached to another computer (thus no DHCP server). This works, I can ssh to it using mDNS and IPv6 with no issue.

But, from time to time, I got completely disconnected. What I've found in the journal is that after some DHCPv4 retries, it disabled the interface:

Oct 23 19:26:12 PIctorinox NetworkManager[676]: <warn> [1792794372.0700] device (eth0): Activation: failed for connection 'netplan-eth0'
Oct 23 19:26:12 PIctorinox NetworkManager[676]: <info> [1792794372.0709] device (eth0): state change: failed -> disconnected (reason 'none', managed-type: 'full')
Oct 23 19:26:12 PIctorinox NetworkManager[676]: <info> [1792794372.0851] dhcp4 (eth0): canceled DHCP transaction
Oct 23 19:26:12 PIctorinox NetworkManager[676]: <info> [1792794372.0852] dhcp4 (eth0): activation: beginning transaction (timeout in 10 seconds)
Oct 23 19:26:12 PIctorinox NetworkManager[676]: <info> [1792794372.0853] dhcp4 (eth0): state changed no lease
Oct 23 19:31:11 PIctorinox NetworkManager[676]: <info> [1792794671.8864] policy: auto-activating connection 'netplan-eth0' (75a1216a-9d1a-30cd-8aca-ace5526ec021)
Oct 23 19:31:11 PIctorinox NetworkManager[676]: <info> [1792794671.8886] device (eth0): Activation: starting connection 'netplan-eth0' (75a1216a-9d1a-30cd-8aca-ace5526ec021)
Oct 23 19:31:11 PIctorinox NetworkManager[676]: <info> [1792794671.8891] device (eth0): state change: disconnected -> prepare (reason 'none', managed-type: 'full')
Oct 23 19:31:11 PIctorinox NetworkManager[676]: <info> [1792794671.8904] device (eth0): state change: prepare -> config (reason 'none', managed-type: 'full')
Oct 23 19:31:11 PIctorinox NetworkManager[676]: <info> [1792794671.8926] device (eth0): state change: config -> ip-config (reason 'none', managed-type: 'full')
Oct 23 19:31:11 PIctorinox NetworkManager[676]: <info> [1792794671.8945] dhcp4 (eth0): activation: beginning transaction (timeout in 10 seconds)

At 19:31, I regained connectivity to it.

The relevant (at least the one I think) settings for this connection are

ipv4.method: auto
ipv4.may-fail: yes
ipv4.link-local: 3 (enabled)
ipv6.method: auto
ipv6.may-fail: yes

Any hints? This is driving me mad.

Thanks,
Max