Re: CVE-2024-3094: malicious code in xz 5.6.0 and xz 5.6.1

2024-04-03 Thread Ben C. O. Grimm
On April 4, 2024 07:50:55 FreeBSD User wrote: Hello, I just stumbled over this CVE regarding xz 5.6.0 and 5.6.1: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3094 FreeBSD starting with 14-STABLE seems to use xz 5.6.0, but my limited skills do not allow me to judge wether the des

Re: CVE-2024-3094: malicious code in xz 5.6.0 and xz 5.6.1

2024-04-03 Thread Kyle Evans
On 4/4/24 00:49, FreeBSD User wrote: Hello, I just stumbled over this CVE regarding xz 5.6.0 and 5.6.1: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3094 FreeBSD starting with 14-STABLE seems to use xz 5.6.0, but my limited skills do not allow me to judge wether the described explo

Re: CVE-2024-3094: malicious code in xz 5.6.0 and xz 5.6.1

2024-04-03 Thread FreeBSD User
Am Thu, 04 Apr 2024 08:06:26 +0200 (CEST) sth...@nethelp.no schrieb: > >> I have to report to my superiors (we're using 14-STABLE and CURRENT > >> and I do so in private), > >> so I would like to welcome any comment on that. > > > > No it does not affect FreeBSD. > > > > The autoconf script ch

Re: CVE-2024-3094: malicious code in xz 5.6.0 and xz 5.6.1

2024-04-03 Thread sthaug
>> I have to report to my superiors (we're using 14-STABLE and CURRENT >> and I do so in private), >> so I would like to welcome any comment on that. > > No it does not affect FreeBSD. > > The autoconf script checks that it is running in a RedHat or Debian > package build environment before tryin

Re: CVE-2024-3094: malicious code in xz 5.6.0 and xz 5.6.1

2024-04-03 Thread Paul Floyd
On 04-04-24 05:49, FreeBSD User wrote: Hello, I just stumbled over this CVE regarding xz 5.6.0 and 5.6.1: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3094 FreeBSD starting with 14-STABLE seems to use xz 5.6.0, but my limited skills do not allow me to judge whether the described

Re: LOR so_snd_sx / nfs

2024-04-03 Thread Rick Macklem
Shouldn't be a problem. The socket used for lookup is AF_UNIX (uses unp_connectat) and the NFS socket will always be UDP or TCP. Different sockets imply different socket locks. At least that's my interpretation, rick On Wed, Apr 3, 2024 at 11:33 AM Bjoern A. Zeeb wrote: > > > NFS root boot of a

LOR so_snd_sx / nfs

2024-04-03 Thread Bjoern A. Zeeb
NFS root boot of a Lab machine; calling wpa_cli: Thilock order reversal: 1st 0x0001d4e1c800 so_snd_sx (so_snd_sx, sx) @ /usr/src/sys/kern/uipc_socket.c:4020 2nd 0xa020cb20e930 nfs (nfs, lockmgr) @ /usr/src/sys/kern/vfs_lookup.c:1083 lock order nfs -> so_snd_sx established at: #0 0xf