> On Tue, May 9, 2017 at 4:17 PM, Ted Unangst wrote:
> > Matthew Martin wrote:
>
> I would suggest N^2 loops are automatically forgiveable, If there
> is a limit on N,
> which is a reasonable number for any supported environment, but total
> potential
> impact on
On Tue, May 9, 2017 at 4:17 PM, Ted Unangst wrote:
> Matthew Martin wrote:
I would suggest N^2 loops are automatically forgiveable, If there
is a limit on N,
which is a reasonable number for any supported environment, but total potential
impact on performance for
On Tue, May 9, 2017 at 3:27 PM, Peter J. Philipp wrote:
> Sorry the patch is bad because I fail to check what I want to free for NULL.
> You probably caught it. Better let someone with lots of experience handle
> this.
At a cursory glance.
Check the referrentI
Matthew Martin wrote:
> Duplicate environment variables have been a source of bugs, so perhaps
> the kernel should fail an execve with an invalid envp. Diff below checks
> that each environment string contains a '=' and that there are no
> duplicates up to the equals sign.
It's not really the
Peter J. Philipp wrote:
> In my tinkering with the ELFSEC mechanism, I have noticed something
> possibly troubling. In /sys/kern/exec_script.c shellname is a pointer
> to cp which is a pointer to hdrstr which is a pointer to epp->ep_hdr...
> When calling the intended set shellname variable,
On Tue, May 09, 2017 at 10:05:28PM +0200, Peter J. Philipp wrote:
> Hi,
>
> In my tinkering with the ELFSEC mechanism, I have noticed something
> possibly troubling. In /sys/kern/exec_script.c shellname is a pointer
> to cp which is a pointer to hdrstr which is a pointer to epp->ep_hdr...
> When
Hi,
In my tinkering with the ELFSEC mechanism, I have noticed something
possibly troubling. In /sys/kern/exec_script.c shellname is a pointer
to cp which is a pointer to hdrstr which is a pointer to epp->ep_hdr...
When calling the intended set shellname variable, later, I get part of the ELF
On Tue, May 09, 2017 at 09:50:19AM +0200, David Coppa wrote:
> Hi!
>
> Fixes for:
>
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8105
>
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8287
>
> From upstream via Arch Linux.
>
> Patches for -current and 6.1.
>
> Ok?
ok.
On Tue, May 09, 2017 at 14:13 +0200, Patrick Wildt wrote:
> On Tue, May 09, 2017 at 01:55:18PM +0200, Mike Belopuhov wrote:
> > On Tue, May 09, 2017 at 10:36 +0200, Patrick Wildt wrote:
> > > On Mon, May 08, 2017 at 02:56:55PM +0200, Patrick Wildt wrote:
> > > > @@ -2307,9 +2326,9 @@
As pointed out by tb@ I forgot about taking care of free'ing finalbuf if
kn_encode_base64 fails.
Revised diff below:
Index: signature.c
===
RCS file: /cvs/src/lib/libkeynote/signature.c,v
retrieving revision 1.25
diff -u -p -u
On 9 May 2017 at 14:13, Patrick Wildt wrote:
> On Tue, May 09, 2017 at 01:55:18PM +0200, Mike Belopuhov wrote:
> > On Tue, May 09, 2017 at 10:36 +0200, Patrick Wildt wrote:
> > > On Mon, May 08, 2017 at 02:56:55PM +0200, Patrick Wildt wrote:
> > > > @@ -2307,9 +2326,9 @@
On Sun, May 07, 2017 at 05:37:47PM +0200, Mark Kettenis wrote:
> So this enables the code. It makes -femulated-tls the default,
> otherwise it will generated TLS relocations that we can't handle yet.
> It is possible to specify -fno-emulated-tls if you really want to
> generate those.
>
> A
Hi,
Found with scan-build, there's a potential leak memory on libkeynote, if
kn_encode_base64 is successful inside keynote_sign_assertion function.
OK?
Index: signature.c
===
RCS file: /cvs/src/lib/libkeynote/signature.c,v
On Tue, May 09, 2017 at 01:55:18PM +0200, Mike Belopuhov wrote:
> On Tue, May 09, 2017 at 10:36 +0200, Patrick Wildt wrote:
> > On Mon, May 08, 2017 at 02:56:55PM +0200, Patrick Wildt wrote:
> > > @@ -2307,9 +2326,9 @@ pfr_pool_get(struct pf_pool *rpool, struct pf_addr
> > > **raddr,
> > >
On 9 May 2017 at 13:38, Alexander Bluhm wrote:
> Hi,
>
> Remove rip_output() and rip6_output() from inetsw and inet6sw. The
> rip_output() function is never called via the pr_output pointer.
> rip_usrreq(PRU_SEND) calls rip_output() directly. raw_usrreq() is
> never
On Tue, May 09, 2017 at 10:36 +0200, Patrick Wildt wrote:
> On Mon, May 08, 2017 at 02:56:55PM +0200, Patrick Wildt wrote:
> > @@ -2307,9 +2326,9 @@ pfr_pool_get(struct pf_pool *rpool, struct pf_addr
> > **raddr,
> > rpool->curweight = kt->pfrkt_maxweight;
> > }
> >
> >
On Tue, May 09, 2017 at 01:38:07PM +0200, Alexander Bluhm wrote:
> Hi,
>
> Remove rip_output() and rip6_output() from inetsw and inet6sw. The
> rip_output() function is never called via the pr_output pointer.
> rip_usrreq(PRU_SEND) calls rip_output() directly. raw_usrreq() is
> never called
Hi,
Remove rip_output() and rip6_output() from inetsw and inet6sw. The
rip_output() function is never called via the pr_output pointer.
rip_usrreq(PRU_SEND) calls rip_output() directly. raw_usrreq() is
never called from inetsw. Situation in inet and inet6 is analog.
ok?
bluhm
Index:
On Sun, May 07, 2017 at 08:06:14PM -0400, Andre Smagin wrote:
> On Mon, 8 May 2017 00:03:02 +0200
> Alexandre Ratchov wrote:
>
> > On Sun, May 07, 2017 at 02:10:03PM -0400, Andre Smagin wrote:
> > >
> > > >From my limited testing it appears that sio_getcap() fails if audio
> > >
On Mon, May 08, 2017 at 02:56:55PM +0200, Patrick Wildt wrote:
> @@ -2307,9 +2326,9 @@ pfr_pool_get(struct pf_pool *rpool, struct pf_addr
> **raddr,
> rpool->curweight = kt->pfrkt_maxweight;
> }
>
> - pfr_prepare_network(_mask, af, ke->pfrke_net);
> +
Hi!
Fixes for:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8105
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8287
>From upstream via Arch Linux.
Patches for -current and 6.1.
Ok?
Ciao,
David
Index: src/psaux/psobjs.c
21 matches
Mail list logo