[Bug 277855] Wrong signatures for wide character string functions

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277855

--- Comment #1 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=69d5783ae81b74295118950d01b6dddb3e504a56

commit 69d5783ae81b74295118950d01b6dddb3e504a56
Author: Konstantin Belousov 
AuthorDate: 2024-03-21 08:38:05 +
Commit: Konstantin Belousov 
CommitDate: 2024-03-21 08:40:08 +

wmemchr(3): fix prototypes for wcpcpy() and wcpncpy()

PR: 277855
Reported by:Paul Floyd 
Sponsored by:   The FreeBSD Foundation
MFC after:  3 days

 lib/libc/string/wmemchr.3 | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277861] corrupt ELF file can crash llvm-objdump in printSymbolVersionDefinition()

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277861

Bug ID: 277861
   Summary: corrupt ELF file can crash llvm-objdump in
printSymbolVersionDefinition()
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: r...@lcs.mit.edu

Created attachment 249368
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249368&action=edit
broken ELF file that crashes llvm-objdump in printSymbolVersionDefinition()

This line in printSymbolVersionDefinition() in
llvm-project/llvm/tools/llvm-objdump/ELFDump.cpp forms a pointer using
a value pulled from the ELF file (vd_aux) without a sanity check:

const uint8_t *BufAux = Buf + Verdef->vd_aux;

It may be that the subsequent uses of vda_next and vd_next have a
similar problem.

I've attached an ELF file that crashes objdump due to a huge vd_aux:

# freebsd-version
15.0-CURRENT
# objdump --version
LLVM (http://llvm.org/):
  LLVM version 17.0.6
  Optimized build with assertions.
..
# objdump -p objdump2a.exe

objdump2a.exe:  file format elf32-lanai

Program Header:
objdump: warning: 'objdump2a.exe': section [index 7] has invalid sh_entsize:
expected 8, but got 5

Version definitions:
1 0x00 0x7650bc00 PLEASE submit a bug report to
https://bugs.freebsd.org/submit/ and include the crash backtrace.
Stack dump:
0.  Program arguments: objdump -p objdump2a.exe
 #0 0x01230c41 PrintStackTrace
/usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:602:13
 #1 0x0122f0b5 RunSignalHandlers
/usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:105:18
 #2 0x01231365 SignalHandler
/usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3
 #3 0x0008255ae5ff handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3
 #4 0x0008255adbbb thr_sighandler
/usr/src/lib/libthr/thread/thr_sig.c:244:1
 #5 0x0008223cd2d3 ([vdso]+0x2d3)
 #6 0x00de60d7 read
/usr/src/contrib/llvm-project/llvm/include/llvm/Support/Endian.h:66:3
 #7 0x00de60d7 read
/usr/src/contrib/llvm-project/llvm/include/llvm/Support/Endian.h:77:10
 #8 0x00de60d7 operator unsigned int
/usr/src/contrib/llvm-project/llvm/include/llvm/Support/Endian.h:216:12
 #9 0x00de60d7
printSymbolVersionDefinition >
/usr/src/contrib/llvm-project/llvm/tools/llvm-objdump/ELFDump.cpp:398:45
#10 0x00de60d7 printSymbolVersion
/usr/src/contrib/llvm-project/llvm/tools/llvm-objdump/ELFDump.cpp:425:7
#11 0x00de60d7 printPrivateHeaders
/usr/src/contrib/llvm-project/llvm/tools/llvm-objdump/ELFDump.cpp:432:3
#12 0x00e6a13c dumpObject
/usr/src/contrib/llvm-project/llvm/tools/llvm-objdump/llvm-objdump.cpp:2815:7
#13 0x00e654b0 dumpInput
/usr/src/contrib/llvm-project/llvm/tools/llvm-objdump/llvm-objdump.cpp:0:5
#14 0x00e654b0
for_each, std::__1::allocator > *>, void
(*)(llvm::StringRef)>
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/__algorithm/for_each.h:26:5
#15 0x00e654b0 for_each, std::__1::allocator >,
std::__1::allocator,
std::__1::allocator > > > &, void (*)(llvm::StringRef)>
/usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLExtras.h:1731:10
#16 0x00e654b0 main
/usr/src/contrib/llvm-project/llvm/tools/llvm-objdump/llvm-objdump.cpp:3248:3
#17 0x000828d4d0aa __libc_start1 /usr/src/lib/libc/csu/libc_start1.c:157:2
Segmentation fault (core dumped)

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277862] potential out-of-bounds in llvm-objdump in OffloadBinary::create()

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277862

Bug ID: 277862
   Summary: potential out-of-bounds in llvm-objdump in
OffloadBinary::create()
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: r...@lcs.mit.edu

Created attachment 249370
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249370&action=edit
broken ELF file that causes llvm-objdump to crash in OffloadBinary::create()

In this code in OffloadBinary::create() in
llvm-project/llvm/lib/Object/OffloadBinary.cpp:

  if (... ||
  TheHeader->EntryOffset > TheHeader->Size - sizeof(Entry) ||

if Size < sizeof(Entry), the subtraction will wrap, and a huge
EntryOffset won't be rejected. Then this array reference can generate
an out-of-bounds memory reference:

  const Entry *TheEntry =
  reinterpret_cast(&Start[TheHeader->EntryOffset]);

I've attached a demonstration:

# freebsd-version
15.0-CURRENT
# objdump --version
LLVM (http://llvm.org/):
  LLVM version 17.0.6
  Optimized build with assertions.
..
# objdump -s objdump1c.exe
PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the
crash backtrace.
Stack dump:
0.  Program arguments: objdump -s objdump1c.exe
 #0 0x01230c41 PrintStackTrace
/usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:602:13
 #1 0x0122f0b5 RunSignalHandlers
/usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:105:18
 #2 0x01231365 SignalHandler
/usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3
 #3 0x000824b055ff handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3
 #4 0x000824b04bbb thr_sighandler
/usr/src/lib/libthr/thread/thr_sig.c:244:1
 #5 0x0008225332d3 ([vdso]+0x2d3)
 #6 0x01174709 create
/usr/src/contrib/llvm-project/llvm/lib/Object/OffloadBinary.cpp:199:29
 #7 0x00f7e328 createBinary
/usr/src/contrib/llvm-project/llvm/lib/Object/Binary.cpp:0:12
 #8 0x00f7e42a operator bool
/usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:559:17
 #9 0x00f7e42a createBinary
/usr/src/contrib/llvm-project/llvm/lib/Object/Binary.cpp:113:8
#10 0x00e65321 operator bool
/usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:559:17
#11 0x00e65321
unwrapOrError, llvm::StringRef
&> /usr/src/contrib/llvm-project/llvm/tools/llvm-objdump/llvm-objdump.h:126:7
#12 0x00e65321 dumpInput
/usr/src/contrib/llvm-project/llvm/tools/llvm-objdump/llvm-objdump.cpp:2913:34
#13 0x00e65321
for_each, std::__1::allocator > *>, void
(*)(llvm::StringRef)>
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/__algorithm/for_each.h:26:5
#14 0x00e65321 for_each, std::__1::allocator >,
std::__1::allocator,
std::__1::allocator > > > &, void (*)(llvm::StringRef)>
/usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLExtras.h:1731:10
#15 0x00e65321 main
/usr/src/contrib/llvm-project/llvm/tools/llvm-objdump/llvm-objdump.cpp:3248:3
#16 0x0008281480aa __libc_start1 /usr/src/lib/libc/csu/libc_start1.c:157:2
Segmentation fault (core dumped)

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277863] Possible regression in mktime(3)

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277863

Bug ID: 277863
   Summary: Possible regression in mktime(3)
   Product: Base System
   Version: 14.0-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: misc
  Assignee: b...@freebsd.org
  Reporter: nson...@outlook.com
 Attachment #249371 text/plain
 mime type:

Created attachment 249371
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249371&action=edit
Code that triggers the mktime bug

The following works on FreeBSD 13.0-RELEASE amd64 but fails on 14.0-RELEASE
amd64 (code included as an attachment):

   #
   # freebsd-version
   13.0-RELEASE
   #
   # uname -m
   amd64
   #
   # cat mktime_bug.c
   #include 
   #include 
   #include 
   #include 
   #include 
   #include 
   #include 

   int
   main(void)
   {
struct tm time_buf = {
.tm_sec = 0,
.tm_min = 0,
.tm_hour = 0,
.tm_mday = 1,
.tm_mon = 0,
.tm_year = 69,
.tm_wday = 3,
.tm_yday = 0,
.tm_isdst = 0,
.tm_zone = "CET",
};

errno = 0;
time_t const unix_time = mktime(&time_buf);
if (errno)
err(EX_DATAERR, "mktime failed");

printf("Unix time is: %ld\n", unix_time);

return 0;
   }
   #
   # cc -g -O0 -o mktime_bug mktime_bug.c
   # ./mktime_bug
   Unix time is: -31539600
   #



Whereas on 14.0-RELEASE:

   $ freebsd-version
   14.0-RELEASE-p5
   $ 
   $ uname -m
   amd64
   $ 
   $ cc -g -O0 -o mktime_bug mktime_bug.c
   $ ./mktime_bug
   mktime_bug: mktime failed: Value too large to be stored in data type
   $ 


Note that the requested year is 1969 - the bug is possibly related to this
fact. This might be a regression due to a version bump of tzcode.

This bug was discovered due to a test failure in schilytools at
https://codeberg.org/schilytools/schilytools/issues/66.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277863] Possible regression in mktime(3)

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277863

Nico Sonack  changed:

   What|Removed |Added

URL||https://codeberg.org/schily
   ||tools/schilytools/issues/66
 CC||f...@freebsd.org,
   ||nson...@outlook.com

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277837] coredirector: Intel Thread Director / Hardware Feedback Interface new driver [patch]

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277837

Koine Yuusuke  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|New |Closed

--- Comment #9 from Koine Yuusuke  ---
(In reply to Gleb Smirnoff from comment #8)
> Thanks a lot for your submission! Indeed, new driver submissions
> fit much better into the FreeBSD review system, rather than into
> the bug database. Can you please file your patch queue at:
>   https://reviews.freebsd.org/differential/

Thank you very much for your advice!

I posted the patches on the review site below.

  - https://reviews.freebsd.org/D44453
  - https://reviews.freebsd.org/D44454
  - https://reviews.freebsd.org/D44455
  - https://reviews.freebsd.org/D44456
  - https://reviews.freebsd.org/D44457
  - https://reviews.freebsd.org/D44458
  - https://reviews.freebsd.org/D44459

>From now on, I will proceed with the review site, so this will be closed.

Best regards.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 248352] mfi(4): Remove RAID map sync functionality

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248352

Dan Mahoney  changed:

   What|Removed |Added

 CC||free...@gushi.org

--- Comment #8 from Dan Mahoney  ---
Just a note that when my raid card (Perc H330) started throwing errors on
startup with the error:

Disabling writes to flash as the flash part has gone bad.
Please contact technical support to resolve this issue.
Please press 'Y' to continue.

Dell pointed me at this bug.  We're internally moving everything we have over
to the mrsas driver, but this really should be looked at, or maybe mrsas made
the default.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277863] Possible regression in mktime(3)

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277863

Dennis Clarke  changed:

   What|Removed |Added

 CC||dcla...@blastwave.org

--- Comment #1 from Dennis Clarke  ---

I can confirm this is a bug even in 13.3-RELEASE : 

callisto$ 
callisto$ ./foo
foo: mktime failed: Value too large to be stored in data type
callisto$ uname -apKU 
FreeBSD callisto 13.3-RELEASE FreeBSD 13.3-RELEASE
releng/13.3-n257428-80d2b634ddf0 GENERIC amd64 amd64 1303001 1303001
callisto$ 

Dennis Clarke

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277863] Possible regression in mktime(3)

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277863

--- Comment #2 from Dennis Clarke  ---

We verified that it seems to work jusrt fine in a 13.0 and 13.1 jail : 

root@:~ # freebsd-version -ru 
14.0-RELEASE-p5
13.1-RELEASE
root@:~ # ./foo
Unix time is: -31536000
root@:~ #

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277863] Possible regression in mktime(3)

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277863

--- Comment #3 from Dennis Clarke  ---

Seems the breakage is somewhere between 13.1 and 13.2 : 

root@:~ # cc -g -O0 -o foo foo.c 
root@:~ # 
root@:~ # ./foo
foo: mktime failed: Value too large to be stored in data type

root@:~ # freebsd-version -ru 
14.0-RELEASE-p5
13.2-RELEASE
root@:~ #

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277863] Possible regression in mktime(3)

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277863

John F. Carr  changed:

   What|Removed |Added

 CC||j...@mit.edu

--- Comment #4 from John F. Carr  ---
Stepping through mktime, I see a binary search in the range INT_MIN to INT_MAX
seconds that fails because time -4611686018427387904 seconds does not convert
cleanly to a 32 bit year number when using 32 bit intermediate variables.  In
this code y = -109624180.

if (ckd_add(&tmp->tm_year, y, -TM_YEAR_BASE)) {
  errno = EOVERFLOW;
  return NULL;
}

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277863] Possible regression in mktime(3)

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277863

--- Comment #5 from John F. Carr  ---
I meant LONG_MIN and LONG_MAX.  64 bits signed, not 32 bits signed.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 193925] CPU-frequeny scaling does not work on FSC Futro S400 thin-client

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193925

daquone wright  changed:

   What|Removed |Added

 CC||quanwright...@gmail.com

--- Comment #5 from daquone wright  ---
Comment on attachment 147671
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147671
gzipped disassembled DSDT-table from FSC Futro S400 thin-client

[52332:22872:2024-3-17 12:31:42.74] Main Start
[52332:22872:2024-3-17 12:31:42.74] Command
line:"C:\Users\Owner\Downloads\Zoom_cm_fnnnZ9vvrZo4_mmFs1P5H833tg+msZvUi4Vw6NVVOML94HoWo@wTiaF97Sl1H35nVV_k70b362096132bc93_.exe"
 Instance:0x36 Show State:1
[52332:22872:2024-3-17 12:31:42.578] C:\
[52332:22872:2024-3-17 12:31:42.633] Main End

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 193925] CPU-frequeny scaling does not work on FSC Futro S400 thin-client

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193925

--- Comment #6 from daquone wright  ---
0150b067a4c39dc75e712d6052339a6e850cfa5344ebe446

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 193925] CPU-frequeny scaling does not work on FSC Futro S400 thin-client

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193925

--- Comment #7 from daquone wright  ---
Created attachment 249383
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249383&action=edit
bugs

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277875] pfctl cowardly refuses to load rules, broken between 8c94ed992702 & f29af8618bf9

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277875

Bug ID: 277875
   Summary: pfctl cowardly refuses to load rules, broken between
8c94ed992702 & f29af8618bf9
   Product: Base System
   Version: 15.0-CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: d...@freebsd.org
 Attachment #249387 text/plain
 mime type:

Created attachment 249387
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249387&action=edit
abridged pf.conf

after 8c94ed992702, servers behind firewall are unable to ping, dns, etc.

I think this is because `pfctl -vvef /etc/pf.conf` returns 1,
and whines about ALTQ even though we're not using any ALTQ function.

Removing dummynet config doesn't seem to address the issue.

Reverting to last boot env built off f29af8618bf9 and all is well.

- abridged pf.conf attached, full one available as needed.
- h/w is ten64 arm64 router running 15.0-CURRENT.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277875] pfctl cowardly refuses to load rules, broken between 8c94ed992702 & f29af8618bf9

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277875

--- Comment #1 from Dave Cottlehuber  ---
Created attachment 249388
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249388&action=edit
codel config

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277875] pfctl cowardly refuses to load rules, broken between 8c94ed992702 & f29af8618bf9

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277875

Mina Galić  changed:

   What|Removed |Added

 CC||free...@igalic.co
   Assignee|b...@freebsd.org|n...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277863] Possible regression in mktime(3)

2024-03-21 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277863

Brennen Murphy  changed:

   What|Removed |Added

 CC||brennenmu...@pm.me

--- Comment #6 from Brennen Murphy  ---

(QEMU FreeBSD 14.0-RELEASE Test not actual hardware)

Big Endian

root@freebsd14_ppc64:~ # ./foo
Unix time is: -31518000
root@freebsd14_ppc64:~ # 


Little Endian

root@freebsd14_ppc64le:~ # ./foo
foo: mktime failed: Value too large to be stored in data type
root@freebsd14_ppc64le:~ #

-- 
You are receiving this mail because:
You are the assignee for the bug.