So that people can at least add auditing: While ideally you would have these set up for all of the PF/AF families you don't expect, The following are probably low noise and should be added to your audit logs so that your EDR and other security tools can find them.
``` auditctl -a always,exit -F arch=b64 -S socket -F a0=33 -k pf_rxrpc auditctl -a always,exit -F arch=b64 -S socket -F a0=38 -k pf_alg ``` The gnu bits/socket.h file is probably the easiest way to find most of the numeric mappings, e.g.: /usr/include/x86_64-linux-gnu/bits/socket.h PF/AF 1,2,10,16,17 are the ones that most people would use, with AF_VSOCK(40) as an exception that may be too noisy to log, along with bluetooth on desktops etc... IMHO, longer term, a bounding set in a text file in /etc of PF/AF families that can be used on a system is the more maintainable and robust solution in the end. socket() is just too tempting of an interface, with no real security boundaries unless it is device/file mediated. It should be blockable at the system level by PF/AF no matter if it is loading a module or is compiled in at the system level IMHO. On Fri, May 8, 2026 at 10:12 AM Kalin KOZHUHAROV <[email protected]> wrote: > > On Fri, May 8, 2026 at 6:39 AM Daniel Tang > <[email protected]> wrote: > > > > > no patches [...] exist > > > Well patches will eventually come, but mitigation across the board hit > a few snags already, so from my lessons learned I baked a script to > apply the mitigation. > Actually renaming the modules, not relying on modprobe config, since > there are some distros that don't have that by default. > > After some initial testing and with GNU parallel as (often) last > resort mass deployment tool, I just released it on > https://github.com/thinrope/cf-df in the hope that I may save some > minutes or hours of someones' job. The script itself is useful on its > own, to be deployed via any configuration management system, or run by > hand. > > Any feedback/issues/PR are welcome. > > Here is the README (reformatted to plaintext for clarity): > =================================================================== > https://github.com/thinrope/cf-df > === copy.fail + Dirty Frag patching-on-the-fly === > > Patch copy.fail[1] and Dirty frag[2] related CVEs > > == Why? == > > I suddenly needed to patch a multitude of linux hosts in various > platforms with minimal impact. I don't trust the suggested method of > disabling module loading, I'd rather have the file renamed (or even > deleted at some point). > > == How? == > > Execute the cf+df_patching.sh script as root on any host. Use and > configuration management system you have in place. Alternatively, for > those odd mass cases, use the wonderful GNU parallel[5] from a central > host via ssh (run as root, ssh as root[3,4]): > > git clone https://github.com/thinrope/cf-df.git > cd cf-df > $EDITOR target.list > parallel --tag --nonall --slf target.list --workdir ... --transferfile > cf+df_patching.sh --cleanup 'bash cf+df_patching.sh' > > == References == > > [1] copy.fail: https://copy.fail/ > [2] Dirty frag: https://github.com/V4bel/dirtyfrag > [3] If you cannot login via ssh directly as root, use sudo properly > [4] ... or abuse these CVEs before you patch to obtain root :-D > [5] GNU parallel: https://www.gnu.org/software/parallel/ > =================================================================== > > > Regards, > Kalin.
