That's in dmesg with kernel 5.15.19. My assessment is that's not really a serious bug requiring action for the ordinary luser. Or should I go searching for a microdode update?

The CPU is an i3-3110m from 2012. The data it's handling is boring.

Your assessment is right. This kind of data leak is a potential problem only for servers that run untrusted code, and then exploiting the vulnerability is a difficult and slow process.
Ed

I'm not sure if there's an MCU for MDS for 3rd gen (and with 5.15.19 I'd expect it would've grabbed it if possible; spectre-meltdown-checker would confirm if you're using the latest if you're really curious) - even if you have the update it will still throw the warn on SMT (if you were to also disable HyperThreading it quiets down) for basically the reasons EdGr points out (it can be an issue with VMs + SMT iirc as well).

Assuming this is some sort of Spectre/Meltdown vulnaribility:
The mitigation can be enabled in the kernel, but it brings a hefty performance penalty.
Most desktop distros choose not to do that.

AFAIU, and simplified to a point that some will groan, the vulnerability is what makes them faster.

This is not Spectre - its part of the MDS bug/vulnerability related to SMT ('Hyperthreading' for Intel marketing). You can read more about it here: https://en.wikipedia.org/wiki/Microa..._Data_Sampling

On one hand it probably is something to consider if you're hosting a bunch of VMs and hoping the hypervisor is effectively airgapping them across SMT (which it probably isn't), but if you've got the patches for whichever 'version' ('MDS' corresponds to like half a dozen CVEs that themselves correspond to various SKUs) of this can leak data in a browser (which AFAIU is browser-side patches), the 'low-to-medium' severity isn't insane guidance AFAICT. If you're really paranoid, turn SMT off. I think what the 'error' here is trying to relay is that SMT is enabled and there's no MCU patch, but there should still be software patches if you're using such an up-to-date kernel (which I'm assuming is part of an up-to-date distro with similarly up-to-date packages); if you want more clarity run spectre-meltdown-checker, which in recent versions has been expanded to check MCU version and summarize MDS as well - it too will warn about SMT being enabled.

Let's make one thing clear: I don't consider my cpu as 'fast'

Thanks for all the replies, I've obviously raised a topic of interest, and it's good to have the state of play laid out in this thread for others. I really have my answer. The sky won't fall in if I do nothing, so that's what I'll do.

The kernel blurb os going a bit OTT for me. The first time I booted Slackware-15.0, I got a few KB of onscreen messages 'warning' me that the sdcard in the SDCard reader could operate at a lower voltage than I was actually applying.

If this is in 15.0, it very likely even is applying patches, but the notes from kernel.org (https://www.kernel.org/doc/html/latest/x86/mds.html) indicate at least some of the 'fix' requires a microcode update for the CPU. From doing a bit of searching, your CPU *should* have a compatible MCU (https://www.techpowerup.com/255545/i...thed-on-may-14), so now I'm curious why that isn't being loaded. Might be something to look into...

That brings us to a very sore point.

I got this box in early 2013, when EFI was brand new. Samsung's Bios were straight out of the M$ play book, and I eventually got linux going by formatting a hd with fdisk/mbr, because if I used GPT it defaulted to UEFI regardless of settings. So I don't get updates, because I don't have UEFI. I would have replaced this laptop last year, except graphics cards were basically unavailable for any new box.

I don't have the cpu cores or the ram to run VMs. I might get one crawling, but I don't need it at the moment, as any windows-only stuff is well handled by wine. So MDS is other people's problem. I did get a microcode update after the Meltdown/Spectre thing broke.

I'll have to get serious when I buy. Right now, I can't be bothered.

I don't mean 'firmware' on the device, I mean MCU in the OS - linux can apply the microcode at start-up (which is how most machines get microcode patches these days - Windows too). Slackbuilds has a build for 14.2 (https://slackbuilds.org/repository/1...tel-microcode/), not sure about 15.0 yet, but I can't imagine it is impossible. Probably I would just let the MCU update run for peace of mind, but I'm also guessing as everyone has said: this probably isn't a huge deal for client systems (likely unless there's some nasty browser-based exploit that I'm not aware of).