similar to: [Bug 866] ssh(1) is too picky about unknown options in ~/.ssh/config

https://bugzilla.mindrot.org/show_bug.cgi?id=866 --- Comment #17 from Olav Morken <olavmrk at gmail.com> 2009-03-09 06:21:16 --- Created an attachment (id=1610) --> (http://bugzilla.mindrot.org/attachment.cgi?id=1610) Patch which allows OpenSSH to ignore unknown options. This is a patch which implements alternative 1 from Josh Triplett. This patch makes ssh ignore all unknown

https://bugzilla.mindrot.org/show_bug.cgi?id=866 Josh Triplett <josh at freedesktop.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |josh at freedesktop.org --- Comment #13 from Josh Triplett <josh at freedesktop.org> 2008-01-03

On Mon, Oct 21, 2013 at 7:34 PM, Josh Triplett <josh at joshtriplett.org> wrote: > __set_tss_desc has a complex calculation of the TSS segment limit, > duplicating the quirky details of the I/O bitmap array length, and > requiring a complex comment to explain. Replace that calculation with a > simpler one based on the offsetof the "stack" field that follows the >

On Mon, Oct 21, 2013 at 7:34 PM, Josh Triplett <josh at joshtriplett.org> wrote: > __set_tss_desc has a complex calculation of the TSS segment limit, > duplicating the quirky details of the I/O bitmap array length, and > requiring a complex comment to explain. Replace that calculation with a > simpler one based on the offsetof the "stack" field that follows the >

On Mon, Sep 28, 2015 at 10:29:16AM +0200, Erwan Velu wrote: > Just looking at the code and the description of it, for me the current code > looks wrong and the proposed patch correct for the following reason: > > The while loop is made for insuring that *source is valid but just after > shift the pointer by one. > This new position isn't tested and so we are addressing an

On Mon, Dec 16, 2013 at 06:23:38AM -0800, Josh Triplett wrote: > On Mon, Dec 16, 2013 at 04:54:08PM +0530, Rashika Kheria wrote: > > Mark the function virtballoon_migratepage() as static in > > virtio_balloon.c because it is not used outside this file. > > > > This eliminates the following warning in virtio_balloon.c: > > drivers/virtio/virtio_balloon.c:372:5:

On Mon, Dec 16, 2013 at 06:23:38AM -0800, Josh Triplett wrote: > On Mon, Dec 16, 2013 at 04:54:08PM +0530, Rashika Kheria wrote: > > Mark the function virtballoon_migratepage() as static in > > virtio_balloon.c because it is not used outside this file. > > > > This eliminates the following warning in virtio_balloon.c: > > drivers/virtio/virtio_balloon.c:372:5:

On Wed, Oct 29, 2014 at 09:59:25AM -0700, Kees Cook wrote: > On Wed, Oct 29, 2014 at 9:10 AM, Josh Triplett <josh at joshtriplett.org> wrote: > > --- a/arch/x86/kernel/process-io.h > > +++ b/arch/x86/kernel/process-io.h > > @@ -1,9 +1,17 @@ > > #ifndef _X86_KERNEL_PROCESS_IO_H > > #define _X86_KERNEL_PROCESS_IO_H > > > > +static inline void

On Wed, Oct 29, 2014 at 09:59:25AM -0700, Kees Cook wrote: > On Wed, Oct 29, 2014 at 9:10 AM, Josh Triplett <josh at joshtriplett.org> wrote: > > --- a/arch/x86/kernel/process-io.h > > +++ b/arch/x86/kernel/process-io.h > > @@ -1,9 +1,17 @@ > > #ifndef _X86_KERNEL_PROCESS_IO_H > > #define _X86_KERNEL_PROCESS_IO_H > > > > +static inline void

Erwan, could you shed some light on this? Was the behavior intentional? If not, I think it might prove more useful down the road to commit this patch. Original code in commit ID 85d9a1a -- -Gene On Sat, May 16, 2015 at 3:30 AM, Josh Triplett via Syslinux <syslinux at zytor.com> wrote: > Check if the first character matches the character to replace, rather > than skipping it and

Some kernel images use the Linux kernel boot protocol and header structure, but do not actually have any protected-mode code. For instance, grub's 1024-byte lnxboot.img consists of 1024 real-mode bytes and 0 protected-mode bytes; you can concatenate it with a full grub core.img to produce a self-contained bootable kernel, but you can also use it standalone as the kernel with the core.img

Hi Josh, Since you added me to the CC, I had a look... Comments inline On Tue, Oct 22, 2013, at 3:34, Josh Triplett wrote: > The 32-bit and 64-bit versions of copy_thread have functionally > identical handling for copying the I/O bitmap, modulo differences in > error handling. Clean up the error paths in both by moving the copy of > the I/O bitmap to the end, to eliminate the need

Hi Josh, Since you added me to the CC, I had a look... Comments inline On Tue, Oct 22, 2013, at 3:34, Josh Triplett wrote: > The 32-bit and 64-bit versions of copy_thread have functionally > identical handling for copying the I/O bitmap, modulo differences in > error handling. Clean up the error paths in both by moving the copy of > the I/O bitmap to the end, to eliminate the need

Hi Josh, On Tue, Oct 22, 2013, at 3:34, Josh Triplett wrote: > __set_tss_desc has a complex calculation of the TSS segment limit, > duplicating the quirky details of the I/O bitmap array length, and > requiring a complex comment to explain. Replace that calculation with a > simpler one based on the offsetof the "stack" field that follows the > array. > > That then

Hi Josh, On Tue, Oct 22, 2013, at 3:34, Josh Triplett wrote: > __set_tss_desc has a complex calculation of the TSS segment limit, > duplicating the quirky details of the I/O bitmap array length, and > requiring a complex comment to explain. Replace that calculation with a > simpler one based on the offsetof the "stack" field that follows the > array. > > That then

On Mon, Nov 03, 2014 at 12:10:49PM +0000, One Thousand Gnomes wrote: > On Sun, 2 Nov 2014 09:33:01 -0800 > Josh Triplett <josh at joshtriplett.org> wrote: > > > On the vast majority of modern systems, no processes will use the > > userspsace IO syscalls, iopl and ioperm. Add a new config option, > > CONFIG_X86_IOPORT, to support configuring them out of the kernel

On Mon, Jun 15, 2015 at 08:57:24PM +0300, Ady wrote: > > > Check if the first character matches the character to replace, rather > > than skipping it and starting with the second. > > > > Signed-off-by: Josh Triplett <josh at joshtriplett.org> > > --- > > > > I'm assuming, based on a look at the callers, that this is not > >

Just looking at the code and the description of it, for me the current code looks wrong and the proposed patch correct for the following reason: The while loop is made for insuring that *source is valid but just after shift the pointer by one. This new position isn't tested and so we are addressing an unknown area. That could corrupt some memory. But also as reported, that prevent from

https://bugzilla.mindrot.org/show_bug.cgi?id=866 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #1610|0 |1 is obsolete| | --- Comment #20 from Damien Miller <djm at mindrot.org> ---

> Check if the first character matches the character to replace, rather > than skipping it and starting with the second. > > Signed-off-by: Josh Triplett <josh at joshtriplett.org> > --- > > I'm assuming, based on a look at the callers, that this is not > intentional, and that it just happened that none of the callers happened > to ever need to replace the