[Bug 267028] kernel panics when booting with both (zfs,ko or vboxnetflt,ko or acpi_wmi.ko) and amdgpu.ko
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267028 --- Comment #349 from George Mitchell --- My system has been upgraded to 14.2-RELEASE. I updated kernel modules graphics/drm-515-kmod-5.15.160.1402000_2 and graphics/gpu-firmware-amd-kmod-raven-20230625.1402000_2 and so far I have not had the crash, But it's early days yet. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 267028] kernel panics when booting with both (zfs,ko or vboxnetflt,ko or acpi_wmi.ko) and amdgpu.ko
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267028 --- Comment #350 from Mark Millard --- (In reply to George Mitchell from comment #349) Which 14.2-RELEASE install files did you use : ) The ones from PkgBase: https://pkg.freebsd.org/FreeBSD:14:amd64/base_release_2/ vs. (different build than above but all the matches to the below are from/for the same build) ) The ones from one of: http://ftp*.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/14.2/FreeBSD-14.2-RELEASE-amd64-*.iso* vs. ) Your own build? Note: The 2 pre-built categories are actually different builds (but are based on the same source code). In addition, which builds did you use for the *-kmod-* packages to match the 14.2-RELEASE : ) The ones from: https://pkg.freebsd.org/FreeBSD:14:amd64/kmods_latest_2/ vs. ) The ones from: https://pkg.freebsd.org/FreeBSD:14:amd64/kmods_quarterly_2/ vs. ) Your own builds? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283807] panic: Fatal trap 12: page fault while in kernel mode on FreeBSD-14.2-RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283807 Bug ID: 283807 Summary: panic: Fatal trap 12: page fault while in kernel mode on FreeBSD-14.2-RELEASE Product: Base System Version: 14.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: free...@sysctl.cz Created attachment 256361 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256361&action=edit core.txt.0 Hi, Before the crash, I looked on Twitch and compiled xray-engine. FreeBSD hades 14.2-RELEASE FreeBSD 14.2-RELEASE releng/14.2-n269506-c8918d6c7412 GENERIC amd64 Fatal trap 12: page fault while in kernel mode cpuid = 11; apic id = 0d fault virtual address= 0x30 fault code= supervisor write data, page not present instruction pointer= 0x20:0x80b66712 stack pointer= 0x28:0xfe0132b03cc0 frame pointer= 0x28:0xfe0132b03d80 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process= 82959 (MediaDecoderStateMa) rdi: fe001b223020 rsi: rdx: rcx: r8: 0201 r9: 0580 rax: 0030 rbx: f80073fd5c00 rbp: fe0132b03d80 r10: r11: 0004 r12: 38b47428f108 r13: 81bbcad0 r14: 81bb2ad0 r15: trap number= 12 panic: page fault cpuid = 11 time = 1735851846 KDB: stack backtrace: #0 0x80b8b89d at kdb_backtrace+0x5d #1 0x80b3dc01 at vpanic+0x131 #2 0x80b3dac3 at panic+0x43 #3 0x81025a0b at trap_fatal+0x40b #4 0x81025a56 at trap_pfault+0x46 #5 0x80ffc398 at calltrap+0x8 #6 0x80b61fc6 at __umtx_op_lock_umutex+0x46 #7 0x80b60b7e at sys__umtx_op+0x7e #8 0x810262c5 at amd64_syscall+0x115 #9 0x80ffccab at fast_syscall_common+0xf8 Uptime: 2d13h44m10s -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283799] tcpdump (14.2+) endian-swaps uid when parsing pflog data
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283799 --- Comment #5 from eborisch+free...@gmail.com --- Created attachment 256362 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256362&action=edit Proposed patch -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283799] tcpdump (14.2+) endian-swaps uid when parsing pflog data
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283799 --- Comment #4 from eborisch+free...@gmail.com --- Something like: pass out log (user) on eth0 in pf.conf should generate cases. Traffic will need to be from someone other than root to be interesting. I see things like: # tcpdump -er /var/log/pflog [...] 16:48:29.398601 rule 5/0(match) [uid 436469760]: pass out on vtnet0: machine.name.one.23101 > machine.name.two.ssh: Flags [S], seq 3725723442, win 65535, options [mss 1460, [|tcp] where that uid should be 1050, and not 436469760. >>> import socket >>> socket.ntohl(436469760) 1050 Most of the other fields are from network code, which frequently lives in the bigendian world. UID and PID are local parameters, so the endian mis-match isn't that surprising, if not explicitly documented. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283807] panic: Fatal trap 12: page fault while in kernel mode on FreeBSD-14.2-RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283807 Mark Millard changed: What|Removed |Added CC||marklmi26-f...@yahoo.com --- Comment #1 from Mark Millard --- More context from Discord's FreeBSD kernel Channel: JordanG: Okay, the code is buggy. umtx_pi_alloc(M_NOWAIT) is called. The flag M_NOWAITmeans that NULL is returned if the memory allocation request cannot be satisfied immediately. The call to the memory allocation routine uma_zalloc fails and returns NULL. umtx_pi_alloc() receives the NULL pointer and immediately, without checking it, tries to access a structure's field via the pointer. And also: JordanG: @maxfx You've discovered a genuine bug that is also present in FreeBSD 15-CURRENT. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283807] panic: Fatal trap 12: page fault while in kernel mode on FreeBSD-14.2-RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283807 Mark Linimon changed: What|Removed |Added Keywords||crash -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283799] tcpdump (14.2+) endian-swaps uid when parsing pflog data
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283799 --- Comment #6 from Joseph Mingrone --- This patch, build, and run tests all look good here. Kristof, are you good with the proposed change? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283799] tcpdump (14.2+) endian-swaps uid when parsing pflog data
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283799 Joseph Mingrone changed: What|Removed |Added CC||k...@freebsd.org --- Comment #2 from Joseph Mingrone --- [CC: k...@freesbd.org who has a better understanding of pf.] Hello, and thank you for reporting. hdr->uid is now defined as nd_uint32_t in contrib/tcpdump/pflog.h [0], so I /thought/ we needed GET_BE_U_4. The equivalent upstream code (which has unfortunately diverged from ours) also uses GET_BE_U_4 when printing the uid [1]. I'm not a pf user, so I'm not clear on the expected output before and after this change. This is what I see now: % id -u 1001 % sudo service pf start Enabling pf. % sudo service pflog start Starting pflog. % cat /etc/pf.conf if="em0" block out log on $if inet proto icmp all % ping google.com # (in another vt) % sudo tcpdump -n -e -ttt -i pflog0 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), snapshot length 262144 bytes 00:00:00.00 rule 0/0(match) [uid 0]: block out on em0: 192.168.2.2 > 142.250.80.46: ICMP echo request, id 40305, seq 0, length 64 Could you share a recipe to demonstrate the problem? -- [0] https://github.com/freebsd/freebsd-src/blob/main/contrib/tcpdump/pflog.h#L118-L151 [1] https://github.com/the-tcpdump-group/tcpdump/blob/master/print-pflog.c#L424-L432 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283799] tcpdump (14.2+) endian-swaps uid when parsing pflog data
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283799 --- Comment #3 from Kristof Provost --- Given this https://cgit.freebsd.org/src/tree/sys/netpfil/pf/if_pflog.c#n256 I'd expect no endianness conversion to be required for uid (and rule_uid, rule_pid). Arguably that's wrong, as we do use big endian for a lot of other fields, but it is what it is now and has been since 2007. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283797] netlink's npt_clear() should set npt->cookie = 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283797 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283795] ICMP echo requests from Windows hosts dropped when NAT'ed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283795 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|p...@freebsd.org Summary|[pf] ICMP echo requests |ICMP echo requests from |from Windows hosts dropped |Windows hosts dropped when |when NAT'ed |NAT'ed -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283799] tcpdump (14.2+) endian-swaps uid when parsing pflog data
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283799
Bug ID: 283799
Summary: tcpdump (14.2+) endian-swaps uid when parsing pflog
data
Product: Base System
Version: 14.2-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: b...@freebsd.org
Reporter: eborisch+free...@gmail.com
In this change:
https://cgit.freebsd.org/src/commit/contrib/tcpdump/print-pflog.c?h=releng/14.2&id=ec3da16d8bc19ad90f04cc227fc8f409813c44f4
Endian macros were added (apparently in error) here:
contrib/tcpdump/print-pflog.c line 122:
if (GET_BE_U_4(hdr->uid) != UID_MAX)
ND_PRINT(" [uid %u]", (unsigned)GET_BE_U_4(hdr->uid));
which causes the output uids to be treated to an incorrect byte-swap.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 283799] tcpdump (14.2+) endian-swaps uid when parsing pflog data
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283799
--- Comment #1 from eborisch+free...@gmail.com ---
Just to explicitly show before/after here:
- if (hdr->uid != UID_MAX)
- ND_PRINT(" [uid %u]", (unsigned)hdr->uid);
+ if (GET_BE_U_4(hdr->uid) != UID_MAX)
+ ND_PRINT(" [uid %u]", (unsigned)GET_BE_U_4(hdr->uid));
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 283795] [pf] ICMP echo requests from Windows hosts dropped when NAT'ed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283795 Bug ID: 283795 Summary: [pf] ICMP echo requests from Windows hosts dropped when NAT'ed Product: Base System Version: 14.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: l...@lbm.dk When multiple Windows hosts ping the same external host, being NAT'ed through pf, ICMP echo requests from all other than the first Windows host to initiate the pinging are dropped. Windows seems to set ICMP identifier based on uptime or alike, typically 0, where others typically use the PID. This is not reproducible in FreeBSD 14.1. Reproducible with three FreeBSD hosts using nping: Configuration: - router /etc/rc.conf: ifconfig_em0="DHCP" ifconfig_em1="inet 10.10.10.1/24" pf_enable="YES" gateway_enable="YES" /etc/pf.conf: nat on em0 from em1:network to any -> em0 - client1 /etc/rc.conf: ifconfig_em0="inet 10.10.10.2/24" defaultrouter="10.10.10.1" - client2 /etc/rc.conf: ifconfig_em0="inet 10.10.10.3/24" defaultrouter="10.10.10.1" Test: - On both clients: pkg install nmap - client1: nping --icmp --icmp-type 8 --icmp-id 0 -c 0 8.8.8.8 - ICMP echo replies are received, keep nping running on client1 - client2: nping --icmp --icmp-type 8 --icmp-id 0 -c 0 8.8.8.8 - ICMP echo replies are NOT received on client2, echo requests dropped by router -- You are receiving this mail because: You are the assignee for the bug.
[Bug 144442] [build] remove unnecessary group and passwd entries for new DESTDIRS // etcupdate
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=12 Enji Cooper changed: What|Removed |Added Summary|[build] remove unnecessary |[build] remove unnecessary |group and passwd entries|group and passwd entries |for new DESTDIRS // |for new DESTDIRS // |mergemaster |etcupdate -- You are receiving this mail because: You are the assignee for the bug.
[Bug 174028] Fix some warnings with fsck_ffs(8)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=174028 Enji Cooper changed: What|Removed |Added Status|Open|Closed Resolution|--- |Overcome By Events --- Comment #5 from Enji Cooper --- This is an ancient patch/report that probably doesn’t apply anymore. Closing. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283797] netlink's npt_clear() should set npt->cookie = 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283797 Bug ID: 283797 Summary: netlink's npt_clear() should set npt->cookie = 0 Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: r...@lcs.mit.edu Attachment #256345 text/plain mime type: Created attachment 256345 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256345&action=edit demonstrate a bug in netlink's npt_clear() npt_clear() in sys/netlink/netlink_io.c zeroes npt->lb, but leaves npt->cookie unchanged. Since npt->cookie (if non-NULL) points into npt->lb, this means that npt_clear() can leave a non-NULL npt->cookie pointing to zeroed contents. As a result, if nl_process_nbuf() takes more than one trip through its for loop, on the second &c trip npt->cookie can be non-NULL even though npt->cookie->nla_len is zero. This can cause nlmsg_ack()'s call to nlattr_add_raw(nw, npt->cookie) to execute return (nlattr_add(nw, nla_src->nla_type, nla_src->nla_len - sizeof(struct nlattr), (const void *)(nla_src + 1))); which (since nla_src->nla_len is zero) will pass attr_len=65532 to nlattr_add. With an INVARIANTS kernel, this will cause an MPASS() or KASSERT() failure. On an ordinary kernel, it will cause nlattr_add() to memcpy off the end of the allocated nw->buf. I've attached a demo. # uname -a FreeBSD 15.0-CURRENT FreeBSD 15.0-CURRENT #335 main-n250995-3750873316a1-dirty: Thu Jan 2 11:25:30 EST 2025 rtm@xxx:/usr/obj/usr/rtm/symbsd/src/riscv.riscv64/sys/RTM riscv # cc netlink4c.c # ./a.out tap0: Ethernet address: da:2e:d7:ce:2d:57 tap0: promiscuous mode enabled REDZONE: Buffer overflow detected. 16 bytes corrupted after 0xffc09e011020 (65568 bytes allocated). Allocation backtrace: #0 0xffc000617370 at redzone_setup+0xa0 #1 0xffc0002d4da8 at malloc_large+0x90 #2 0xffc0002d4bc4 at malloc+0x120 #3 0xffc00052bad4 at nl_buf_alloc+0x2a #4 0xffc00052ca02 at _nlmsg_refill_buffer+0xb2 #5 0xffc00052d11e at nlmsg_ack+0x3a6 #6 0xffc00052bfca at nl_taskqueue_handler+0x32a #7 0xffc000357070 at taskqueue_run_locked+0x158 #8 0xffc000357d74 at taskqueue_thread_loop+0xd4 #9 0xffc0002ba19c at fork_exit+0x68 #10 0xffc0006785ea at fork_trampoline+0xa Free backtrace: #0 0xffc00061773a at redzone_check+0x344 #1 0xffc0002d5bac at free_dbg+0x5c #2 0xffc0002d4976 at free+0x1c #3 0xffc00052bb1c at nl_buf_free+0x14 #4 0xffc00052a85c at nl_close+0x1ca #5 0xffc00038e438 at soclose+0xba #6 0xffc00036cd88 at soo_close+0x20 #7 0xffc0002a1f8e at _fdrop+0x16 #8 0xffc0002a55d8 at closef+0x1b0 #9 0xffc0002a4ca4 at fdescfree+0x4ea #10 0xffc0002b55bc at exit1+0x40a #11 0xffc0002b51ae at sys_exit+0x10 #12 0xffc00067913a at do_trap_user+0x1e0 #13 0xffc000666b12 at cpu_exception_handler_user+0x72 panic: Stopping here. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 242835] concurrency issue when building kernel with 'make -j8': make[5]: make[5]: don't know how to make opt_global.h. Stop
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242835 John Hein changed: What|Removed |Added CC||jcfyecr...@liamekaens.com --- Comment #5 from John Hein --- I just got this when doing 'make buildkernel', also with -j8, on a 13.3-system (trying to update to 13.4-stable; buildworld was fine). Both /usr/src and /usr/obj were on NFS in this case (and /usr/src was mounted read-only - not that it makes a difference for this problem). I tried bmake meta mode (e.g., WITH_META_MODE=yes in /etc/src-env.conf) without -DNO_CLEAN just to see if it would get a successful buildkernel. It didn't (although -DNO_CLEAN and WITH_META_MODE=yes does succeed, but that's not much more information than comment 3 which says buildkernel with -DNO_CLEAN worked). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279403] typedef redeclaration in base include becoming an issue for DTrace
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279403 Michael Dexter changed: What|Removed |Added See Also||https://reviews.freebsd.org ||/D48254 CC||edi...@callfortesting.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279403] typedef redeclaration in base include becoming an issue for DTrace
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279403 Mark Johnston changed: What|Removed |Added See Also|https://reviews.freebsd.org | |/D48254 | --- Comment #2 from Mark Johnston --- D48254 is unrelated. I believe the underlying problem here is that libdtrace wants to be able to parse C headers, and its parser is too simple. For instance, it has trouble with attribute declarations. I worked a bit on it but it doesn't seem easy to solve and I haven't had a chance to go back to it. -- You are receiving this mail because: You are the assignee for the bug.
