Re: Possibly wrong information in tcpdump/print-domain.c
See below quoted text.
On Sun, Feb 26, 2023 at 03:08:42PM +0100, p...@delphinusdns.org wrote:
> >Synopsis:Possibly wrong information in tcpdump/print-domain.c
> >Category:user
> >Environment:
> System : OpenBSD 7.2
> Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
>
> r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
>
> Architecture: OpenBSD.arm64
> Machine : arm64
> >Description:
> print-domain.c in tcpdump has some bug. In fact it's not really sure
> itself whether to print a label at 32 bytes or 63 bytes. Though according to
> RFC 1034/1035 a label is maximally 63 bytes. There is some sort of EDNS0 mode
> with bitmap lengths that I don't fully understand myself but it's there and
> a crafted packet can give information that is possibly wrongly printed.
>
> In print-domain.c there is function labellen() which maximally gives back a
> labellen of 32 if it's one of these bitmap packets. In function
> blabel_print() the variable lim is maximally 64 but the for loop will print
> maximally 32 bytes in hex (so 64 characters). Let me show you some code:
>
> 109 slen = (bitlen + 3) / 4;
> 110 lim = cp + 1 + slen;
> 111
> 112 /* print the bit string as a hex string */
> 113 printf("\\[x");
> 114 for (bitp = cp + 1, b = bitlen; bitp < lim && b > 7; b -= 8,
> bit
> p++) {
> 115 TCHECK(*bitp);
> 116 printf("%02x", *bitp);
> 117 }
>
>
> Luckily this discrepancy can't be taken further and all it's doing is printing
> possible misinformation in the tcpdump header, if (-X is not used you'll never
> find out though what the true domain was I think).
>
> >How-To-Repeat:
> It looks like this in a specially crafted packet.
>
> 14:49:01.321764 192.168.177.13 > 255.255.255.255: gre [R] 0800 off 0x0
> (rtaf=0x0) 192.168.177.13.59 > 255.255.255.255.53: [no udp cksum] 13352+
> [1au] A?
> \[x3132333435363738393031323334353637383930313233343536373839303132/256].(0)
> (ttl 255, id 0, len 28) (ttl 255, id 0, len 20)
> : 4500 0014 ff2f 4a05 c0a8 b10d E/J.
> 0010: 4000 0800 00e8 @...
> 0020:
> 0030:
> 0040:
> 0050:
> 0060:
> 0070:
> 0080:
> 0090:
> 00a0:
> 00b0:
> 00c0:
> 00d0:
> 00e0:
> 00f0:
> 0100: 4500 001c E...
> 0110: ff11 4a1b c0a8 b10d ..J.
> 0120: 003b 0035 3428 0100 0001 .;.54(..
> 0130: 0001 4100 3132 3334 3536 3738 3930 A.1234567890
> 0140: 3132 3334 3536 3738 3930 3132 3334 3536 1234567890123456
> 0150: 3738 3930 3132 0100 0100 0100 0100 789012..
> 0160: 2904 d000 0080 00 )
>
> If you would like the file that generated this GRE packet with DNS information
> in it, please mail me for it (I can only give it to @openbsd.org addresses).
> >Fix:
> I'm not going to fix this one, but I wanted to call out the bug!
>
>
> dmesg:
> See my other mails for this.
Sundays is not my days or print-domain.c is too complex for me. I retract
this bug report. The only bug here is the variable lim in blabel_print().
I informed myself in the meanwhile on RFC 2673 which was deprecated by
RFC 6891. So this is a deprecated protocol (binary labels). I don't know
if it should linger around still in the code, that's up for you to decide.
Best Regards,
-peter
Re: Minor bug in xcb_connect
Matthieu Herrb writes: > On Tue, Jan 31, 2023 at 10:31:34PM +, cho...@jtan.com wrote: > > If the function implementing xcb_connect is called directly with a > > custom xcb_auth_info_t then checking that the screen in $DISPLAY > > is valid is skipped. > > > > Matthew > > Hi, > > Thank you for this patch. Can you also file a Merge Request to > upstream libxcb project at gitlab.freedesktop.org so that this can get > reviewed by libxcb developpers ? No. You have a patch. You can apply it and fix your bug, or you can not. It's not my problem any more. Matthew
Re: Dell Wyse 3040 acpitz vs tipmic
On Sun, Feb 26, 2023 at 01:28:04PM +0100, Mark Kettenis wrote:
> > Date: Sun, 26 Feb 2023 18:13:18 +1000
> > From: David Gwynne
yeesh, i should have proofread my email before i sent it. sorry about
making it harder to read than it should have been.
> > i picked a couple of Dell Wyse 3040 boxes, which are very cute, i
> > like them a lot. however, i have to disable acpitz to be able to
> > use them because the driver gets stuck during attach.
> >
> > during apcitz_attach does a read of all the temperatures. the read
> > of _TMP ends up talking to tipmic(4) via tipmic_thermal_opreg_handler().
> > tipmic_thermal_opreg_handler has a loop on line 335 waiting for
> > sc->sc_stat_adc to change, but that value is only set from tipmic_intr.
> > acpitz_attach is running while the kernel is code, and it appears that
> > the interrupt handler never runs, so that value never changes, and
> > acpitz blocks. also because it's cold, the timeout on the tsleep doesn't
> > do anything. thanks to patrick for helping me on the acpi side of things
> > so we could figure this out.
>
> A better approach might be to make sure that while we're cold,
> tipmic_thermal_opreg_handler() polls for completion. Something like:
>
> while (sc->sc_stat_adc == 0) {
> if (cold) {
> delay(1000);
> tpmic_intr();
> } else {
> if (tsleep(>sc_stat_adc, PRIBIO, "tipmic",
> SEC_TO_NSEC(1))) {
> ...
> }
> }
> }
>
>
> > i tried deferring basically all of acpitz_attach to when kthreads are
> > running, and that works well enough to get to userland.
> >
> > is that reasonable?
>
> The problem is that you can't really know whether AML accesses the
> opregion while cold.
good point. the diff below works in this situation and is less
intrusive.
> > also, shortly after dwiic complains about short reads and the kernel
> > locks up again. i'll have to plug it in and transcribe the exact
> > errors. i think that's a separate problem though.
>
> Yes, dwiic(4) has always been somewhat problematic. Transactions seem
> to fail randomly on some platforms like the atom system you're looking
> at but also on my Ampere eMAG system.
fun. i managed to catch some of the dwiic stuff via dmesg before
it locked up:
dwiic0: timed out waiting for tx_empty intr
dwiic0: timed out waiting for rx_full intr
dwiic0: timed out reading remaining 1
tipmic0: can't read register 0x5b
dwiic0: timed out waiting for tx_empty intr
dwiic0: timed out reading remaining 1
tipmic0: can't read register 0x01
dwiic0: timed out reading remaining 1
tipmic0: can't read register 0x01
dwiic0: timed out waiting for rx_full intr
dwiic0: timed out reading remaining 1
tipmic0: can't read register 0x5a
dwiic0: timed out waiting for rx_full intr
dwiic0: timed out reading remaining 1
tipmic0: can't read register 0x50
dwiic0: timed out waiting for stop intr
dwiic0: timed out waiting for stop intr
dwiic0: timed out waiting for stop intr
dwiic0: timed out reading remaining 1
tipmic0: can't read register 0x01
dwiic0: timed out waiting for bus idle
dwiic0: timed out waiting for stop intr
dwiic0: timed out waiting for stop intr
dwiic0: timed out waiting for stop intr
dwiic0: timed out waiting for stop intr
dwiic0: timed out waiting for stop intr
dwiic0: timed out reading remaining 1
tipmic0: can't read register 0x01
dwiic0: timed out waiting for bus idle
Index: tipmic.c
===
RCS file: /cvs/src/sys/dev/acpi/tipmic.c,v
retrieving revision 1.7
diff -u -p -r1.7 tipmic.c
--- tipmic.c6 Apr 2022 18:59:27 - 1.7
+++ tipmic.c26 Feb 2023 23:56:04 -
@@ -276,6 +276,25 @@ struct tipmic_regmap tipmic_thermal_regm
{ 0x18, TIPMIC_SYSTEMP_HI, TIPMIC_SYSTEMP_LO }
};
+static int
+tipmic_wait_adc(struct tipmic_softc *sc)
+{
+ int i;
+
+ if (!cold) {
+ return (tsleep_nsec(>sc_stat_adc, PRIBIO, "tipmic",
+ SEC_TO_NSEC(1)));
+ }
+
+ for (i = 0; i < 1000; i++) {
+ delay(1000);
+ if (tipmic_intr(sc) == 1)
+ return (0);
+ }
+
+ return (EWOULDBLOCK);
+}
+
int
tipmic_thermal_opreg_handler(void *cookie, int iodir, uint64_t address,
int size, uint64_t *value)
@@ -333,8 +352,7 @@ tipmic_thermal_opreg_handler(void *cooki
splx(s);
while (sc->sc_stat_adc == 0) {
- if (tsleep_nsec(>sc_stat_adc, PRIBIO, "tipmic",
- SEC_TO_NSEC(1))) {
+ if (tipmic_wait_adc(sc)) {
printf("%s: ADC timeout\n", sc->sc_dev.dv_xname);
break;
}
No console on Macmini2,1
SENDBUG: -*- sendbug -*- SENDBUG: Lines starting with `SENDBUG' will be removed automatically. SENDBUG: SENDBUG: Choose from the following categories: SENDBUG: SENDBUG: system user library documentation kernel alpha aarch64 amd64 arm hppa i386 m88k mips64 mips64el powerpc powerpc64 riscv64 sh sparc64 SENDBUG: SENDBUG: To: bugs@openbsd.org Subject: No console on Macmini2,1 From: r...@adelaide.lan.gadallah.net Cc: lgadal...@gmail.com Reply-To: lgadal...@gmail.com >Synopsis:Was able to boot and install OS using console, but installed OS has no console output >Category:system >Environment: System : OpenBSD 7.2 Details : OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: Installed OpenBSD 7.2 amd64 on an Apple Macmini2,1 Booting from CD-ROM, was able to interact with installer on console normally Once OS was installed, there was no console output The OS works as expected otherwise, network access etc. is all functional >How-To-Repeat: See description >Fix: Unknown SENDBUG: dmesg, pcidump, acpidump and usbdevs are attached. SENDBUG: Feel free to delete or use the -D flag if they contain sensitive information. dmesg: OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1024217088 (976MB) avail mem = 975831040 (930MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (38 entries) bios0: vendor Apple Inc. version "MM21.88Z.009A.B00.0706281359" date 06/28/07 bios0: Apple Inc. Macmini2,1 acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC MCFG ASF! SBST ECDT SSDT SSDT SSDT acpi0: wakeup devices PXS1(S4) PXS2(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB7(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz, 1833.34 MHz, 06-0f-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 2MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 166MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz, 1833.32 MHz, 06-0f-02 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 2MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus 3 (PCIB) acpibtn0 at acpi0: PWRB acpipci0 at acpi0 PCI0: 0x0010 0x0011 0xmemory map conflict 0xe00f8000/0x1000 memory map conflict 0xfed1c000/0x4000 memory map conflict 0xfffb/0x3 asmc0 at acpi0: SMC_ (smc-napa) addr 0x300/0x20: rev 1.19f519, 137 keys acpicmos0 at acpi0 acpicpu0 at acpi0: !C2(500@1 mwait@0x10), C1(1000@1 mwait), PSS acpicpu1 at acpi0: !C2(500@1 mwait@0x10), C1(1000@1 mwait), PSS acpivideo0 at acpi0: GFX0 cpu0: Enhanced SpeedStep 1833 MHz: speeds: 1833, 1667, 1500, 1333, 1000 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03 inteldrm0 at pci0 dev 2 function 0 "Intel 82945GM Video" rev 0x03 drm0 at inteldrm0 intagp0 at inteldrm0 agp0 at intagp0: aperture at 0x4000, size 0x1000 inteldrm0: apic 1 int 16, I945GM, gen 3 vendor "Intel", unknown product 0x27a3 (class DASP subclass Time and Frequency, rev 0x03) at pci0 dev 7 function 0 not configured azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi azalia0: codecs: Sigmatel STAC9220/1 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: msi pci1 at ppb0 bus 1 mskc0 at pci1 dev 0 function 0 "Marvell Yukon 88E8053" rev 0x22, Yukon-2 EC rev. A3 (0x2): apic 1 int 16 msk0 at mskc0 port A: address 00:16:cb:ab:e1:0d eephy0 at msk0 phy 0: 88E Gigabit PHY, rev. 2 ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: msi pci2 at ppb1 bus 2 ath0 at pci2 dev 0 function 0 "Atheros AR5424" rev 0x01: apic 1 int 17 ath0:
Possibly wrong information in tcpdump/print-domain.c
>Synopsis: Possibly wrong information in tcpdump/print-domain.c
>Category: user
>Environment:
System : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
Architecture: OpenBSD.arm64
Machine : arm64
>Description:
print-domain.c in tcpdump has some bug. In fact it's not really sure
itself whether to print a label at 32 bytes or 63 bytes. Though according to
RFC 1034/1035 a label is maximally 63 bytes. There is some sort of EDNS0 mode
with bitmap lengths that I don't fully understand myself but it's there and
a crafted packet can give information that is possibly wrongly printed.
In print-domain.c there is function labellen() which maximally gives back a
labellen of 32 if it's one of these bitmap packets. In function
blabel_print() the variable lim is maximally 64 but the for loop will print
maximally 32 bytes in hex (so 64 characters). Let me show you some code:
109 slen = (bitlen + 3) / 4;
110 lim = cp + 1 + slen;
111
112 /* print the bit string as a hex string */
113 printf("\\[x");
114 for (bitp = cp + 1, b = bitlen; bitp < lim && b > 7; b -= 8, bit
p++) {
115 TCHECK(*bitp);
116 printf("%02x", *bitp);
117 }
Luckily this discrepancy can't be taken further and all it's doing is printing
possible misinformation in the tcpdump header, if (-X is not used you'll never
find out though what the true domain was I think).
>How-To-Repeat:
It looks like this in a specially crafted packet.
14:49:01.321764 192.168.177.13 > 255.255.255.255: gre [R] 0800 off 0x0
(rtaf=0x0) 192.168.177.13.59 > 255.255.255.255.53: [no udp cksum] 13352+ [1au]
A? \[x3132333435363738393031323334353637383930313233343536373839303132/256].(0)
(ttl 255, id 0, len 28) (ttl 255, id 0, len 20)
: 4500 0014 ff2f 4a05 c0a8 b10d E/J.
0010: 4000 0800 00e8 @...
0020:
0030:
0040:
0050:
0060:
0070:
0080:
0090:
00a0:
00b0:
00c0:
00d0:
00e0:
00f0:
0100: 4500 001c E...
0110: ff11 4a1b c0a8 b10d ..J.
0120: 003b 0035 3428 0100 0001 .;.54(..
0130: 0001 4100 3132 3334 3536 3738 3930 A.1234567890
0140: 3132 3334 3536 3738 3930 3132 3334 3536 1234567890123456
0150: 3738 3930 3132 0100 0100 0100 0100 789012..
0160: 2904 d000 0080 00 )
If you would like the file that generated this GRE packet with DNS information
in it, please mail me for it (I can only give it to @openbsd.org addresses).
>Fix:
I'm not going to fix this one, but I wanted to call out the bug!
dmesg:
See my other mails for this.
Re: Dell Wyse 3040 acpitz vs tipmic
> Date: Sun, 26 Feb 2023 18:13:18 +1000
> From: David Gwynne
>
> i picked a couple of Dell Wyse 3040 boxes, which are very cute, i
> like them a lot. however, i have to disable acpitz to be able to
> use them because the driver gets stuck during attach.
>
> during apcitz_attach does a read of all the temperatures. the read
> of _TMP ends up talking to tipmic(4) via tipmic_thermal_opreg_handler().
> tipmic_thermal_opreg_handler has a loop on line 335 waiting for
> sc->sc_stat_adc to change, but that value is only set from tipmic_intr.
> acpitz_attach is running while the kernel is code, and it appears that
> the interrupt handler never runs, so that value never changes, and
> acpitz blocks. also because it's cold, the timeout on the tsleep doesn't
> do anything. thanks to patrick for helping me on the acpi side of things
> so we could figure this out.
A better approach might be to make sure that while we're cold,
tipmic_thermal_opreg_handler() polls for completion. Something like:
while (sc->sc_stat_adc == 0) {
if (cold) {
delay(1000);
tpmic_intr();
} else {
if (tsleep(>sc_stat_adc, PRIBIO, "tipmic",
SEC_TO_NSEC(1))) {
...
}
}
}
> i tried deferring basically all of acpitz_attach to when kthreads are
> running, and that works well enough to get to userland.
>
> is that reasonable?
The problem is that you can't really know whether AML accesses the
opregion while cold.
> also, shortly after dwiic complains about short reads and the kernel
> locks up again. i'll have to plug it in and transcribe the exact
> errors. i think that's a separate problem though.
Yes, dwiic(4) has always been somewhat problematic. Transactions seem
to fail randomly on some platforms like the atom system you're looking
at but also on my Ampere eMAG system.
> OpenBSD 7.2-current (GENERIC.MP) #1071: Wed Feb 22 17:34:56 MST 2023
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 2018418688 (1924MB)
> avail mem = 1937928192 (1848MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7a9f4000 (50 entries)
> bios0: vendor Dell Inc. version "1.2.5" date 08/20/2018
> bios0: Dell Inc. Wyse 3040 Thin Client
> efi0 at bios0: UEFI 2.4
> efi0: American Megatrends rev 0x5000b
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S4 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI SSDT HPET
> SSDT SSDT SSDT LPIT BCFG PRAM CSRT WDAT
> acpi0: wakeup devices
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 480.02 MHz, 06-4c-04
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu0: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line
> 16-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 79MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 480.03 MHz, 06-4c-04
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu1: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line
> 16-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 480.04 MHz, 06-4c-04
> cpu2:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu2: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line
> 16-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 480.07 MHz, 06-4c-04
> cpu3:
>
kernel panic while using random graphical apps
Hi, Lately this machine is freezing while using random graphical applications, the other day happend while doing some scrolling with firefox, today while selecting some tag in a dialog in gbdfed (a little gtk2 application to edit fonts.) I got only this one line message: panic: kernel diagnostic assertion "flags & (M_NOWAIT)" failed: file "/usr/src/sys/kern/kern_malloc.c", line 176 dmesg: OpenBSD 7.2-current (GENERIC.MP) #1075: Fri Feb 24 10:09:47 MST 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4135260160 (3943MB) avail mem = 3990528000 (3805MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xeb920 (70 entries) bios0: vendor Hewlett-Packard version "786E1 v01.16" date 08/17/2011 bios0: Hewlett-Packard HP Compaq dc7700 Convertible Minitower acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET acpi0: wakeup devices PCI0(S4) COM1(S4) PEG1(S4) IGBE(S4) PCX1(S4) PCX2(S4) HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) EUS1(S3) EUS2(S3) PBTN(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz, 1795.57 MHz, 06-0f-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 2MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, C-substates=0.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz, 1795.65 MHz, 06-0f-02 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 2MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xf400, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG1) acpiprt2 at acpi0: bus 32 (PCX1) acpiprt3 at acpi0: bus -1 (PCX2) acpiprt4 at acpi0: bus 7 (HUB_) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 com0 at acpi0 COM1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo "PNP0003" at acpi0 not configured acpibtn0 at acpi0: PBTN "PNP0C14" at acpi0 not configured acpicpu0 at acpi0: C1(@1 halt!), PSS acpicpu1 at acpi0: C1(@1 halt!), PSS cpu0: Enhanced SpeedStep 1795 MHz: speeds: 1800, 1200 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82Q965 Host" rev 0x02 inteldrm0 at pci0 dev 2 function 0 "Intel 82Q965 Video" rev 0x02 drm0 at inteldrm0 intagp0 at inteldrm0 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0: apic 1 int 16, I965G, gen 4 "Intel 82Q965 HECI" rev 0x02 at pci0 dev 3 function 0 not configured em0 at pci0 dev 25 function 0 "Intel ICH8 IGP AMT" rev 0x02: apic 1 int 19, address 00:0f:fe:77:4f:df uhci0 at pci0 dev 26 function 0 "Intel 82801H USB" rev 0x02: apic 1 int 20 uhci1 at pci0 dev 26 function 1 "Intel 82801H USB" rev 0x02: apic 1 int 21 ehci0 at pci0 dev 26 function 7 "Intel 82801H USB" rev 0x02: apic 1 int 22 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 82801H HD Audio" rev 0x02: apic 1 int 21 azalia0: codecs: Realtek ALC262 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 82801H PCIE" rev 0x02 pci1 at ppb0 bus 32 uhci2 at pci0 dev 29 function 0 "Intel 82801H USB" rev 0x02: apic 1 int 20 uhci3 at pci0 dev 29 function 1 "Intel 82801H USB" rev 0x02: apic 1 int 21 ehci1 at pci0 dev 29 function 7 "Intel 82801H USB" rev 0x02: apic 1 int 20 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb1 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xf2 pci2 at ppb1 bus 7 pcib0 at pci0 dev 31 function 0 "Intel 82801HO LPC" rev 0x02 pciide0 at pci0 dev 31 function 2 "Intel 82801H SATA" rev 0x02: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide0: using apic 1 int 18 for native-PCI interrupt wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 usb2 at uhci0: USB revision 1.0 uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb3 at uhci1: USB revision 1.0 uhub3 at usb3
Re: possible underflow (wrap) in tcpdump/print-domain.c
> You also need to have a closer look.
> Line 603 is in
> if (DNS_QR(np)) {
> Line 686 is in the corresponding else block. So there is no way to get
> from 603 into 686 and 690.
>
> --
> :wq Claudio
Arghh, you're right! I'm forever shamed :-(. Good call!
Best Regards,
-peter
Re: possible underflow (wrap) in tcpdump/print-domain.c
On 23-02-26 10:29AM, Peter J. Philipp wrote:
> On Sun, Feb 26, 2023 at 10:17:53AM +0100, Claudio Jeker wrote:
> > On Sun, Feb 26, 2023 at 09:52:43AM +0100, p...@delphinusdns.org wrote:
> > > >Synopsis:possible underflow (wrap) in tcpdump/print-domain.c
> > > >Category:system
> > > >Environment:
> > > System : OpenBSD 7.2
> > > Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
> > >
> > > r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> > >
> > > Architecture: OpenBSD.arm64
> > > Machine : arm64
> > > >Description:
> > > While code reading and giving signedness scrutiny in print-domain.c I
> > > noticed there being opportunity for variables to underflow into the
> > > negative and
> > > thus being positive in testing. Here is a code-snippet of function
> > > ns_print():
> > >
> > > 572 void
> > > 573 ns_print(const u_char *bp, u_int length, int is_mdns)
> > > 574 {
> > > 575 const HEADER *np;
> > > 576 int qdcount, ancount, nscount, arcount;
> > > 577 const u_char *cp;
> > > 578 u_int16_t b2;
> > > 579
> > > 580 np = (const HEADER *)bp;
> > > 581 TCHECK(*np);
> > > 582 /* get the byte-order right */
> > > 583 qdcount = EXTRACT_16BITS(>qdcount);
> > > 584 ancount = EXTRACT_16BITS(>ancount);
> > > 585 nscount = EXTRACT_16BITS(>nscount);
> > > 586 arcount = EXTRACT_16BITS(>arcount);
> > >
> > > notice qdcount,ancount,nscount and arcount can wrap into the negative and
> > > that is being tested like so:
> > >
> > > 603 while (qdcount--) {
> > >
> > > But really what's meant is qdcount-- > 0 as there is no negatives in
> > > here. I
> > > personally don't feel comfortable having tcpdump go deeper into this and
> > > print-domain.c is complex(!!) I can only guess that with this it's
> > > possible
> > > to print domain names that don't exist with this. I just don't feel all
> > > that
> > > comfortable with this, it gives me a bad feeling.
> > > >How-To-Repeat:
> > > code-reading.
> > > >Fix:
> > >
> > > ? tcpdump.patch
> > > Index: print-domain.c
> > > ===
> > > RCS file: /cvs/src/usr.sbin/tcpdump/print-domain.c,v
> > > retrieving revision 1.27
> > > diff -u -p -u -r1.27 print-domain.c
> > > --- print-domain.c24 Jan 2020 22:46:36 - 1.27
> > > +++ print-domain.c26 Feb 2023 08:42:21 -
> > > @@ -600,7 +600,7 @@ ns_print(const u_char *bp, u_int length,
> > > printf(" [%dq]", qdcount);
> > > /* Print QUESTION section on -vv */
> > > cp = (const u_char *)(np + 1);
> > > - while (qdcount--) {
> > > + while (qdcount-- > 0) {
> > > if (qdcount < EXTRACT_16BITS(>qdcount) - 1)
> > > putchar(',');
> > > if (vflag > 1) {
> > > @@ -614,10 +614,10 @@ ns_print(const u_char *bp, u_int length,
> > > }
> > > }
> > > printf(" %d/%d/%d", ancount, nscount, arcount);
> > > - if (ancount--) {
> > > + if (ancount-- > 0) {
> > > if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> > > goto trunc;
> > > - while (cp < snapend && ancount--) {
> > > + while (cp < snapend && ancount-- > 0) {
> > > putchar(',');
> > > if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> > > goto trunc;
> > > @@ -627,11 +627,11 @@ ns_print(const u_char *bp, u_int length,
> > > goto trunc;
> > > /* Print NS and AR sections on -vv */
> > > if (vflag > 1) {
> > > - if (cp < snapend && nscount--) {
> > > + if (cp < snapend && nscount-- > 0) {
> > > printf(" ns:");
> > > if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> > > goto trunc;
> > > - while (cp < snapend && nscount--) {
> > > + while (cp < snapend && nscount-- > 0) {
> > > putchar(',');
> > > if ((cp = ns_rprint(cp, bp, is_mdns))
> > > == NULL)
> > > goto trunc;
> > > @@ -639,11 +639,11 @@ ns_print(const u_char *bp, u_int length,
> > > }
> > > if (nscount > 0)
> > > goto trunc;
> > > - if (cp < snapend && arcount--) {
> > > + if (cp < snapend && arcount-- > 0) {
> > > printf(" ar:");
> > > if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> > >
Re: possible underflow (wrap) in tcpdump/print-domain.c
On Sun, Feb 26, 2023 at 10:29:34AM +0100, Peter J. Philipp wrote:
> On Sun, Feb 26, 2023 at 10:17:53AM +0100, Claudio Jeker wrote:
> > On Sun, Feb 26, 2023 at 09:52:43AM +0100, p...@delphinusdns.org wrote:
> > > >Synopsis:possible underflow (wrap) in tcpdump/print-domain.c
> > > >Category:system
> > > >Environment:
> > > System : OpenBSD 7.2
> > > Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
> > >
> > > r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> > >
> > > Architecture: OpenBSD.arm64
> > > Machine : arm64
> > > >Description:
> > > While code reading and giving signedness scrutiny in print-domain.c I
> > > noticed there being opportunity for variables to underflow into the
> > > negative and
> > > thus being positive in testing. Here is a code-snippet of function
> > > ns_print():
> > >
> > > 572 void
> > > 573 ns_print(const u_char *bp, u_int length, int is_mdns)
> > > 574 {
> > > 575 const HEADER *np;
> > > 576 int qdcount, ancount, nscount, arcount;
> > > 577 const u_char *cp;
> > > 578 u_int16_t b2;
> > > 579
> > > 580 np = (const HEADER *)bp;
> > > 581 TCHECK(*np);
> > > 582 /* get the byte-order right */
> > > 583 qdcount = EXTRACT_16BITS(>qdcount);
> > > 584 ancount = EXTRACT_16BITS(>ancount);
> > > 585 nscount = EXTRACT_16BITS(>nscount);
> > > 586 arcount = EXTRACT_16BITS(>arcount);
> > >
> > > notice qdcount,ancount,nscount and arcount can wrap into the negative and
> > > that is being tested like so:
> > >
> > > 603 while (qdcount--) {
> > >
> > > But really what's meant is qdcount-- > 0 as there is no negatives in
> > > here. I
> > > personally don't feel comfortable having tcpdump go deeper into this and
> > > print-domain.c is complex(!!) I can only guess that with this it's
> > > possible
> > > to print domain names that don't exist with this. I just don't feel all
> > > that
> > > comfortable with this, it gives me a bad feeling.
> > > >How-To-Repeat:
> > > code-reading.
> > > >Fix:
> > >
> > > ? tcpdump.patch
> > > Index: print-domain.c
> > > ===
> > > RCS file: /cvs/src/usr.sbin/tcpdump/print-domain.c,v
> > > retrieving revision 1.27
> > > diff -u -p -u -r1.27 print-domain.c
> > > --- print-domain.c24 Jan 2020 22:46:36 - 1.27
> > > +++ print-domain.c26 Feb 2023 08:42:21 -
> > > @@ -600,7 +600,7 @@ ns_print(const u_char *bp, u_int length,
> > > printf(" [%dq]", qdcount);
> > > /* Print QUESTION section on -vv */
> > > cp = (const u_char *)(np + 1);
> > > - while (qdcount--) {
> > > + while (qdcount-- > 0) {
> > > if (qdcount < EXTRACT_16BITS(>qdcount) - 1)
> > > putchar(',');
> > > if (vflag > 1) {
> > > @@ -614,10 +614,10 @@ ns_print(const u_char *bp, u_int length,
> > > }
> > > }
> > > printf(" %d/%d/%d", ancount, nscount, arcount);
> > > - if (ancount--) {
> > > + if (ancount-- > 0) {
> > > if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> > > goto trunc;
> > > - while (cp < snapend && ancount--) {
> > > + while (cp < snapend && ancount-- > 0) {
> > > putchar(',');
> > > if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> > > goto trunc;
> > > @@ -627,11 +627,11 @@ ns_print(const u_char *bp, u_int length,
> > > goto trunc;
> > > /* Print NS and AR sections on -vv */
> > > if (vflag > 1) {
> > > - if (cp < snapend && nscount--) {
> > > + if (cp < snapend && nscount-- > 0) {
> > > printf(" ns:");
> > > if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> > > goto trunc;
> > > - while (cp < snapend && nscount--) {
> > > + while (cp < snapend && nscount-- > 0) {
> > > putchar(',');
> > > if ((cp = ns_rprint(cp, bp, is_mdns))
> > > == NULL)
> > > goto trunc;
> > > @@ -639,11 +639,11 @@ ns_print(const u_char *bp, u_int length,
> > > }
> > > if (nscount > 0)
> > > goto trunc;
> > > - if (cp < snapend && arcount--) {
> > > + if (cp < snapend && arcount-- > 0) {
> > > printf(" ar:");
> > > if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
>
Re: possible underflow (wrap) in tcpdump/print-domain.c
On Sun, Feb 26, 2023 at 10:17:53AM +0100, Claudio Jeker wrote:
> On Sun, Feb 26, 2023 at 09:52:43AM +0100, p...@delphinusdns.org wrote:
> > >Synopsis: possible underflow (wrap) in tcpdump/print-domain.c
> > >Category: system
> > >Environment:
> > System : OpenBSD 7.2
> > Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
> >
> > r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.arm64
> > Machine : arm64
> > >Description:
> > While code reading and giving signedness scrutiny in print-domain.c I
> > noticed there being opportunity for variables to underflow into the
> > negative and
> > thus being positive in testing. Here is a code-snippet of function
> > ns_print():
> >
> > 572 void
> > 573 ns_print(const u_char *bp, u_int length, int is_mdns)
> > 574 {
> > 575 const HEADER *np;
> > 576 int qdcount, ancount, nscount, arcount;
> > 577 const u_char *cp;
> > 578 u_int16_t b2;
> > 579
> > 580 np = (const HEADER *)bp;
> > 581 TCHECK(*np);
> > 582 /* get the byte-order right */
> > 583 qdcount = EXTRACT_16BITS(>qdcount);
> > 584 ancount = EXTRACT_16BITS(>ancount);
> > 585 nscount = EXTRACT_16BITS(>nscount);
> > 586 arcount = EXTRACT_16BITS(>arcount);
> >
> > notice qdcount,ancount,nscount and arcount can wrap into the negative and
> > that is being tested like so:
> >
> > 603 while (qdcount--) {
> >
> > But really what's meant is qdcount-- > 0 as there is no negatives in here.
> > I
> > personally don't feel comfortable having tcpdump go deeper into this and
> > print-domain.c is complex(!!) I can only guess that with this it's possible
> > to print domain names that don't exist with this. I just don't feel all
> > that
> > comfortable with this, it gives me a bad feeling.
> > >How-To-Repeat:
> > code-reading.
> > >Fix:
> >
> > ? tcpdump.patch
> > Index: print-domain.c
> > ===
> > RCS file: /cvs/src/usr.sbin/tcpdump/print-domain.c,v
> > retrieving revision 1.27
> > diff -u -p -u -r1.27 print-domain.c
> > --- print-domain.c 24 Jan 2020 22:46:36 - 1.27
> > +++ print-domain.c 26 Feb 2023 08:42:21 -
> > @@ -600,7 +600,7 @@ ns_print(const u_char *bp, u_int length,
> > printf(" [%dq]", qdcount);
> > /* Print QUESTION section on -vv */
> > cp = (const u_char *)(np + 1);
> > - while (qdcount--) {
> > + while (qdcount-- > 0) {
> > if (qdcount < EXTRACT_16BITS(>qdcount) - 1)
> > putchar(',');
> > if (vflag > 1) {
> > @@ -614,10 +614,10 @@ ns_print(const u_char *bp, u_int length,
> > }
> > }
> > printf(" %d/%d/%d", ancount, nscount, arcount);
> > - if (ancount--) {
> > + if (ancount-- > 0) {
> > if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> > goto trunc;
> > - while (cp < snapend && ancount--) {
> > + while (cp < snapend && ancount-- > 0) {
> > putchar(',');
> > if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> > goto trunc;
> > @@ -627,11 +627,11 @@ ns_print(const u_char *bp, u_int length,
> > goto trunc;
> > /* Print NS and AR sections on -vv */
> > if (vflag > 1) {
> > - if (cp < snapend && nscount--) {
> > + if (cp < snapend && nscount-- > 0) {
> > printf(" ns:");
> > if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> > goto trunc;
> > - while (cp < snapend && nscount--) {
> > + while (cp < snapend && nscount-- > 0) {
> > putchar(',');
> > if ((cp = ns_rprint(cp, bp, is_mdns))
> > == NULL)
> > goto trunc;
> > @@ -639,11 +639,11 @@ ns_print(const u_char *bp, u_int length,
> > }
> > if (nscount > 0)
> > goto trunc;
> > - if (cp < snapend && arcount--) {
> > + if (cp < snapend && arcount-- > 0) {
> > printf(" ar:");
> > if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> > goto trunc;
> > - while (cp < snapend && arcount--) {
> > + while (cp < snapend && arcount-- > 0) {
> >
Re: possible underflow (wrap) in tcpdump/print-domain.c
On Sun, Feb 26, 2023 at 09:52:43AM +0100, p...@delphinusdns.org wrote:
> >Synopsis:possible underflow (wrap) in tcpdump/print-domain.c
> >Category:system
> >Environment:
> System : OpenBSD 7.2
> Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
>
> r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
>
> Architecture: OpenBSD.arm64
> Machine : arm64
> >Description:
> While code reading and giving signedness scrutiny in print-domain.c I
> noticed there being opportunity for variables to underflow into the negative
> and
> thus being positive in testing. Here is a code-snippet of function
> ns_print():
>
> 572 void
> 573 ns_print(const u_char *bp, u_int length, int is_mdns)
> 574 {
> 575 const HEADER *np;
> 576 int qdcount, ancount, nscount, arcount;
> 577 const u_char *cp;
> 578 u_int16_t b2;
> 579
> 580 np = (const HEADER *)bp;
> 581 TCHECK(*np);
> 582 /* get the byte-order right */
> 583 qdcount = EXTRACT_16BITS(>qdcount);
> 584 ancount = EXTRACT_16BITS(>ancount);
> 585 nscount = EXTRACT_16BITS(>nscount);
> 586 arcount = EXTRACT_16BITS(>arcount);
>
> notice qdcount,ancount,nscount and arcount can wrap into the negative and
> that is being tested like so:
>
> 603 while (qdcount--) {
>
> But really what's meant is qdcount-- > 0 as there is no negatives in here. I
> personally don't feel comfortable having tcpdump go deeper into this and
> print-domain.c is complex(!!) I can only guess that with this it's possible
> to print domain names that don't exist with this. I just don't feel all that
> comfortable with this, it gives me a bad feeling.
> >How-To-Repeat:
> code-reading.
> >Fix:
>
> ? tcpdump.patch
> Index: print-domain.c
> ===
> RCS file: /cvs/src/usr.sbin/tcpdump/print-domain.c,v
> retrieving revision 1.27
> diff -u -p -u -r1.27 print-domain.c
> --- print-domain.c24 Jan 2020 22:46:36 - 1.27
> +++ print-domain.c26 Feb 2023 08:42:21 -
> @@ -600,7 +600,7 @@ ns_print(const u_char *bp, u_int length,
> printf(" [%dq]", qdcount);
> /* Print QUESTION section on -vv */
> cp = (const u_char *)(np + 1);
> - while (qdcount--) {
> + while (qdcount-- > 0) {
> if (qdcount < EXTRACT_16BITS(>qdcount) - 1)
> putchar(',');
> if (vflag > 1) {
> @@ -614,10 +614,10 @@ ns_print(const u_char *bp, u_int length,
> }
> }
> printf(" %d/%d/%d", ancount, nscount, arcount);
> - if (ancount--) {
> + if (ancount-- > 0) {
> if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> goto trunc;
> - while (cp < snapend && ancount--) {
> + while (cp < snapend && ancount-- > 0) {
> putchar(',');
> if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> goto trunc;
> @@ -627,11 +627,11 @@ ns_print(const u_char *bp, u_int length,
> goto trunc;
> /* Print NS and AR sections on -vv */
> if (vflag > 1) {
> - if (cp < snapend && nscount--) {
> + if (cp < snapend && nscount-- > 0) {
> printf(" ns:");
> if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> goto trunc;
> - while (cp < snapend && nscount--) {
> + while (cp < snapend && nscount-- > 0) {
> putchar(',');
> if ((cp = ns_rprint(cp, bp, is_mdns))
> == NULL)
> goto trunc;
> @@ -639,11 +639,11 @@ ns_print(const u_char *bp, u_int length,
> }
> if (nscount > 0)
> goto trunc;
> - if (cp < snapend && arcount--) {
> + if (cp < snapend && arcount-- > 0) {
> printf(" ar:");
> if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> goto trunc;
> - while (cp < snapend && arcount--) {
> + while (cp < snapend && arcount-- > 0) {
> putchar(',');
> if ((cp = ns_rprint(cp, bp, is_mdns))
> == NULL)
>
possible underflow (wrap) in tcpdump/print-domain.c
>Synopsis: possible underflow (wrap) in tcpdump/print-domain.c
>Category: system
>Environment:
System : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
Architecture: OpenBSD.arm64
Machine : arm64
>Description:
While code reading and giving signedness scrutiny in print-domain.c I
noticed there being opportunity for variables to underflow into the negative and
thus being positive in testing. Here is a code-snippet of function
ns_print():
572 void
573 ns_print(const u_char *bp, u_int length, int is_mdns)
574 {
575 const HEADER *np;
576 int qdcount, ancount, nscount, arcount;
577 const u_char *cp;
578 u_int16_t b2;
579
580 np = (const HEADER *)bp;
581 TCHECK(*np);
582 /* get the byte-order right */
583 qdcount = EXTRACT_16BITS(>qdcount);
584 ancount = EXTRACT_16BITS(>ancount);
585 nscount = EXTRACT_16BITS(>nscount);
586 arcount = EXTRACT_16BITS(>arcount);
notice qdcount,ancount,nscount and arcount can wrap into the negative and
that is being tested like so:
603 while (qdcount--) {
But really what's meant is qdcount-- > 0 as there is no negatives in here. I
personally don't feel comfortable having tcpdump go deeper into this and
print-domain.c is complex(!!) I can only guess that with this it's possible
to print domain names that don't exist with this. I just don't feel all that
comfortable with this, it gives me a bad feeling.
>How-To-Repeat:
code-reading.
>Fix:
? tcpdump.patch
Index: print-domain.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-domain.c,v
retrieving revision 1.27
diff -u -p -u -r1.27 print-domain.c
--- print-domain.c 24 Jan 2020 22:46:36 - 1.27
+++ print-domain.c 26 Feb 2023 08:42:21 -
@@ -600,7 +600,7 @@ ns_print(const u_char *bp, u_int length,
printf(" [%dq]", qdcount);
/* Print QUESTION section on -vv */
cp = (const u_char *)(np + 1);
- while (qdcount--) {
+ while (qdcount-- > 0) {
if (qdcount < EXTRACT_16BITS(>qdcount) - 1)
putchar(',');
if (vflag > 1) {
@@ -614,10 +614,10 @@ ns_print(const u_char *bp, u_int length,
}
}
printf(" %d/%d/%d", ancount, nscount, arcount);
- if (ancount--) {
+ if (ancount-- > 0) {
if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
goto trunc;
- while (cp < snapend && ancount--) {
+ while (cp < snapend && ancount-- > 0) {
putchar(',');
if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
goto trunc;
@@ -627,11 +627,11 @@ ns_print(const u_char *bp, u_int length,
goto trunc;
/* Print NS and AR sections on -vv */
if (vflag > 1) {
- if (cp < snapend && nscount--) {
+ if (cp < snapend && nscount-- > 0) {
printf(" ns:");
if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
goto trunc;
- while (cp < snapend && nscount--) {
+ while (cp < snapend && nscount-- > 0) {
putchar(',');
if ((cp = ns_rprint(cp, bp, is_mdns))
== NULL)
goto trunc;
@@ -639,11 +639,11 @@ ns_print(const u_char *bp, u_int length,
}
if (nscount > 0)
goto trunc;
- if (cp < snapend && arcount--) {
+ if (cp < snapend && arcount-- > 0) {
printf(" ar:");
if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
goto trunc;
- while (cp < snapend && arcount--) {
+ while (cp < snapend && arcount-- > 0) {
putchar(',');
if ((cp = ns_rprint(cp, bp, is_mdns))
== NULL)
goto trunc;
@@ -666,28 +666,28 @@ ns_print(const u_char *bp, u_int length,
printf(" [b2&3=0x%x]", b2);
if (DNS_OPCODE(np) ==
Dell Wyse 3040 acpitz vs tipmic
i picked a couple of Dell Wyse 3040 boxes, which are very cute, i like them a lot. however, i have to disable acpitz to be able to use them because the driver gets stuck during attach. during apcitz_attach does a read of all the temperatures. the read of _TMP ends up talking to tipmic(4) via tipmic_thermal_opreg_handler(). tipmic_thermal_opreg_handler has a loop on line 335 waiting for sc->sc_stat_adc to change, but that value is only set from tipmic_intr. acpitz_attach is running while the kernel is code, and it appears that the interrupt handler never runs, so that value never changes, and acpitz blocks. also because it's cold, the timeout on the tsleep doesn't do anything. thanks to patrick for helping me on the acpi side of things so we could figure this out. i tried deferring basically all of acpitz_attach to when kthreads are running, and that works well enough to get to userland. is that reasonable? also, shortly after dwiic complains about short reads and the kernel locks up again. i'll have to plug it in and transcribe the exact errors. i think that's a separate problem though. OpenBSD 7.2-current (GENERIC.MP) #1071: Wed Feb 22 17:34:56 MST 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2018418688 (1924MB) avail mem = 1937928192 (1848MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7a9f4000 (50 entries) bios0: vendor Dell Inc. version "1.2.5" date 08/20/2018 bios0: Dell Inc. Wyse 3040 Thin Client efi0 at bios0: UEFI 2.4 efi0: American Megatrends rev 0x5000b acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI SSDT HPET SSDT SSDT SSDT LPIT BCFG PRAM CSRT WDAT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 480.02 MHz, 06-4c-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 79MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 480.03 MHz, 06-4c-04 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 480.04 MHz, 06-4c-04 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu2: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 480.07 MHz, 06-4c-04 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu3: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus -1 (RP02) acpiprt3 at acpi0: bus -1 (RP03) acpiprt4 at acpi0: bus -1 (RP04) "INT33A4" at acpi0 not configured dwiic0 at acpi0 I2C7 addr 0x9151e000/0x1000 irq 38 iic0 at dwiic0 chvgpio0 at acpi0 GPO1 uid 2 addr 0xfed88000/0x8000 irq 48, 59 pins tipmic0 at iic0 addr 0x5e gpio 15 acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 com0 at acpi0 IURT
