Re: net/pfvar.h: MAXPATHLEN -> PATH_MAX
Hello,
On Tue, Oct 13, 2020 at 10:31:28PM +0200, Christian Weisgerber wrote:
> In revision 1.407 of , deraadt@ replaced MAXPATHLEN
> with PATH_MAX so userland wouldn't have to pull in .
>
> In 1.466, sashan@ accidentally slipped one MAXPATHLEN back in,
> because its use is ubiquitous on the kernel side of pf. Switch
> this over to PATH_MAX again.
>
> pfctl(8) doesn't actually use this, so it's very cosmetic.
fine with me. and sorry for inconveniences.
OK sashan
>
> Index: sys/net/pfvar.h
> ===
> RCS file: /cvs/src/sys/net/pfvar.h,v
> retrieving revision 1.496
> diff -u -p -r1.496 pfvar.h
> --- sys/net/pfvar.h 24 Aug 2020 15:30:58 - 1.496
> +++ sys/net/pfvar.h 13 Oct 2020 20:21:04 -
> @@ -475,7 +475,7 @@ union pf_rule_ptr {
> };
>
> #define PF_ANCHOR_NAME_SIZE 64
> -#define PF_ANCHOR_MAXPATH (MAXPATHLEN - PF_ANCHOR_NAME_SIZE - 1)
> +#define PF_ANCHOR_MAXPATH (PATH_MAX - PF_ANCHOR_NAME_SIZE - 1)
> #define PF_OPTIMIZER_TABLE_PFX "__automatic_"
>
> struct pf_rule {
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
Re: Non-const basename: bin/chio
On Tue, 13 Oct 2020 21:37:11 +0200, Christian Weisgerber wrote: > As far as I understand, the basename() here is specifically intended > to skip a leading "/dev/". So how about doing this expressly? That works for me. > Do we want to use _PATH_DEV or "/dev/"? There's a "/dev/rst%d" a > few lines outside of the diff context... I'd use _PATH_DEV but it doesn't really matter. It is not like we can really change the value of _PATH_DEV. OK millert@ either way. - todd
Re: Non-const basename: sbin/pfctl
Hello,
On Tue, Oct 13, 2020 at 10:52:58PM +0200, Christian Weisgerber wrote:
> Accommodate a basename(3) that takes a non-const parameter and may
> in fact modify the string buffer.
>
> The length of anchor has already been checked in main().
>
> ok?
looks OK to me.
sashan
>
> Index: sbin/pfctl/pfctl.c
> ===
> RCS file: /cvs/src/sbin/pfctl/pfctl.c,v
> retrieving revision 1.382
> diff -u -p -r1.382 pfctl.c
> --- sbin/pfctl/pfctl.c16 Jan 2020 01:02:20 - 1.382
> +++ sbin/pfctl/pfctl.c13 Oct 2020 20:45:16 -
> @@ -2241,16 +2241,19 @@ pfctl_get_anchors(int dev, const char *a
> {
> struct pfioc_rulesetpr;
> static struct pfr_anchors anchors;
> + char anchorbuf[PATH_MAX];
> char *n;
>
> SLIST_INIT();
>
> memset(, 0, sizeof(pr));
> if (*anchor != '\0') {
> - n = dirname(anchor);
> + strlcpy(anchorbuf, anchor, sizeof(anchorbuf));
> + n = dirname(anchorbuf);
> if (n[0] != '.' && n[1] != '\0')
> strlcpy(pr.path, n, sizeof(pr.path));
> - n = basename(anchor);
> + strlcpy(anchorbuf, anchor, sizeof(anchorbuf));
> + n = basename(anchorbuf);
> if (n != NULL)
> strlcpy(pr.name, n, sizeof(pr.name));
> }
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
Non-const basename: sbin/pfctl
Accommodate a basename(3) that takes a non-const parameter and may
in fact modify the string buffer.
The length of anchor has already been checked in main().
ok?
Index: sbin/pfctl/pfctl.c
===
RCS file: /cvs/src/sbin/pfctl/pfctl.c,v
retrieving revision 1.382
diff -u -p -r1.382 pfctl.c
--- sbin/pfctl/pfctl.c 16 Jan 2020 01:02:20 - 1.382
+++ sbin/pfctl/pfctl.c 13 Oct 2020 20:45:16 -
@@ -2241,16 +2241,19 @@ pfctl_get_anchors(int dev, const char *a
{
struct pfioc_rulesetpr;
static struct pfr_anchors anchors;
+ char anchorbuf[PATH_MAX];
char *n;
SLIST_INIT();
memset(, 0, sizeof(pr));
if (*anchor != '\0') {
- n = dirname(anchor);
+ strlcpy(anchorbuf, anchor, sizeof(anchorbuf));
+ n = dirname(anchorbuf);
if (n[0] != '.' && n[1] != '\0')
strlcpy(pr.path, n, sizeof(pr.path));
- n = basename(anchor);
+ strlcpy(anchorbuf, anchor, sizeof(anchorbuf));
+ n = basename(anchorbuf);
if (n != NULL)
strlcpy(pr.name, n, sizeof(pr.name));
}
--
Christian "naddy" Weisgerber na...@mips.inka.de
net/pfvar.h: MAXPATHLEN -> PATH_MAX
In revision 1.407 of , deraadt@ replaced MAXPATHLEN
with PATH_MAX so userland wouldn't have to pull in .
In 1.466, sashan@ accidentally slipped one MAXPATHLEN back in,
because its use is ubiquitous on the kernel side of pf. Switch
this over to PATH_MAX again.
pfctl(8) doesn't actually use this, so it's very cosmetic.
Index: sys/net/pfvar.h
===
RCS file: /cvs/src/sys/net/pfvar.h,v
retrieving revision 1.496
diff -u -p -r1.496 pfvar.h
--- sys/net/pfvar.h 24 Aug 2020 15:30:58 - 1.496
+++ sys/net/pfvar.h 13 Oct 2020 20:21:04 -
@@ -475,7 +475,7 @@ union pf_rule_ptr {
};
#definePF_ANCHOR_NAME_SIZE 64
-#definePF_ANCHOR_MAXPATH (MAXPATHLEN - PF_ANCHOR_NAME_SIZE - 1)
+#definePF_ANCHOR_MAXPATH (PATH_MAX - PF_ANCHOR_NAME_SIZE - 1)
#definePF_OPTIMIZER_TABLE_PFX "__automatic_"
struct pf_rule {
--
Christian "naddy" Weisgerber na...@mips.inka.de
Non-const basename: bin/chio
As far as I understand, the basename() here is specifically intended
to skip a leading "/dev/". So how about doing this expressly?
Do we want to use _PATH_DEV or "/dev/"? There's a "/dev/rst%d" a
few lines outside of the diff context...
Index: bin/chio/parse.y
===
RCS file: /cvs/src/bin/chio/parse.y,v
retrieving revision 1.22
diff -u -p -r1.22 parse.y
--- bin/chio/parse.y13 Feb 2019 22:57:07 - 1.22
+++ bin/chio/parse.y13 Oct 2020 19:23:22 -
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -445,10 +446,12 @@ parse_tapedev(const char *filename, cons
errors = file->errors;
popfile();
+ if (strncmp(changer, _PATH_DEV, sizeof(_PATH_DEV) - 1) == 0)
+ changer += sizeof(_PATH_DEV) - 1;
TAILQ_FOREACH(p, , entry) {
- if (strcmp(basename(changer), p->name) == 0) {
+ if (strcmp(changer, p->name) == 0) {
if (drive >= 0 && drive < p->drivecnt) {
- if (asprintf(, "/dev/%s",
+ if (asprintf(, _PATH_DEV "%s",
p->drives[drive]) == -1)
errx(1, "malloc failed");
} else
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: [PATCH] Add IOMMU support for Intel VT-d and AMD-Vi
> Date: Thu, 8 Oct 2020 00:34:28 -0500
> From: Jordan Hargrave
>
> Ok updated the new changes.
I think this is good enough for further cleanup in the tree now.
Builds all thr amd64 kernels, doesn't break i386 and arm64 GENERIC.MP.
However, I think acpidmar(4) shouldn't be enabled yet until have done
a bit more testing. Theo do we want to compile in the driver such
that people can easily flip it on in UKC?
I also noticed that re(4) does a bad DMA transfer as soon as the
interface is brought up. With your diff the kernel doesn't panic if
that happensl it just spits out some debugging information. We may
want to change that in the future.
ok kettenis@ once the question about enabling acpidmar(4) is resolved.
>
> On Mon, Oct 05, 2020 at 09:54:02PM +0200, Mark Kettenis wrote:
> > > Date: Thu, 17 Sep 2020 20:54:51 -0500
> > > From: Jordan Hargrave
> > > Cc: ma...@peereboom.org, kette...@openbsd.org, tech@openbsd.org,
> > > d...@openbsd.org, j...@openbsd.org
> > > Content-Type: text/plain; charset=us-ascii
> > > Content-Disposition: inline
> > >
> > > Ok made more changes
> > >
> > > >
> > > > Should be handled by that activate function as well.
> > > >
> >
> > So there are quite a few style issues. I can point them out to you,
> > or I could fix them after this is committed, which is probably more
> > efficient.
> >
> > Also, there seems to be lot of debug code left in here that should be
> > removed or at least hidden before this gets committed.
> >
> > >
> > > diff --git a/sys/arch/amd64/conf/GENERIC b/sys/arch/amd64/conf/GENERIC
> > > index 1d6397391..a69c72c26 100644
> > > --- a/sys/arch/amd64/conf/GENERIC
> > > +++ b/sys/arch/amd64/conf/GENERIC
> > > @@ -45,6 +45,7 @@ acpibtn*at acpi?
> > > acpicpu* at acpi?
> > > acpicmos*at acpi?
> > > acpidock*at acpi?
> > > +acpidmar0at acpi?
> > > acpiec* at acpi?
> > > acpipci* at acpi?
> > > acpiprt* at acpi?
> > > diff --git a/sys/arch/amd64/include/pci_machdep.h
> > > b/sys/arch/amd64/include/pci_machdep.h
> > > index bc295cc22..ea09f1abc 100644
> > > --- a/sys/arch/amd64/include/pci_machdep.h
> > > +++ b/sys/arch/amd64/include/pci_machdep.h
> > > @@ -91,7 +91,12 @@ void
> > > *pci_intr_establish_cpu(pci_chipset_tag_t, pci_intr_handle_t,
> > > int, struct cpu_info *,
> > > int (*)(void *), void *, const char *);
> > > void pci_intr_disestablish(pci_chipset_tag_t, void *);
> > > +#if NACPIDMAR > 0
> > > +int pci_probe_device_hook(pci_chipset_tag_t,
> > > + struct pci_attach_args *);
> > > +#else
> > > #define pci_probe_device_hook(c, a) (0)
> > > +#endif
> >
> > This is probably a bad idea. You don't include "acpidmar.h" in this
> > file, and doing so is probaly undesireable. But that means the
> > definition of the hook function depends on whether the file that
> > includes this does that or not.
> >
> > Better just unconditionally provide the prototype and use a #if
> > NACPIDMAR > 0 in the implementation.
> >
>
> Ok changed to that method
>
> > > +#include "acpidmar.h"
> > > +#include "amd_iommu.h"
> > > +
> > > +//#define IOMMU_DEBUG
> >
> > No C++-style comments please. Make this an #undef or use /* */.
> >
> > > +
> > > +#ifdef IOMMU_DEBUG
> > > +#define dprintf(x...) printf(x)
> > > +#else
> > > +#define dprintf(x...)
> > > +#endif
> > > +
> > > +#ifdef DDB
> > > +int acpidmar_ddb = 0;
> > > +#endif
> > > +
> > > +int intel_iommu_gfx_mapped = 0;
> >
> > Unused variable.
> >
> > > +int force_cm = 1;
> >
> > Rename to "acpidmar_force_cm"?
> >
> > > +
> > > +void showahci(void *);
> >
> > Unused prototype.
> >
> > > +
> > > +/* Page Table Entry per domain */
> > > +struct iommu_softc;
> > > +
> > > +static inline int
> > > +mksid(int b, int d, int f)
> > > +{
> > > + return (b << 8) + (d << 3) + f;
> > > +}
> > > +
> > > +static inline int
> > > +sid_devfn(int sid)
> > > +{
> > > + return sid & 0xff;
> > > +}
> > > +
> > > +static inline int
> > > +sid_bus(int sid)
> > > +{
> > > + return (sid >> 8) & 0xff;
> > > +}
> > > +
> > > +static inline int
> > > +sid_dev(int sid)
> > > +{
> > > + return (sid >> 3) & 0x1f;
> > > +}
> > > +
> > > +static inline int
> > > +sid_fun(int sid)
> > > +{
> > > + return (sid >> 0) & 0x7;
> > > +}
> > > +
> > > +/* Alias mapping */
> > > +#define SID_INVALID 0x8000L
> > > +static uint32_t sid_flag[65536];
> > > +
> > > +struct domain_dev {
> > > + int sid;
> > > + int sec;
> > > + int sub;
> > > + TAILQ_ENTRY(domain_dev) link;
> > > +};
> > > +
> > > +struct domain {
> > > + struct iommu_softc *iommu;
> > > + int did;
> > > + int gaw;
> > > + struct pte_entry*pte;
> > > + paddr_t ptep;
> > > + struct bus_dma_tag dmat;
> > > + int flag;
> > > +
> > > + struct mutexexlck;
> >
Re: Unbound 1.12.0
On 2020-10-13 07:25, Stuart Henderson wrote: On 2020/10/11 15:37, Renaud Allard wrote: On 10/10/2020 22:05, Stuart Henderson wrote: Here's an update to the recently released version of Unbound. Much of the additional code is for DoH and is unused here as it requires the nghttp2 library. nghttp2 seems to be MIT licensed. Could it be possible to import it in base? Personally I am not particularly interested in pushing a library that is already in ports into base.. At this point I would prefer to handle it as a simple update, then consider 1) whether there should be a separate "ports unbound" with things that can't (or can't easily) be handled in base - e.g. this, python, dnstap or 2) whether unbound should just move back to ports completely. Not that my opinion matters, but I really enjoy having a nice relatively "stripped down" unbound in base. I like knowing the OpenBSD folks have stripped out a lot of the cruft. I shouldn't need Python and an HTTP parsing library just to run a modest little local resolver -- Just my two cents. Regards, Jordan
Non-const basename: usr.sbin/hotplugd
Accommodate a basename(3) that takes a non-const parameter and may
in fact modify the string buffer.
Between access(file, ...) and execl(file, ...), no check for
truncation should be necessary.
ok?
Index: usr.sbin/hotplugd/hotplugd.c
===
RCS file: /cvs/src/usr.sbin/hotplugd/hotplugd.c,v
retrieving revision 1.15
diff -u -p -r1.15 hotplugd.c
--- usr.sbin/hotplugd/hotplugd.c30 Apr 2019 17:05:15 - 1.15
+++ usr.sbin/hotplugd/hotplugd.c13 Oct 2020 16:19:43 -
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -163,7 +164,10 @@ exec_script(const char *file, int class,
}
if (pid == 0) {
/* child process */
- execl(file, basename(file), strclass, name, (char *)NULL);
+ char filebuf[PATH_MAX];
+
+ strlcpy(filebuf, file, sizeof(filebuf));
+ execl(file, basename(filebuf), strclass, name, (char *)NULL);
syslog(LOG_ERR, "execl %s: %m", file);
_exit(1);
/* NOTREACHED */
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: Unbound 1.12.0
On 2020/10/11 15:37, Renaud Allard wrote: > > > On 10/10/2020 22:05, Stuart Henderson wrote: > > Here's an update to the recently released version of Unbound. Much of > > the additional code is for DoH and is unused here as it requires the > > nghttp2 library. > > > > nghttp2 seems to be MIT licensed. Could it be possible to import it in base? > Personally I am not particularly interested in pushing a library that is already in ports into base.. At this point I would prefer to handle it as a simple update, then consider 1) whether there should be a separate "ports unbound" with things that can't (or can't easily) be handled in base - e.g. this, python, dnstap or 2) whether unbound should just move back to ports completely.
Diff to allow selection of source IP address
Is anyone interested in this ?
This diff allows to select the default source IP address (for TCP/UDP
connections) on multi-homed & "multi-addressed" machines.
Looking for feedbacks on what I broke.
Do not test with ping(8) as it uses another source address selection codepath.
`curl ifconfig.co` is a good candidate to check if source is set correctly.
Example usage :
Set 2001:db8::1 as source : route source 2001:db8::1
Unset previously set IPv6 address on rdomain 10 : route -T10 source -inet6
default
Show set address : route source
Comments ? OK ?
Denis
Index: sbin/route/keywords.h
===
RCS file: /cvs/src/sbin/route/keywords.h,v
retrieving revision 1.34
diff -u -p -r1.34 keywords.h
--- sbin/route/keywords.h 10 Aug 2017 13:44:48 - 1.34
+++ sbin/route/keywords.h 17 Sep 2020 09:59:25 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: keywords.h,v 1.34 2017/08/10 13:44:48 benno Exp $ */
+/* $OpenBSD$ */
/* WARNING! This file was generated by keywords.sh */
@@ -66,6 +66,7 @@ enum {
K_SA,
K_SENDPIPE,
K_SHOW,
+ K_SOURCE,
K_SSTHRESH,
K_STATIC,
K_SWAP,
@@ -129,6 +130,7 @@ struct keytab keywords[] = {
{ "sa", K_SA },
{ "sendpipe", K_SENDPIPE },
{ "show", K_SHOW },
+ { "source", K_SOURCE },
{ "ssthresh", K_SSTHRESH },
{ "static", K_STATIC },
{ "swap", K_SWAP },
Index: sbin/route/keywords.sh
===
RCS file: /cvs/src/sbin/route/keywords.sh,v
retrieving revision 1.32
diff -u -p -r1.32 keywords.sh
--- sbin/route/keywords.sh 10 Aug 2017 13:44:48 - 1.32
+++ sbin/route/keywords.sh 17 Sep 2020 09:59:25 -
@@ -67,6 +67,7 @@ rttvar
sa
sendpipe
show
+source
ssthresh
static
swap
Index: sbin/route/route.8
===
RCS file: /cvs/src/sbin/route/route.8,v
retrieving revision 1.91
diff -u -p -r1.91 route.8
--- sbin/route/route.8 19 Jan 2020 18:22:31 - 1.91
+++ sbin/route/route.8 17 Sep 2020 09:59:25 -
@@ -195,6 +195,17 @@ or
.Cm bgp .
If the priority is negative, then routes that do not match the numeric
priority are shown.
+.It Xo
+.Nm route
+.Op Fl T Ar rtable
+.Tg
+.Cm source
+.Ar address
+.Xc
+Set the preferred source address. If
+.Ar address
+is the word "default", 0.0.0.0 or ::, source address will be chosen by
+the kernel for the matching address family.
.El
.Pp
.Tg destination
Index: sbin/route/route.c
===
RCS file: /cvs/src/sbin/route/route.c,v
retrieving revision 1.248
diff -u -p -r1.248 route.c
--- sbin/route/route.c 7 Jul 2020 14:53:36 - 1.248
+++ sbin/route/route.c 17 Sep 2020 09:59:25 -
@@ -68,7 +68,8 @@
const struct if_status_description
if_status_descriptions[] = LINK_STATE_DESCRIPTIONS;
-union sockunion so_dst, so_gate, so_mask, so_ifa, so_ifp, so_src, so_label;
+union sockunion so_dst, so_gate, so_mask, so_ifa, so_ifp, so_src, so_label,
+so_source;
typedef union sockunion *sup;
pid_t pid;
@@ -85,6 +86,7 @@ struct rt_metrics rt_metrics;
int flushroutes(int, char **);
int newroute(int, char **);
+int setsource(int, char **);
int show(int, char *[]);
int keycmp(const void *, const void *);
int keyword(char *);
@@ -132,7 +134,8 @@ usage(char *cp)
"usage: %s [-dnqtv] [-T rtable] command [[modifiers] args]\n",
__progname);
fprintf(stderr,
- "commands: add, change, delete, exec, flush, get, monitor, show\n");
+ "commands: add, change, delete, exec, flush, get, monitor, show, "
+ "source\n");
exit(1);
}
@@ -258,6 +261,10 @@ main(int argc, char **argv)
case K_FLUSH:
exit(flushroutes(argc, argv));
break;
+ case K_SOURCE:
+ nflag = 1;
+ exit(setsource(argc, argv));
+ break;
}
if (pledge("stdio dns", NULL) == -1)
@@ -450,6 +457,52 @@ set_metric(char *value, int key)
locking = 0;
}
+
+int
+setsource(int argc, char **argv)
+{
+ char *cmd, *srcaddr = "";
+ int af = AF_UNSPEC, ret = 0;
+ struct hostent *hp = NULL;
+ int key;
+
+ if (uid)
+ errx(1, "must be root to alter source address");
+ cmd = argv[0];
+ while (--argc > 0) {
+ if (**(++argv)== '-') {
+ switch (key = keyword(1 + *argv)) {
+ case K_INET:
+ af = AF_INET;
+ aflen = sizeof(struct sockaddr_in);
+ break;
+ case K_INET6:
+ af = AF_INET6;
+ aflen = sizeof(struct
Re: WANTLIB problems and possible solution: the libset design
On Sun, Oct 11, 2020 at 06:03:55PM +0200, Landry Breuil wrote: > On Sun, Oct 11, 2020 at 05:03:31PM +0200, Marc Espie wrote: > > On Sun, Oct 11, 2020 at 04:53:18PM +0200, Christian Weisgerber wrote: > > > Marc Espie: > > > > > > > The new design: > > > > > > > > The idea behind "libset" is to be able to specify a "set" of wantlib > > > > that > > > > corresponds to our package, AND to just write WANTLIB wrt that libset > > > > for > > > > that specific set of libraries. > > > > > > I'm struggling to understand whether this libset records the libraries > > > a port depends on, the libraries the port provides, or both. > > > > > > Let's say--slightly simplified from reality--we have devel/gettext > > > that provides libintl and depends on iconv from converters/libiconv. > > > What would gettext's LIBSET entry look like? > > > > > > (1) LIBSET = iconv > > > (2) LIBSET = intl > > > (3) LIBSET = intl iconv > > > > > > > > I assume any user of gettext will need both iconv and intl, so > > > > LIBSET = intl iconv > > Hmm, pretty sure some consumers of gettext only have one in their > WANTLIB and not both, in that case those ones shouldnt you the libset to > avoid an extra WANTLIB ? > On the off chance I understood your meaning, I think it's better to err on the side of having too many WANTLIB than too few. I fail to see an actual downside to updating when iconv gets updated. gettext will often be updated as well.
Re: WANTLIB problems and possible solution: the libset design
On Sun, Oct 11, 2020 at 06:03:55PM +0200, Landry Breuil wrote: > On Sun, Oct 11, 2020 at 05:03:31PM +0200, Marc Espie wrote: > > On Sun, Oct 11, 2020 at 04:53:18PM +0200, Christian Weisgerber wrote: > > > Marc Espie: > > > > > > > The new design: > > > > > > > > The idea behind "libset" is to be able to specify a "set" of wantlib > > > > that > > > > corresponds to our package, AND to just write WANTLIB wrt that libset > > > > for > > > > that specific set of libraries. > > > > > > I'm struggling to understand whether this libset records the libraries > > > a port depends on, the libraries the port provides, or both. > > > > > > Let's say--slightly simplified from reality--we have devel/gettext > > > that provides libintl and depends on iconv from converters/libiconv. > > > What would gettext's LIBSET entry look like? > > > > > > (1) LIBSET = iconv > > > (2) LIBSET = intl > > > (3) LIBSET = intl iconv > > > > > > > > I assume any user of gettext will need both iconv and intl, so > > > > LIBSET = intl iconv > > Hmm, pretty sure some consumers of gettext only have one in their > WANTLIB and not both, in that case those ones shouldnt you the libset to > avoid an extra WANTLIB ? How about you make a full sentence with the correct words so I get what you mean ?
Re: Non-const basename: libkvm
On Tue, 13 Oct 2020 11:05:42 +0200, Christian Weisgerber wrote: > Accommodate a basename(3) that takes a non-const parameter and may > in fact modify the string buffer. > > Note that strlen(uf) >= PATH_MAX is already checked by the caller > in _kvm_open(). OK. - todd
Non-const basename: libkvm
Accommodate a basename(3) that takes a non-const parameter and may
in fact modify the string buffer.
Note that strlen(uf) >= PATH_MAX is already checked by the caller
in _kvm_open().
ok?
Index: lib/libkvm/kvm.c
===
RCS file: /cvs/src/lib/libkvm/kvm.c,v
retrieving revision 1.66
diff -u -p -r1.66 kvm.c
--- lib/libkvm/kvm.c28 Jun 2019 13:32:42 - 1.66
+++ lib/libkvm/kvm.c13 Oct 2020 08:55:29 -
@@ -676,12 +676,13 @@ static int
kvm_dbopen(kvm_t *kd, const char *uf)
{
char dbversion[_POSIX2_LINE_MAX], kversion[_POSIX2_LINE_MAX];
- char dbname[PATH_MAX];
+ char dbname[PATH_MAX], ufbuf[PATH_MAX];
struct nlist nitem;
size_t dbversionlen;
DBT rec;
- uf = basename(uf);
+ strlcpy(ufbuf, uf, sizeof(ufbuf));
+ uf = basename(ufbuf);
(void)snprintf(dbname, sizeof(dbname), "%skvm_%s.db", _PATH_VARDB, uf);
kd->db = dbopen(dbname, O_RDONLY, 0, DB_HASH, NULL);
--
Christian "naddy" Weisgerber na...@mips.inka.de
