screaming in digital

fixate on what you think you know… you’re missing what you don’t though.

  • 2 Posts
  • 431 Comments
Joined 3 years ago
cake
Cake day: May 7th, 2023

help-circle




  • a security site that (kinda) demands JS shields down? sigh… anyway here is the article for those that prefer to not do silly things…

    cw: OOB writes and race conditions.

    Open source antivirus scanning sits inside mail gateways, file upload checks, and endpoint tooling at organizations of every size. Much of that work runs through ClamAV, the scanning engine maintained by Cisco’s Talos group. The project released two patch versions, 1.5.3 and 1.4.5, carrying fixes for seven security flaws along with smaller hardening changes.

    Most of the patched bugs sit in the code that unpacks and parses executable formats, the part of a scanner built to handle hostile input. CVE-2026-20213 is an integer overflow in the PE rebuild size calculation that a malformed Aspack-packed file can trigger, leading to a heap buffer overflow write. The related CVE-2026-20214 covers an FSG unpacker loop underflow that can write past the section array during a scan of a crafted PE file. Both reach far back through the codebase, with the FSG issue present in builds dating to 2004.

    CVE-2026-20217 rounds out the PE group. A bug in the PESpin unpacker cleanup path could free pointers into the scanned file buffer and crash the scanner. That flaw has lived in the code since 2005. Archive and image format bugs

    Three more fixes address archive and disk-image handling. CVE-2026-20215 is a 7z parser substream count overflow that can under-allocate parser metadata arrays and then write past them when reading a crafted archive. CVE-2026-20243 covers ALZ parser size handling errors that can make malformed ALZ archives panic, abort the scanner, or skip expected scan-limit handling. CVE-2026-20216 is an InstallShield archive extraction limit bypass that can write far more temporary data than intended and drain temporary storage.

    The last parsing flaw, CVE-2026-20244, sits in the 32-bit DMG parser. A short mish stripe table could pass validation and crash the scanner. This one affects only 32-bit builds, going back to version 0.98.1, and leaves 64-bit builds untouched. Quarantine race condition

    The releases also harden the quarantine actions in clamscan, clamdscan, and clamonacc against time-of-check/time-of-use races. Under unsafe quarantine directory settings, those races could redirect files as the scanner copied, moved, or removed them. Hiroki Imai of Ricerca Security, Inc. reported the issue.

    Version 1.5.3 adds a few items beyond 1.4.5. It upgrades the Rust tar dependency to resolve two RUSTSEC advisories and moves the Rust openssl dependency past CVE-2026-41676. Metadata preclass scans now run before the final scan verdict. A ClamOnAcc fix addresses hash bucket list corruption when two watched paths land in the same bucket. Both releases raise the minimum CMake version to 3.17 to repair Linux builds that link static dependencies against libcurl v8.21.0.

    The release files are available on the GitHub release page, and through Docker Hub in Alpine and Debian containers.









  • honestly, I have always had pretty decent experiences with non-oem lead-acid batteries. my local battery place has a decent supply and longevity is roughly the same as the oem ones (3-4 years). I have never had any issues (type or frequency) that were not also an issue with oem batteries.

    almost no UPS mfcr makes their own batteries, so if you strip off the labeling from the oem ones, you may even find an exact replacement.

    edit: another advantage of a local place is the core-return rebate and disposal of your old batteries.






  • You shouldn’t be getting downvoted.

    agreed. a tad snarky, but it was an honest opinion. lemmy will grow and communities will fill out.

    dumb idea here..

    one thing that may help are clients that allow community aggregation into meta communities. this would allow users to be presented with a themed superfeed of similar communities across many instances. easiest done at the client level (no protocol changes needed), but could be extended to communities using meta tags or moderator inclusion into meta communities with protocol help. protocol support would also allow meta communities to be presented via the web interface.

    perhaps this has already been done in some clients. if implemented thoughtfully it could be interesting and perhaps even useful.