From: Lester Thorpe <lt@gnu.rocks>
Subject: The Security Circus Continues
Newsgroups: comp.os.linux.advocacy,comp.os.linux.misc,alt.os.linux
Followup-To: comp.os.linux.advocacy
Mime-Version: 1.0
User-Agent: Don't Look Here the Joke's in Your Pants
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Lines: 34
Path: ...!npeer.as286.net!npeer-ng0.as286.net!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!news.usenetexpress.com!not-for-mail
Date: Wed, 18 Sep 2024 10:32:06 +0000
Nntp-Posting-Date: Wed, 18 Sep 2024 10:32:06 +0000
Organization: UsenetExpress - www.usenetexpress.com
X-Complaints-To: abuse@usenetexpress.com
Message-Id: <17f6500d803f0672$39525$1458621$802601b3@news.usenetexpress.com>
X-Received-Bytes: 1906
Bytes: 2033

The security circus continues... (what else can it do?)

Kernel 6.11 has added yet more security garbage:

SLAB_BUCKETS

"Kernel heap attacks frequently depend on being able to create
specifically-sized allocations with user-controlled contents
that will be allocated into the same kmalloc bucket as a
target object. To avoid sharing these allocation buckets,
provide an explicitly separated set of buckets to be used for
user-controlled allocations. This may very slightly increase
memory fragmentation, though in practice it's only a handful
of extra pages since the bulk of user-controlled allocations
are relatively long-lived."

The rationale:

"many heap memory spraying/grooming attacks depend on using
userspace-controllable dynamically sized allocations to collide with
fixed size allocations that end up in same cache"

Yeah, sure.

Like who/what the fuck will ever attempt that on my personal
desktop workstation?

Just say "No."  Keep your fucking security hallucinations off
of my fucking machine.



-- 
Systemd: solving all the problems that you never knew you had.