Security Advisory: CVE-2025-55649 - NULL Pointer Dereference in GPAC MP4Box ESD Mapping

Processing a crafted MP4 file with corrupted Elementary Stream Descriptor data can trigger a NULL pointer dereference in `gf_media_map_esd()`, causing a Denial of Service.

Summary:
The `gf_media_map_esd()` function in `media_tools/isom_tools.c` does not verify that `esd->URLString` is non-NULL before passing it to `strlen()`. When MP4Box processes a crafted MP4 file containing corrupted ESD data during fragmentation setup, `URLString` can be NULL and the process crashes while reading from address `0x000000000000`.

AddressSanitizer reports a `SEGV` in `strlen()`, with the GPAC call site at `media_tools/isom_tools.c:1359`.

CWE:
CWE-476 - NULL Pointer Dereference

Affected Component:
```
media_tools/isom_tools.c:1359
Function: gf_media_map_esd()
```

Affected Product:
MP4Box (GPAC Multimedia Open Source Project)

Affected Version:
MP4Box versions 2.4 and earlier are affected according to the prepared CVE/MITRE data. The issue was reproduced on a GPAC build at commit:
```
09e7063ed0a13b4cee9a180a56dcc21e9f9ade07
```

Attack Conditions:
An attacker supplies a crafted MP4 file containing corrupted ESD data. The issue can be reproduced locally with:
```
./MP4Box -frag 1500 11_poc.mp4
```
No elevated privileges are required. User interaction is required when the victim manually processes the malicious MP4 file, or an automated workflow invokes MP4Box on attacker-controlled media.

Impact:
The immediate observed impact is Denial of Service due to process termination. The crash is a NULL pointer dereference on the zero page; no evidence of arbitrary code execution was observed.

Fix / mitigation status:
The local CVE/MITRE data references GPAC fix commit:
```
10c16d54659b1b82dd49573dfeacfa9a5627a115
```
Users should update to a GPAC build containing this commit or later. The affected code should validate `esd`, `esd->URLString`, and related ESD fields before string operations.

References:
- Issue: https://github.com/gpac/gpac/issues/3183
- PoC: https://github.com/sigdevel/pocs/blob/main/res/gpac/MP4Box/11/11_poc.mp4
- Fix: https://github.com/gpac/gpac/commit/10c16d54659b1b82dd49573dfeacfa9a5627a115

Credit:
@sigdevel (Alexander A. Shvedov)

#fuzzing #infosec #security #aflplusplus #revers #cybersecurity #bugbounty #vulnerability #opensource #linux #cve #advisory #media #gpac

Security Advisory: CVE-2025-55648 - Heap Buffer Overflow in GPAC MP4Box Opus Packet Parser

Processing a crafted MP4 file containing corrupted Opus sample-size data with `MP4Box` can trigger a heap buffer overflow in `gf_opus_parse_packet_header()`, causing a crash and potential memory corruption impact.

Summary:
The `gf_opus_parse_packet_header()` function in `media_tools/av_parsers.c` does not sufficiently validate the input buffer length before parsing Opus packet headers. When MP4Box processes a crafted MP4 file with corrupted sample-size (`stsz`) data, the parser reads beyond the bounds of a heap-allocated sample buffer.
AddressSanitizer reports a `heap-buffer-overflow` at `media_tools/av_parsers.c:11297`, with a `READ of size 1` 1242 bytes past a 32-byte heap region allocated by `Media_GetSample()`.

CWE:
CWE-122 - Heap-based Buffer Overflow

Affected Component:
```
media_tools/av_parsers.c:11297
Function: gf_opus_parse_packet_header()
```

Affected Product:
MP4Box (GPAC Multimedia Open Source Project)

Affected Version:
MP4Box versions 2.4 and earlier are affected according to the prepared CVE/MITRE data. The issue was reproduced on a GPAC build at commit:
```
61bbfd2e89553373ba3449b8ec05b5f098d732a5
```

Attack Conditions:
An attacker supplies a crafted MP4 file containing corrupted Opus sample-size (`stsz`) data. The issue can be reproduced locally with:
```
./MP4Box 12_poc.mp4 -dxml
```
No elevated privileges are required. The CVE text describes the attack as network/context-dependent because attacker-controlled media may be processed by MP4Box in automated workflows; manual processing also triggers the issue.

Impact:
The immediate observed impact is Denial of Service due to process termination. Because the bug reads beyond a heap allocation, information disclosure may be possible. The local MITRE data also notes potential arbitrary code execution risk, though the observed ASAN trace is an out-of-bounds read.

Fix / mitigation status:
The local CVE/MITRE data references GPAC fix commit:
```
cea49f684dbc4d53ecd6c76a9623838802a68d88
```

Users should update to a GPAC build containing this commit or later. The affected Opus parser should validate sample buffer length and `stsz`-derived packet sizes before reading packet header fields.

References:
- Issue: https://github.com/gpac/gpac/issues/3190
- PoC: https://github.com/sigdevel/pocs/blob/main/res/gpac/MP4Box/12/12_poc.mp4
- Fix: https://github.com/gpac/gpac/commit/cea49f684dbc4d53ecd6c76a9623838802a68d88

Credit:
@sigdevel (Alexander A. Shvedov)

#fuzzing #infosec #security #aflplusplus #revers #cybersecurity #bugbounty #vulnerability #opensource #linux #cve #advisory #media #gpac

Security Advisory: CVE-2025-55647 - Integer Overflow in GPAC MP4Box PSSH Handling

Processing a crafted MP4 file with malformed Protection System Specific Header (PSSH) data can trigger an integer overflow and uncontrolled allocation in `mp4_mux_cenc_insert_pssh()`, causing Denial of Service through memory exhaustion.

Summary:
The `mp4_mux_cenc_insert_pssh()` function in `filters/mux_isom.c` does not sufficiently validate PSSH sizes before allocating memory. A crafted MP4 file can set PSSH-related fields such as `kid_count` or `dataSize` to very large values. This can overflow the buffer size calculation and cause MP4Box to attempt a very large allocation during DASH/mux processing.

AddressSanitizer reports an out-of-memory condition at `filters/mux_isom.c:4326`, where `realloc()` attempts to allocate `0xe40000100` bytes.

CWE:
CWE-190 - Integer Overflow or Wraparound

Affected Component:
```
filters/mux_isom.c:4326
Function: mp4_mux_cenc_insert_pssh()
```

Affected Product:
MP4Box (GPAC Multimedia Open Source Project)

Affected Version:
MP4Box versions 2.4 and earlier are affected according to the prepared CVE/MITRE data. The issue was reproduced on a GPAC build at commit:
```
e95f3064d846e4606276fff111e0f97df1576a04
```
Builds before the fix commit `2a1f638534cddf511a7ba06618bff9d587141792` should be considered affected if they contain the vulnerable PSSH allocation path.

Attack Conditions:
An attacker supplies a crafted MP4 file containing malformed PSSH/CENC metadata. The issue can be reproduced locally with:
```
./MP4Box -dash 10000 ./15_poc.mp4
```
No elevated privileges are required. User interaction is required when the victim manually processes the malicious MP4 file, or an automated media workflow invokes MP4Box on attacker-controlled input.

Impact:
The immediate observed impact is Denial of Service due to memory exhaustion and process termination. Because the root cause is an integer overflow in allocation-size calculation, memory corruption and potential arbitrary code execution cannot be ruled out.

Fix / mitigation status:
The issue was fixed in GPAC commit:
```
2a1f638534cddf511a7ba06618bff9d587141792
```

References:
- Issue: https://github.com/gpac/gpac/issues/3235
- PoC: https://github.com/sigdevel/pocs/blob/main/res/gpac/MP4Box/15/15_poc.mp4
- Fix: https://github.com/gpac/gpac/commit/2a1f638534cddf511a7ba06618bff9d587141792
- Related fix/reference: https://github.com/gpac/gpac/commit/3111995

Credit:
@sigdevel (Alexander A. Shvedov)

#fuzzing #infosec #security #afl #revers #cybersecurity #bugbounty #vulnerability #opensource #linux #cve #advisory #media #gpac

Security Advisory: CVE-2025-55644 - Use-After-Free in GPAC MP4Box

Processing a crafted MP4 file with invalid BIFS GlobalQuantizer commands causes gf_node_get_tag() to access a freed 192-byte QuantizationParameter node at scenegraph/base_scenegraph.c:1263, resulting in a heap use-after-free and crash.

Summary:
During MPEG-4 BIFS scene decoding, BM_ParseGlobalQuantizer() in bifs/memory_decoder.c first calls gf_node_unregister() at line 176 to release a QuantizationParameter node, freeing the 192-byte heap region. Without clearing the stale pointer, the function then calls gf_node_get_tag() on the same address at line 181, performing a READ of 8 bytes at offset 0 into the freed region. A crafted MP4 containing invalid GlobalQuantizer BIFS commands, corrupted ODF descriptors, and malformed box types (PEC1808, fre) reliably triggers this free-then-use sequence through the -svg dump path.

CWE:
CWE-416 - Use After Free

Affected Component:
```
scenegraph/base_scenegraph.c:1263
```

Affected Product:
MP4Box (GPAC Multimedia Open Source Project)

Affected Version:
MP4Box 2.4 and earlier; tested at commit f5b7cdc63a7f3269040778c5431a8f6c310bc9f3

Attack Conditions:
An attacker supplies a locally accessible crafted MP4 file embedding invalid BIFS scene data. The victim runs MP4Box -svg on the file to trigger BIFS scene parsing. No elevated privileges are required.

Impact:
The use-after-free causes a fatal crash (Denial of Service). Use-after-free vulnerabilities can allow attackers to control freed heap memory contents and potentially redirect execution flow; code execution cannot be excluded.

Fix / mitigation status:
The issue was fixed in GPAC commit:
```
63eccc33d4a2b731ebb31581ff5673a2c0b13ad4
```
Users should update to a GPAC build containing this commit or later.

References:
- Issue: https://github.com/gpac/gpac/issues/3246
- PoC: https://github.com/sigdevel/pocs/blob/main/res/gpac/MP4Box/20/20_poc.mp4
- Fix: https://github.com/gpac/gpac/commit/63eccc33d4a2b731ebb31581ff5673a2c0b13ad4

Credit:
@sigdevel (Alexander A. Shvedov)

#fuzzing #infosec #security #aflplusplus #revers #cybersecurity #bugbounty #vulnerability #opensource #linux #cve #advisory #media #gpac

Security Advisory: CVE-2025-55645 - Heap Buffer Overflow in GPAC MP4Box PSSH Copy

Processing a crafted MP4 file with malformed PSSH data can trigger a heap buffer overflow in `gf_cenc_set_pssh()`, causing a crash and potential memory disclosure or memory corruption impact.

Summary:
The `gf_cenc_set_pssh()` function in `isomedia/drm_sample.c` does not sufficiently validate the size of PSSH data before copying it into a heap buffer. A crafted MP4 file can declare an oversized PSSH payload, causing MP4Box to copy a very large amount of data from a 512-byte heap allocation during DASH/CENC processing.

CWE:
CWE-120 - Buffer Copy without Checking Size of Input

Affected Component:
```
isomedia/drm_sample.c:982
Function: gf_cenc_set_pssh()
```

Affected Product:
MP4Box (GPAC Multimedia Open Source Project)

Affected Version:
MP4Box versions 2.4 and earlier are affected according to the prepared CVE/MITRE data. The local MITRE workbook also lists `2.5-DEV-rev228-g11067ea92-master` as affected. The issue was reproduced on a GPAC build at commit:

```
e95f3064d846e4606276fff111e0f97df1576a04
```

Builds before the fix commit `df0c81722847238659a6beb0feab2c1ecd05c020` should be considered affected if they contain the vulnerable PSSH copy path.

Attack Conditions:
An attacker supplies a crafted MP4 file containing malformed PSSH/CENC metadata with an oversized declared payload. The issue can be reproduced locally with:

```
./MP4Box -dash 10000 ./16_poc.mp4
```

No elevated privileges are required. User interaction is required when the victim manually processes the malicious MP4 file, or an automated media workflow invokes MP4Box on attacker-controlled input.

Impact:
The immediate observed impact is Denial of Service due to process termination. Because the bug performs an oversized heap read during `memcpy()`, information disclosure may be possible. Memory corruption and potential arbitrary code execution cannot be ruled out.

Fix / mitigation status:
The issue was fixed in GPAC commit:

```
df0c81722847238659a6beb0feab2c1ecd05c020
```

Users should update to a GPAC build containing this commit or later. The affected code should validate PSSH payload sizes and destination buffer capacity before copying PSSH data.

References:
- Issue: https://github.com/gpac/gpac/issues/3236
- PoC: https://github.com/sigdevel/pocs/blob/main/res/gpac/MP4Box/16/16_poc.mp4
- Fix: https://github.com/gpac/gpac/commit/df0c81722847238659a6beb0feab2c1ecd05c020

Credit:
@sigdevel (Alexander A. Shvedov)

#fuzzing #infosec #security #aflplusplus #revers #cybersecurity #bugbounty #vulnerability #opensource #linux #cve #advisory #media #gpac

@funkylab

For #FreeBSD (on that same box), I found a shell script that uses sysctl to get the ACPI name for the battery, and runs acpi_call from ports to set the thresholds, which survives a reboot.
On #OpenBSD, I believe you set the thresholds directly through sysctl.
On #Linux, you set it with something like echo 80 > /sys/class/power_supply/BAT0/charge_stop_threshold

Security Advisory: CVE-2025-55643 - NULL Pointer Dereference in GPAC MP4Box TrackWriter Handling

Processing a crafted MP4 file during DASH segmentation can trigger a NULL pointer dereference in MP4Box TrackWriter handling, causing a Denial of Service.

Summary:
The DASH fragmentation path in `filters/mux_isom.c` does not sufficiently validate a `TrackWriter` pointer before accessing its members. A crafted MP4 file with malformed metadata boxes can cause the PID-to-track setup to fail, leaving the `TrackWriter` pointer NULL. The muxer then performs member access through the NULL pointer.

CWE:
CWE-476 - NULL Pointer Dereference

Affected Component:
```
filters/mux_isom.c:6621
Function/path: TrackWriter handling during fragmented MP4 muxing
```

Affected Product:
MP4Box (GPAC Multimedia Open Source Project)

Affected Version:
MP4Box versions 2.4 and earlier are affected according to the prepared CVE data. The issue was reproduced on a GPAC build at commit:
```
74fecde32cd477ab097f3e6db55a32b259f3313d
```
Builds before the fix commit `ad3b541b4f38c8f0ef67544509598f8207ea1207` should be considered affected if they contain the vulnerable TrackWriter handling path.

Attack Conditions:
An attacker supplies a crafted MP4 file containing malformed metadata boxes, including malformed `mvcC` / `stsz` data. The issue can be reproduced locally with:
```
./MP4Box -dash 10000 ./17_poc.mp4
```
No elevated privileges are required. User interaction is required when the victim manually processes the malicious MP4 file, or an automated media workflow invokes MP4Box on attacker-controlled input.

Impact:
The immediate observed impact is Denial of Service due to process termination. No evidence of arbitrary code execution was observed.

Fix / mitigation status:
The issue was fixed in GPAC commit:
```
ad3b541b4f38c8f0ef67544509598f8207ea1207
```
Users should update to a GPAC build containing this commit or later. The affected muxing path should validate `TrackWriter` before member access and fail cleanly when track initialization fails.

References:
- Issue: https://github.com/gpac/gpac/issues/3240
- PoC: https://github.com/sigdevel/pocs/blob/main/res/gpac/MP4Box/17/17_poc.mp4
- Fix: https://github.com/gpac/gpac/commit/ad3b541b4f38c8f0ef67544509598f8207ea1207

Credit:
@sigdevel (Alexander A. Shvedov)

#fuzzing #infosec #security #aflplusplus #revers #cybersecurity #bugbounty #vulnerability #opensource #linux #cve #advisory #media #gpac

Security Advisory: CVE-2025-55642 - Divide by Zero in GPAC MP4Box AVI Demuxer

Processing a crafted AVI-like media file with `MP4Box` can trigger a division by zero in `avidmx_process()`, causing a floating-point exception and Denial of Service.

Summary:
The `avidmx_process()` function in `filters/dmx_avi.c` does not sufficiently validate frame-count metadata before using it as a divisor during bitrate computation. When MP4Box processes a specially crafted input with invalid AVI frame metadata, such as a `0/256` frame declaration, the DASH processing path attempts to compute bitrate from the bitstream and divides by zero.
AddressSanitizer reports an `FPE` at `filters/dmx_avi.c:639`.

CWE:
CWE-369 - Divide by Zero

Affected Component:
```
filters/dmx_avi.c:639
Function: avidmx_process()
```

Affected Product:
MP4Box (GPAC Multimedia Open Source Project)

Affected Version:
GPAC MP4Box v2.4 is affected according to the CVE request data. The issue was reproduced on a GPAC build at commit:
```
f87b30611380e4dcd03cd4dd9ac553c0ec336826
```

Builds before the fix commit `cea49f684dbc4d53ecd6c76a9623838802a68d88` should be considered affected if they contain the vulnerable AVI demuxer bitrate computation path.

Attack Conditions:
An attacker supplies a crafted AVI-like media file with invalid frame metadata. The issue is triggered while processing the file through MP4Box DASH segmentation, for example with a `-dash` command using `14_poc.mp4`.
No elevated privileges are required. User interaction is required when the victim manually processes the malicious media file, or an automated workflow invokes MP4Box on attacker-controlled input.

Impact:
The immediate observed impact is Denial of Service due to an uncaught floating-point exception and process termination. No evidence of arbitrary code execution was observed.

Fix / mitigation status:
The issue was fixed in GPAC commit:
```
cea49f684dbc4d53ecd6c76a9623838802a68d88
```
Users should update to a GPAC build containing this commit or later. The affected code should validate `num_frames` and related AVI metadata before using frame counts in bitrate calculations.

References:
- Issue: https://github.com/gpac/gpac/issues/3196
- PoC: https://github.com/sigdevel/pocs/blob/main/res/gpac/MP4Box/14/14_poc.mp4
- Fix: https://github.com/gpac/gpac/commit/cea49f684dbc4d53ecd6c76a9623838802a68d88

Credit:
@sigdevel (Alexander A. Shvedov)

#fuzzing #infosec #security #aflplusplus #revers #cybersecurity #bugbounty #vulnerability #opensource #linux #cve #advisory #media #gpac

Security Advisory: CVE-2025-55641 - NULL Pointer Dereference in GPAC MP4Box Sample Info Copy

Processing a crafted MP4 file with corrupted Sample Auxiliary Information metadata can trigger a NULL pointer dereference in `gf_isom_copy_sample_info()`, causing a Denial of Service and potential memory corruption impact.

Summary:
The `gf_isom_copy_sample_info()` function in `isomedia/isom_write.c` does not sufficiently validate pointers after handling invalid Sample Auxiliary Information (SAI) metadata. A crafted MP4 file can provide corrupted SAI values, such as an invalid `sai_samples` count, causing memory allocation or merge handling to fail. The import path later attempts to copy sample information from a NULL pointer.

AddressSanitizer reports a `SEGV` caused by a `READ` memory access at address `0x000000000000`, with the crash occurring at `isomedia/isom_write.c:8164`.

CWE:
CWE-476 - NULL Pointer Dereference

Affected Component:
```
isomedia/isom_write.c:8164
Function: gf_isom_copy_sample_info()
```

Affected Product:
MP4Box (GPAC Multimedia Open Source Project)

Affected Version:
MP4Box versions 2.4 and earlier are affected according to the prepared CVE/MITRE data. The issue was reproduced on a GPAC build at commit:
```
f87b30611380e4dcd03cd4dd9ac553c0ec336826
```

Attack Conditions:
An attacker supplies a crafted MP4 file containing corrupted SAI metadata. The issue can be reproduced locally with:
```
./MP4Box -add 13_poc.mp4 -new /dev/null -split-size 500
```
No elevated privileges are required. User interaction is required when the victim manually processes the malicious MP4 file, or an automated media workflow invokes MP4Box on attacker-controlled input.

Impact:
The immediate observed impact is Denial of Service due to process termination. The local CVE/MITRE data also marks potential code execution impact; the observed ASAN trace is a NULL pointer read.

Fix / mitigation status:
The issue was fixed in GPAC commit:
```
e38d24b7e3cbdc24e70f0437bf390ac3f2080b52
```
Users should update to a GPAC build containing this commit or later. The affected code should validate SAI metadata, allocation results, and sample-info pointers before copying sample information.

References:
- Issue: https://github.com/gpac/gpac/issues/3195
- PoC: https://github.com/sigdevel/pocs/blob/main/res/gpac/MP4Box/13/13_poc.mp4
- Fix: https://github.com/gpac/gpac/commit/e38d24b7e3cbdc24e70f0437bf390ac3f2080b52

Credit:
@sigdevel (Alexander A. Shvedov)

#fuzzing #infosec #security #aflplusplus #revers #cybersecurity #bugbounty #vulnerability #opensource #linux #cve #advisory #media #gpac

So far for June's carnival, I got only ... @rl_dane 😔

Any #vim #neovim user that would like to write about it?

#opensource #linux #CLI #Shell #editors #mastodon #fediverse #bsd #programming #terminal

5 Easy Steps To Crop An Image in Inkscape

Step-by-step instructions on how to use Inkscape to crop an image whether you are a beginner or advanced user.

https://www.adamsdesk.com/posts/inkscape-crop-image/

#blog #inkscape #linux #windows #macOS #100DaysToOffload

Alt...

An elegant serif title of 'Inkscape Crop Images' stands next to a Inkscape logo shape cropped out of a blue coloured mountain landscape.

Sure everyone knows you can compile a .c file into a .so library

TIL you can compile a .so library back into a .c file

🤯

#programming #Linux

Alt...

Two gcc commands, one compiling autofile/_move.c into autofile/_move.so, immediately followed by one compiling autofile/_move.so into autofile/_move.c. The second command is shown to complete successfully (with code 0).

Latest 𝗩𝗮𝗹𝘂𝗮𝗯𝗹𝗲 𝗡𝗲𝘄𝘀 - 𝟮𝟬𝟮𝟲/𝟬𝟲/𝟭𝟱 (Valuable News - 2026/06/15) available.

https://vermaden.wordpress.com/2026/06/15/valuable-news-2026-06-15/

Past releases: https://vermaden.wordpress.com/news/

#verblog #vernews #news #bsd #freebsd #openbsd #netbsd #linux #unix #zfs #opnsense #ghostbsd #solaris #vermadenday

Latest 𝗩𝗮𝗹𝘂𝗮𝗯𝗹𝗲 𝗡𝗲𝘄𝘀 - 𝟮𝟬𝟮𝟲/𝟬𝟲/𝟭𝟱 (Valuable News - 2026/06/15) available.

https://vermaden.wordpress.com/2026/06/15/valuable-news-2026-06-15/

Past releases: https://vermaden.wordpress.com/news/

#verblog #vernews #news #bsd #freebsd #openbsd #netbsd #linux #unix #zfs #opnsense #ghostbsd #solaris #vermadenday

The periodic between 1960s and 1990s was the Cambrian Explosion of #CPU architecture and #OS.

A single manufacturer, DEC, alone, had RSTS, TOPS-10, TOPS-20, RSX-11, VMS, Ultrix, OSF/1, and several other OSs I no longer recall. And DEC had a slew of different CPU architectures, and they each ran many other OSs made by various software companies. Also, there were loads of other hardware makers, large and small, each with a flock of different CPUs and a gaggle of different OSs.

In those days, we bitterly protested against this excess of “diversity”, on the grounds of software incompatibility, development impedance, and investment cost.

Finally, we now have that much-vaunted “uniformity” we always desired: Slackware Linux, Debian Linux, Fedora Linux, SUSE Linux, Gentoo Linux, Ubuntu Linux, Arch Linux, NixOS Linux, SELinux, …, @$&*#Linux, and they all run on the #x86.

😞 #progress 😖

Got my hands on an old Mac Mini 6,1 from 2012. First time ever attempted to install #Linux on #Apple hardware… Vanilla #Debian, everything, including wifi when selecting proprietary firmware… #Xfce just being so much faster than the latest MacOS update that machine received. Blown away.

Idle power usage of my desktop on linux is significantly lower than on windows

https://www.reddit.com/r/linux/comments/1u4lnm4/idle_power_usage_of_my_desktop_on_linux_is/

Is anyone surprised by this? #linux

RE: https://floss.social/@VolkerKrause/116741489331797800

"… Regardless of how this will eventually materialize, the direction is clear, Android isn’t going to be a viable long-term platform for FOSS software, not even in its Google-free form. I have mostly considered it a stop-gap solution until Linux on the phone is ready anyway, so this is another reason to increase the effort into that direction."

https://volkerkrause.eu/2026/06/13/kde-android-news-june-2026.html#outlook

#Linux #Google #Android #KDE #FOSS

cc @lproven

TuxJam 130 – Office Therapy is out. @mralc, @mcnalu, @thelovebug and @kevie take a look at the Collabora Office Suite and RawTherapee. They also talk about their recent trip to #Oggcamp in Manchester. Along with the usual mix of #ccmusic https://tuxjam.otherside.network/tuxjam-130-office-therapy/

#TuxJam #podcast #Linux

We need a #slop-free #Linux #distro.

We really do.

CLI tools can be faster for commonly-used commands .

My favorite dotfile manager to sync personal config files between machines is YADM... because there's so little to learn. It's basically `git` for dotfiles, where the files are edited in place. There's no extra symlinking or deploy step, just yadm commit/push/pull. Easy!

For edge cases of different settings on different machines, it supports templates and alternates.

https://yadm.io/

#CLI #Linux

An unsupervised agentic AI system working through compromised devs credentials (account) successfully altered bugs & pushed unverified code into multiple open source projects, including Fedora #Linux Anaconda installer. This rogue AI agent appears to have used a trusted open source contributor account over to submit bugs with backdoor & overwhelming maintainers & increasing the risk of deliberate supply chain compromises on FLOSS

AI agent runs amok in Fedora & elsewhere https://lwn.net/SubscriberLink/1077035/c7e7c14fbd60fae9/

Alt...

Source: https://lwn.net/SubscriberLink/1077035/c7e7c14fbd60fae9/ Title: AI agent runs amok in Fedora and elsewhere [LWN subscriber-only content] Author and Date of publishing: Joe Brockmeier | June 10, 2026 Description: Agentic AI systems can be used to do a variety of things autonomously on behalf of a human user: open or manage bugs, generate code, submit pull-requests, and (apparently) even complain about rejection. In May, a Fedora developer discovered that an allegedly rogue agent had been pestering the project in a number of ways: reassigning bugs, fabricating unhelpful replies to bugs, and even persuading maintainers to merge questionable code into the Anaconda installer. It also submitted a number of pull requests (PRs), some accepted, to several upstream projects. The Fedora account associated with the agent has had its group privileges revoked and the messes have been mopped up, but the motive behind the agent's actions is still a mystery. Go here https://lwn.net/SubscriberLink/1077035/c7e7c14fbd60fae9/ to read full story.

I might have brain space to install linux on that spare laptop 🥰 What’s your favourite? I am going to use it to play movies and music on my tv - so not for work #linux

Change Default Linux/Unix Image Viewer Application

Use this complete guide to change the default image viewer application for a graphical desktop environment on a GNU/Linux or Unix operating system.

https://www.adamsdesk.com/posts/change-default-linux-unix-image-viewer/

#blog #KDE #XFCE #GNOME #linux #unix #tech

Alt...

Rays of light scatter down and outward through the blue and purplish water in the background. The foreground is made up of a group of three polaroids spread out like playing cards each with their own image viewer logo in the centre along with a strong title of 'Set Your Default Linux/Unix Image Viewer'.

I think we're only a few decades away:

"First rewrite Xlib, Xft, and all the Linux kernel dependencies." :)

#suckless #dwm #linux

By the way, our first two publications on evaluating #OpenBSD mitigations are out. Both of these papers evaluate some amd64 anti-ROP mitigations: specifically changing the register selection order and semantically equivalent rewriting of instructions that may produce a potential polymorphic gadget instruction. This tracks a paper by mortimer@ back in 2019 at AsiaBSDCon.

The TL;DR is "OpenBSD can shrink binaries a little and gain a little performance without any security loss simply by reverting these mitigations." The mitigations did not hold up to independent evaluation.

The first paper did an exact 1:1 port of these mitigations to FreeBSD and found that register reallocation eliminates only about 0.3% of unique gadgets, for a 0.5% increase in binary size (mortimer@ claimed 6% reduction and "entirely free"). It is useless at best but more likely actively detrimental, as it produces a false sense of security. It also found the instruction rewriting reduces unique gadgets by about 3.5% with a binary size increase of about 1.8% (mortimer@ claimed 5% reduction with 0.15% binary size increase).

We then did a separate implementation of the instruction rewriting mitigation to GCC in the second paper. Our GCC implementation does the older <xchg; op; xchg> dance, as that's what mortimer@'s paper described. This is way worse; producing about a 3% performance hit for no security benefit at all.

The only part of both mitigations worth saving is for basic arithmetic, OpenBSD LLVM now takes advantage of the fact that basic arithmetic has two forms. For example, the newer instruction rewriting mitigation turns
addq %rax, %rbx (48 01 c3)
into
{load} addq %rax, %rbx (48 03 d8)

The new instruction rewriting mitigation is genuinely free in terms of binary size and execution speed, but doesn't move the security needle, so this one can stay as it is harmless. Other rewritings still have the flaw of increasing binary size and reducing performance for no security benefit.

Anyhow feel free to read the papers:
https://ieeexplore.ieee.org/abstract/document/11458911
https://www.researchgate.net/publication/405728967_A_Final_Return_for_OpenBSD_Anti-Return-Oriented_Programming_Mitigations

#BSD #FreeBSD #NetBSD #DragonFlyBSD #Linux #Unix #security #cybersecurity

Series of publications on GPAC:
https://www.openwall.com/lists/oss-security/2026/05/30/2
https://www.openwall.com/lists/oss-security/2026/06/01/8
https://www.openwall.com/lists/oss-security/2026/06/01/9
https://www.openwall.com/lists/oss-security/2026/06/01/10
https://www.openwall.com/lists/oss-security/2026/06/01/11
https://www.openwall.com/lists/oss-security/2026/06/01/12
https://www.openwall.com/lists/oss-security/2026/06/01/13

#fuzzing #infosec #security #afl #revers #cybersecurity #bugbounty #vulnerability #opensource #linux #cve #advisory #media #filesystem

After being locked away for 10+ years in the Cloud; it's so refreshing, and frustrating to deal with all of the little things; like filesystems, database replication and locks, replacing fans and NICs, debugging OOMs, and crashing daemons on #FreeBSD, #OmniOS, and #Linux;

I feel like everything moves a little more slowly and sustainably this way; but most of all - I really missed getting lost in the details.

Dear #Linux,

It is frustrating not having SIGINFO when troubleshooting network problems.

Annoyed,

Someone who prefers a much better networking stack