malloc: handle to be cleaned chunks the same as regular ones

2023-02-18 Thread Otto Moerbeek
Hi,

these recent sshd double free issue prompted me to look at malloc
again. I have something bigger brewing, but this diff makes sure the
to be cleaned chunks (via freezero() or malloc_conceal) particpate in
the delayed freeing just as others.

-Otto

Index: stdlib/malloc.c
===
RCS file: /home/cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.276
diff -u -p -r1.276 malloc.c
--- stdlib/malloc.c 27 Dec 2022 17:31:09 -  1.276
+++ stdlib/malloc.c 16 Feb 2023 14:11:50 -
@@ -1515,42 +1515,38 @@ ofree(struct dir_info **argpool, void *p
unmap(pool, p, PAGEROUND(sz), clear ? argsz : 0);
delete(pool, r);
} else {
+   void *tmp;
+   u_int i;
+
/* Validate and optionally canary check */
struct chunk_info *info = (struct chunk_info *)r->size;
if (info->size != sz)
wrterror(pool, "internal struct corrupt");
find_chunknum(pool, info, p, mopts.chunk_canaries);
-   if (!clear) {
-   void *tmp;
-   int i;
 
-   if (mopts.malloc_freecheck) {
-   for (i = 0; i <= MALLOC_DELAYED_CHUNK_MASK; i++)
-   if (p == pool->delayed_chunks[i])
-   wrterror(pool,
-   "double free %p", p);
-   }
-   junk_free(pool->malloc_junk, p, sz);
-   i = getrbyte(pool) & MALLOC_DELAYED_CHUNK_MASK;
-   tmp = p;
-   p = pool->delayed_chunks[i];
-   if (tmp == p)
-   wrterror(pool, "double free %p", tmp);
-   pool->delayed_chunks[i] = tmp;
-   if (p != NULL) {
-   r = find(pool, p);
-   REALSIZE(sz, r);
-   if (r != NULL)
-   validate_junk(pool, p, sz);
-   }
-   } else if (argsz > 0) {
-   r = find(pool, p);
-   explicit_bzero(p, argsz);
+   if (mopts.malloc_freecheck) {
+   for (i = 0; i <= MALLOC_DELAYED_CHUNK_MASK; i++)
+   if (p == pool->delayed_chunks[i])
+   wrterror(pool,
+   "double free %p", p);
}
+   if (clear && argsz > 0)
+   explicit_bzero(p, argsz);
+   junk_free(pool->malloc_junk, p, sz);
+
+   i = getrbyte(pool) & MALLOC_DELAYED_CHUNK_MASK;
+   tmp = p;
+   p = pool->delayed_chunks[i];
+   if (tmp == p)
+   wrterror(pool, "double free %p", p);
+   pool->delayed_chunks[i] = tmp;
if (p != NULL) {
+   r = find(pool, p);
if (r == NULL)
wrterror(pool,
"bogus pointer (double free?) %p", p);
+   REALSIZE(sz, r);
+   validate_junk(pool, p, sz);
free_bytes(pool, r, p);
}
}



Re: pinsyscall.2: Add a missing period

2023-02-18 Thread Jason McIntyre
On Sat, Feb 18, 2023 at 08:25:48AM -0500, Josiah Frentsos wrote:
> Index: pinsyscall.2
> ===
> RCS file: /cvs/src/lib/libc/sys/pinsyscall.2,v
> retrieving revision 1.1
> diff -u -p -r1.1 pinsyscall.2
> --- pinsyscall.2  16 Feb 2023 04:43:54 -  1.1
> +++ pinsyscall.2  18 Feb 2023 13:13:39 -
> @@ -54,7 +54,7 @@ that system call must be entered from, a
>  entry instruction to perform the specified
>  .Va syscall
>  from a different address range will deliver
> -Dv SIGABRT .
> +.Dv SIGABRT .
>  .Sh RETURN VALUES
>  .Rv -std
>  .Sh ERRORS
> 

fixed, thanks.
jmc



pinsyscall.2: Add a missing period

2023-02-18 Thread Josiah Frentsos
Index: pinsyscall.2
===
RCS file: /cvs/src/lib/libc/sys/pinsyscall.2,v
retrieving revision 1.1
diff -u -p -r1.1 pinsyscall.2
--- pinsyscall.216 Feb 2023 04:43:54 -  1.1
+++ pinsyscall.218 Feb 2023 13:13:39 -
@@ -54,7 +54,7 @@ that system call must be entered from, a
 entry instruction to perform the specified
 .Va syscall
 from a different address range will deliver
-Dv SIGABRT .
+.Dv SIGABRT .
 .Sh RETURN VALUES
 .Rv -std
 .Sh ERRORS



Re: [xenocara] xenodm.man fix

2023-02-18 Thread Matthieu Herrb
On Sat, Feb 18, 2023 at 12:15:54PM +0300, Mikhail wrote:
> On Sat, Feb 18, 2023 at 08:00:26AM +0100, Matthieu Herrb wrote:
> > On Fri, Feb 17, 2023 at 11:52:44AM +, Laurence Tratt wrote:
> > > On Thu, Feb 16, 2023 at 09:29:53PM +0300, Mikhail wrote:
> > > 
> > > Hello Mikhail,
> > > 
> > > > /etc/X11/xenodm/Xsession file has a check for x bit
> > > 
> > > Yes, this one caught me out a few years back:
> > > 
> > >   https://marc.info/?l=openbsd-bugs=162737223625768=2
> > > 
> > > In subsequent discussions with Matthieu and Theo, I *think* the
> > > eventual thought was that it would be better to get rid of the `-x`
> > > check. I might be misremembering that, though.
> > > 
> > 
> > I'm fine with not runing the script if not executable.  I don't
> > remember exactly why I didn't do it when you brought the issue up in
> > 2021. But I prefer to use the fallback session when the script exists
> > and isn't executable rather than letting the session fail immediatly.
> > 
> > ok?
> 
> It will break setups which people have working now, but what do we get
> in return? Just to be complaint with the docs?
> 

As Klemens and Laurence have mentionned it, the current code
leads to subtle behaviour changes depending on whether the user
.xsession file is executable or not.

It has always been documented that the file needs to be executable, so
people who rely on the undocumented feature need to fix their setups.

I'll add an entry in current.html if I get oks for the diff.
-- 
Matthieu Herrb



Re: [xenocara] xenodm.man fix

2023-02-18 Thread Mikhail
On Sat, Feb 18, 2023 at 08:00:26AM +0100, Matthieu Herrb wrote:
> On Fri, Feb 17, 2023 at 11:52:44AM +, Laurence Tratt wrote:
> > On Thu, Feb 16, 2023 at 09:29:53PM +0300, Mikhail wrote:
> > 
> > Hello Mikhail,
> > 
> > > /etc/X11/xenodm/Xsession file has a check for x bit
> > 
> > Yes, this one caught me out a few years back:
> > 
> >   https://marc.info/?l=openbsd-bugs=162737223625768=2
> > 
> > In subsequent discussions with Matthieu and Theo, I *think* the
> > eventual thought was that it would be better to get rid of the `-x`
> > check. I might be misremembering that, though.
> > 
> 
> I'm fine with not runing the script if not executable.  I don't
> remember exactly why I didn't do it when you brought the issue up in
> 2021. But I prefer to use the fallback session when the script exists
> and isn't executable rather than letting the session fail immediatly.
> 
> ok?

It will break setups which people have working now, but what do we get
in return? Just to be complaint with the docs?



format strings in libexpat

2023-02-18 Thread Miod Vallat
libexpat assumes the compiler might not know of the C99 format
specifiers for ptrdiff_t and size_t, and tries to guess alternative
format strings.

The following diff relieves it of this misery (but can't be sent
upѕtream, as it is too aggressive).

Index: lib/internal.h
===
RCS file: /OpenBSD/src/lib/libexpat/lib/internal.h,v
retrieving revision 1.10
diff -u -p -r1.10 internal.h
--- lib/internal.h  20 Sep 2022 23:00:53 -  1.10
+++ lib/internal.h  18 Feb 2023 08:16:19 -
@@ -105,31 +105,9 @@
 #  endif
 #endif
 
-#include  // ULONG_MAX
-
-#if defined(_WIN32)
\
-&& (! defined(__USE_MINGW_ANSI_STDIO)  
\
-|| (1 - __USE_MINGW_ANSI_STDIO - 1 == 0))
-#  define EXPAT_FMT_ULL(midpart) "%" midpart "I64u"
-#  if defined(_WIN64) // Note: modifiers "td" and "zu" do not work for MinGW
-#define EXPAT_FMT_PTRDIFF_T(midpart) "%" midpart "I64d"
-#define EXPAT_FMT_SIZE_T(midpart) "%" midpart "I64u"
-#  else
-#define EXPAT_FMT_PTRDIFF_T(midpart) "%" midpart "d"
-#define EXPAT_FMT_SIZE_T(midpart) "%" midpart "u"
-#  endif
-#else
-#  define EXPAT_FMT_ULL(midpart) "%" midpart "llu"
-#  if ! defined(ULONG_MAX)
-#error Compiler did not define ULONG_MAX for us
-#  elif ULONG_MAX == 18446744073709551615u // 2^64-1
-#define EXPAT_FMT_PTRDIFF_T(midpart) "%" midpart "ld"
-#define EXPAT_FMT_SIZE_T(midpart) "%" midpart "lu"
-#  else
-#define EXPAT_FMT_PTRDIFF_T(midpart) "%" midpart "d"
-#define EXPAT_FMT_SIZE_T(midpart) "%" midpart "u"
-#  endif
-#endif
+#define EXPAT_FMT_ULL(midpart) "%" midpart "llu"
+#define EXPAT_FMT_PTRDIFF_T(midpart) "%" midpart "td"
+#define EXPAT_FMT_SIZE_T(midpart) "%" midpart "zu"
 
 #ifndef UNUSED_P
 #  define UNUSED_P(p) (void)p