floof.org
Today feeling very "Creature" coded....
So wearing my kigu and fursuit stompies around
Rezz - AM BIG SCARY DERG! RAWR!
Urban - Sure you are, Rezz. Big and scary...
*pat pat pat*
With Urban (Incog) #fursuitfriday
If you are as annoyed as me about the fancy CVE-2026-31431 website not actually mentioning what Kernel versions to update to (only mentioning the commit rev), I translated this for you by looking through the releases manually and checking if they contain the fix.
The following upstream kernel tags contain the fix:
5.10.254+
5.15.204+
6.1.170+
6.6.137+
6.12.85+
6.18.22+
6.19.12+
7.0+
But of course your distro might also apply the patches on any other version, and they will hopefully provide that information.
Edit: added 6.6/6.12 versions
Mitigation to #CVE_2026_31431 / #copyfail :
- If kernel config has CONFIG_CRYPTO_USER_API_AEAD=m:
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf; sudo rmmod algif_aead
- If kernel config has CONFIG_CRYPTO_USER_API_AEAD=y:
Add "initcall_blacklist=algif_aead_init" to the kernel command line and reboot.
You can use the following the check if the mitigation has been applied correctly:
python3 -c 'import socket; s=socket.socket(38,5,0);
try:
s.bind(("aead","authencesn(hmac(sha256),cbc(aes))"))
print("AEAD interface present")
except OSError:
print("AEAD interface disabled")'
Once again, my professional recommendation in response to the latest Linux kernel vulnerability in the news is that you should gather up all your electronic devices, cast them into the sea, and retreat to the woods.
Each night, gather your children and tell them tales of the Before Times when the hubris of humanity grew so large that we made idols of sand and spoke to them as equals. Remind them that the sand, of course, did not speak or think, but we imagined it could, and let it guide us to folly.
Should a stranger ever come to your village with a glowing rectangle, encourage the youth to beat them with sticks.
See us on tour now. Tix & new limited merch available at www.wearekream.comGo follow our LIQUID : LAB Youtube page for monthly mixes https://www.youtube.com/...YouTube
Lewis Pullman, Bill Pullman, Josh Gad, Rick Moranis, Daphne Zuniga and Josh Greenbaum chat with ET's Nischelle Turner all about their highly anticipated new ...YouTube
Content warning: bitching about openai/chatgpt/ai/llms
Lots of animals! And yet still I missed many. I saw them but couldn't get to them before they disappearedTasty Eagle (Flickr)
Have you ever actually read the TOS for any of the AI tools you use, well probably not but there's some fun little excerpts that you can find==========Suppor...YouTube
sometimes u just become a bee ya knowtldr-- been working full time as a teacher after i graduated college ~ 2 years ago & have been working on my own indie p...YouTube
"I've got a lot to do now, like go to my room and cry in the fetal position. My pillow's not going to sob into itself."
Wise words, Tiabeanie.
Not here to catch anything today. He has seen people feed the fish before, tossing little bits into the water. So he thought… why not share something better? That something he enjoys a lot!
Piece for Red Panda Bean.
Traditional. Markers + Colored pencils.
For #FursuitFriday, a few pics of Peaches from Ainmhícon.
With Maple, Strawberry, Berry, & Dobie.
I’m not wearing Peaches here - it’s @KandaBear on goat duty.
I could not find my multimeter. Looked everywhere I could think of. Eventually, gave up and sat back down at my desk… and immediately found it. It was right next to my left elbow.
With a piece of paper on top of it.
The 3.6V battery I wanted to test in fact read about 2mV, so yes, replacement ordered.
RE: https://mastodon.social/@mmalc/116364176497768667
This
Attached: 1 image It's frustrating that the UK is trying to follow in the USA's political footsteps… #USPol #UKPol (Not sure who to credit for the artwork.)mmalc (Mastodon)
I just tried to tell my dad what I'd achieved today, and had one of those "first create the universe" moments. I pretty much ended up describing (simplified) the whole technical history of my hosting network, what BGP, OSPF and VRRP do and how they fit together, how my router setup has evolved over time, and quite a few sidetracks too, to explain that what I'd done today was to complete a script that sets up Linux "virtual MAC interfaces" for the VRRP implementation I'm hoping to soon migrate to, because the vrrp keyword built into the ifupdown2 package I've been using doesn't do a few things quite exactly the way I need and it's easier to reimplement than to fix.
Explaining all that took probably an hour and left my throat really dry and with the realisation of just how *much* technical stuff I have to look after to run a whole hosting ISP single-handedly. I really *really* ought to actually try to get some more customers in - pretty much all the customers I have, I got by accident.
FYI I do server colocation in London, UK, plus most of the other stuff a hoster does: domains and DNS, email (well, not really at the moment, email's one of the more horrible things to host and the current setup is very old and crusty and needs modernising before I'll be happy taking on email customers), web hosting, virtual servers, etc. My main selling points are service and reliability - if cost is your main factor in choosing a host, you might want to try elsewhere. ;) If I haven't scared you off and you're interested, feel free to ask.
Looks like FRR's VRRP implementation has a lot of weirdnesses. It works by having you configure a macvlan interface attached to the actual interface VRRP is running on. The macvlan interface has the VRRP virtual router MAC address on it, plus the virtual IP addresses. VRRPd doesn't touch the addresses or interfaces, other than to set or remove "protodown on" on the macvlan interface.
Weirdnesses discovered so far:
1. Packets that should transit the router running VRRP which are addressed to a virtual IP address on a VRRP macvlan interface in backup mode get received by that router rather than being routed on and ending up at the active VRRP router. Not a huge problem, but can be annoyingly misleading when, e.g., tracerouting.
2. Packets addressed to the VRRP subnet get routed out the macvlan interface even in backup mode unless you turn on "ignore_routes_with_linkdown" for the interface in sysctl. Again, not a huge problem (it's nice to have ingress and egress from a given subnet on the same router for statistics purposes but it's not a deal-breaker if not). Solved, but just the first indication that there may be any number of other related weirdnesses.
3. The one that's currently bugging me. Since the macvlan interface is still "up" (albeit also "protodown on") while VRRP is in the backup state, so that VRRPd can listen for VRRP announcements from other routers, the kernel still receives packets addressed to the VRRP virtual MAC address. Unfortunately, it also still *forwards* those packets. That's not actually a problem as long as your switches correctly learn where the VRRP MAC address lives and send packets only to that interface, but if (as mine have) they decide they are confused as they've seen that MAC address in two different places, throw up their little hands and say "I have no idea, let's just flood frames for this MAC address" you'll get all VRRP routers in a subnet (active and backup) all receiving all packets going out the default router, and therefore all routing those packets out. So your outbound bandwidth suddenly doubles if you have two VRRP routers, or triples or more if you have three or more. Ouch.
4. Can't remember if there was anything else. But… it feels like there are more that won't come to mind as I write this up.
I've been pondering how to fix number 3, and so far I have a tiny shell script which has to run continuously all the time on every VRRP macvlan interface (and if it breaks, the world ends), which uses "ip monitor" to see when "protodown on" is turned on or off. It would then do something to fix things while in backup state — potentially remove/re-add IP addresses, or possibly turn off/on forwarding for the interface using the kernel sysctl interface, or maybe move the interface between groups so that firewall rules can block forwarding when it's in backup state, or… something else. It feels like I shouldn't need to do this kind of thing just to get the protocol to work properly, though. I wonder if there's a better VRRP implementation I should be using instead, or if I should be reporting bugs to FRR (but their VRRPd has had very few changes in years, which suggests they either consider it works properly or it's disused. And I lack the energy to work out how to report bugs, and to write them up properly.)
*sigh* Why is nothing ever simple?
Content warning: AI, LLMs, and NetBSD