On 22/05/17 23:30, Alexander Sverdlin wrote:
> As agreed with Ryan, change the maintainership.
Thanks for taking this over Alexander.
Acked-by: Ryan Mallon <rmal...@gmail.com>
> Signed-off-by: Alexander Sverdlin <alexander.sverd...@gmail.com>
> ---
> MAINTAINERS | 2
On 22/05/17 23:30, Alexander Sverdlin wrote:
> As agreed with Ryan, change the maintainership.
Thanks for taking this over Alexander.
Acked-by: Ryan Mallon
> Signed-off-by: Alexander Sverdlin
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
On 29/08/14 00:15, Sudip Mukherjee wrote:
> printk replaced with corresponding pr_err, dev_alert, dev_notice and pr_info.
> fixed two broken user-visible strings used by the corresponding printk
>
> Signed-off-by: Sudip Mukherjee
> ---
>
> In the first patch i sent Greg suggested to use
On 29/08/14 00:15, Sudip Mukherjee wrote:
printk replaced with corresponding pr_err, dev_alert, dev_notice and pr_info.
fixed two broken user-visible strings used by the corresponding printk
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
In the first patch i sent Greg
On 12/08/14 17:35, Sanjeev Sharma wrote:
> on some architecture spin_is_locked() always return false in
> uniprocessor configuration and can therefore not be used
> with BUG_ON.it would be advise to replace with
> lockdep_assert_held().
>
> Signed-off-by: Sanjeev Sharma
> ---
>
On 12/08/14 17:35, Sanjeev Sharma wrote:
on some architecture spin_is_locked() always return false in
uniprocessor configuration and can therefore not be used
with BUG_ON.it would be advise to replace with
lockdep_assert_held().
Signed-off-by: Sanjeev Sharma sanjeev_sha...@mentor.com
---
On 12/02/14 19:54, Tomi Valkeinen wrote:
> On 11/02/14 21:07, Ryan Mallon wrote:
>> On 12/02/14 03:06, Tomi Valkeinen wrote:
>>
>>> On 20/09/13 10:06, Ryan Mallon wrote:
>>>> Several video drivers open code the fb_write write function with code
>>>>
On 12/02/14 03:06, Tomi Valkeinen wrote:
> On 20/09/13 10:06, Ryan Mallon wrote:
>> Several video drivers open code the fb_write write function with code
>> which is very similar to fb_sys_write. Replace the open code versions
>> with calls to fb_sys_write. An fb_sync call
On 12/02/14 03:06, Tomi Valkeinen wrote:
On 20/09/13 10:06, Ryan Mallon wrote:
Several video drivers open code the fb_write write function with code
which is very similar to fb_sys_write. Replace the open code versions
with calls to fb_sys_write. An fb_sync callback is added to each
On 12/02/14 19:54, Tomi Valkeinen wrote:
On 11/02/14 21:07, Ryan Mallon wrote:
On 12/02/14 03:06, Tomi Valkeinen wrote:
On 20/09/13 10:06, Ryan Mallon wrote:
Several video drivers open code the fb_write write function with code
which is very similar to fb_sys_write. Replace the open code
All in kernel users of %n in format strings have now been removed and
the %n directive is ignored. Remove the handling of %n so that it is
treated the same as any other invalid format string directive. Keep a
warning in place to deter new instances of %n in format strings.
Signed-off-by: Ryan
On 29/01/14 09:51, Kees Cook wrote:
> On Mon, Jan 27, 2014 at 5:02 PM, Ryan Mallon wrote:
>> On 28/01/14 11:39, Kees Cook wrote:
>>> If arguments are consumed without output when encountering %n, it
>>> could be used to benefit or improve information leak attack
On 29/01/14 09:51, Kees Cook wrote:
On Mon, Jan 27, 2014 at 5:02 PM, Ryan Mallon rmal...@gmail.com wrote:
On 28/01/14 11:39, Kees Cook wrote:
If arguments are consumed without output when encountering %n, it
could be used to benefit or improve information leak attacks that were
exposed via
All in kernel users of %n in format strings have now been removed and
the %n directive is ignored. Remove the handling of %n so that it is
treated the same as any other invalid format string directive. Keep a
warning in place to deter new instances of %n in format strings.
Signed-off-by: Ryan
On 28/01/14 11:39, Kees Cook wrote:
> If arguments are consumed without output when encountering %n, it
> could be used to benefit or improve information leak attacks that were
> exposed via a limited size buffer. Since %n is not used by the kernel,
> there is no reason to make an info leak attack
On 28/01/14 10:56, Kees Cook wrote:
> On Mon, Jan 27, 2014 at 3:11 PM, Ryan Mallon wrote:
>> On 28/01/14 10:03, Kees Cook wrote:
>>> Now that there has been a full release of the kernel, and all users
>>> of %n have been dropped, switch to %n use triggering a BUG. I
On 28/01/14 10:03, Kees Cook wrote:
> Now that there has been a full release of the kernel, and all users
> of %n have been dropped, switch to %n use triggering a BUG. Ignoring
> arguments could be used to assist in information leaks if an arbitrary
> format string was under the control of an
On 28/01/14 10:03, Kees Cook wrote:
Now that there has been a full release of the kernel, and all users
of %n have been dropped, switch to %n use triggering a BUG. Ignoring
arguments could be used to assist in information leaks if an arbitrary
format string was under the control of an
On 28/01/14 10:56, Kees Cook wrote:
On Mon, Jan 27, 2014 at 3:11 PM, Ryan Mallon rmal...@gmail.com wrote:
On 28/01/14 10:03, Kees Cook wrote:
Now that there has been a full release of the kernel, and all users
of %n have been dropped, switch to %n use triggering a BUG. Ignoring
arguments
On 28/01/14 11:39, Kees Cook wrote:
If arguments are consumed without output when encountering %n, it
could be used to benefit or improve information leak attacks that were
exposed via a limited size buffer. Since %n is not used by the kernel,
there is no reason to make an info leak attack any
On 13/12/13 06:06, Theodore Ts'o wrote:
> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
>> From: Vegard Nossum
>>
>> The idea is simple -- since different kernel versions are vulnerable to
>> different root exploits, hackers most likely try multiple exploits before
>>
On 13/12/13 06:06, Theodore Ts'o wrote:
On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
From: Vegard Nossum vegard.nos...@oracle.com
The idea is simple -- since different kernel versions are vulnerable to
different root exploits, hackers most likely try multiple
On 14/12/13 00:06, Ingo Molnar wrote:
>
> * Ryan Mallon wrote:
>
>> On 13/12/13 08:13, Kees Cook wrote:
>>> On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o wrote:
>>>> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
>>>
On 13/12/13 20:20, Vegard Nossum wrote:
> On 12/13/2013 12:50 AM, Ryan Mallon wrote:
>> On 13/12/13 08:13, Kees Cook wrote:
>>> On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o wrote:
>>>> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
>
On 13/12/13 20:20, Vegard Nossum wrote:
On 12/13/2013 12:50 AM, Ryan Mallon wrote:
On 13/12/13 08:13, Kees Cook wrote:
On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o ty...@mit.edu wrote:
On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
The idea is simple -- since
On 14/12/13 00:06, Ingo Molnar wrote:
* Ryan Mallon rmal...@gmail.com wrote:
On 13/12/13 08:13, Kees Cook wrote:
On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o ty...@mit.edu wrote:
On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
From: Vegard Nossum vegard.nos
On 13/12/13 08:13, Kees Cook wrote:
> On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o wrote:
>> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
>>> From: Vegard Nossum
>>>
>>> The idea is simple -- since different kernel versions are vulnerable to
>>> different root
On 13/12/13 08:13, Kees Cook wrote:
On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o ty...@mit.edu wrote:
On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nos...@oracle.com wrote:
From: Vegard Nossum vegard.nos...@oracle.com
The idea is simple -- since different kernel versions are vulnerable
On 11/12/13 16:12, Joe Perches wrote:
> seq_printf and seq_puts returns are often misused.
>
> Instead of checking the seq_printf or seq_puts return,
> add a new seq_overflow function to test if a seq_file has
> overflowed the available buffer space.
>
> This will eventually allow seq_printf and
On 11/12/13 16:12, Joe Perches wrote:
seq_printf and seq_puts returns are often misused.
Instead of checking the seq_printf or seq_puts return,
add a new seq_overflow function to test if a seq_file has
overflowed the available buffer space.
This will eventually allow seq_printf and
On 25/11/13 10:38, Johannes Weiner wrote:
> The VM maintains cached filesystem pages on two types of lists. One
> list holds the pages recently faulted into the cache, the other list
> holds pages that have been referenced repeatedly on that first list.
> The idea is to prefer reclaiming young
On 25/11/13 10:38, Johannes Weiner wrote:
The VM maintains cached filesystem pages on two types of lists. One
list holds the pages recently faulted into the cache, the other list
holds pages that have been referenced repeatedly on that first list.
The idea is to prefer reclaiming young pages
On 05/11/13 19:44, Frank Haverkamp wrote:
> Debugfs interfaces for the GenWQE card. Help to debug potential
> problems. Dump internal chip state for debugging and failure
> determination.
>
> Signed-off-by: Frank Haverkamp
> Co-authors: Joerg-Stephan Vogt ,
> Michael Jung ,
>
On 05/11/13 19:44, Frank Haverkamp wrote:
> Sysfs interfaces for the GenWQE card. There are attributes to query
> the version of the bitstream as well as some for the driver. For
> debugging, please also see the debugfs interfaces of this driver.
>
> Signed-off-by: Frank Haverkamp
> Co-authors:
On 05/11/13 19:44, Frank Haverkamp wrote:
Sysfs interfaces for the GenWQE card. There are attributes to query
the version of the bitstream as well as some for the driver. For
debugging, please also see the debugfs interfaces of this driver.
Signed-off-by: Frank Haverkamp
On 05/11/13 19:44, Frank Haverkamp wrote:
Debugfs interfaces for the GenWQE card. Help to debug potential
problems. Dump internal chip state for debugging and failure
determination.
Signed-off-by: Frank Haverkamp ha...@linux.vnet.ibm.com
Co-authors: Joerg-Stephan Vogt jsv...@de.ibm.com,
On 05/11/13 04:08, Frank Haverkamp wrote:
> Selecting interface names via configuration option is obsolete.
Don't do this. You are adding completely new code, so there is no reason
to post a patch full of code that is known to be incorrect, followed by
a set of patches fixing things. Just post
On 05/11/13 04:08, Frank Haverkamp wrote:
Selecting interface names via configuration option is obsolete.
Don't do this. You are adding completely new code, so there is no reason
to post a patch full of code that is known to be incorrect, followed by
a set of patches fixing things. Just post the
On 30/10/13 20:32, Frank Haverkamp wrote:
> From: Frank Haverkamp
> Signed-off-by: Frank Haverkamp
> Co-authors: Joerg-Stephan Vogt ,
> Michael Jung ,
> Michael Ruettger
> ---
> Documentation/ABI/testing/debugfs-driver-genwqe | 57 +
>
On 31/10/13 04:35, Greg KH wrote:
> On Wed, Oct 30, 2013 at 10:32:58AM +0100, Frank Haverkamp wrote:
>> +if GENWQE
>> +
>> +config GENWQE_DEVNAME
>> +string "Name for sysfs and device nodes"
>> +default "genwqe"
>> +help
>> + Select alternate name for sysfs and device
On 31/10/13 04:35, Greg KH wrote:
On Wed, Oct 30, 2013 at 10:32:58AM +0100, Frank Haverkamp wrote:
+if GENWQE
+
+config GENWQE_DEVNAME
+string Name for sysfs and device nodes
+default genwqe
+help
+ Select alternate name for sysfs and device nodes.
Don't
On 30/10/13 20:32, Frank Haverkamp wrote:
From: Frank Haverkamp ha...@vnet.ibm.com
Signed-off-by: Frank Haverkamp ha...@linux.vnet.ibm.com
Co-authors: Joerg-Stephan Vogt jsv...@de.ibm.com,
Michael Jung mij...@de.ibm.com,
Michael Ruettger mich...@ibmra.de
---
cleaner when adding new entries.
>
> Signed-off-by: H Hartley Sweeten
Acked-by: Ryan Mallon
> Cc: Ryan Mallon
> Cc: Alan Stern
> Cc: Lennert Buytenhek
> Cc: Greg Kroah-Hartman
> Cc: Olof Johansson
> Cc: Russell King
> ---
> arch/arm/configs/ep93xx_defconfig
.
Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com
Acked-by: Ryan Mallon rmal...@gmail.com
Cc: Ryan Mallon rmal...@gmail.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Lennert Buytenhek ker...@wantstofly.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Olof Johansson
On 15/10/13 08:35, H Hartley Sweeten wrote:
> Convert ep93xx to use the OHCI platform driver and remove the
> ohci-ep93xx bus glue driver.
>
> Signed-off-by: H Hartley Sweeten
> Cc: Alan Stern
> Cc: Greg Kroah-Hartman
> Cc: Ryan Mallon
Cc'ed Olof, who wanted to see wh
On 15/10/13 02:47, Hartley Sweeten wrote:
> On Friday, October 11, 2013 8:11 PM, Michael Opdenacker wrote:
>> This patch proposes to remove the use of the IRQF_DISABLED flag
>>
>> It's a NOOP since 2.6.35 and it will be removed one day.
>>
>> Signed-off-by: Michael Opdenacker
>> ---
>>
dmesg_restrict.
Signed-off-by: Ryan Mallon
Cc: sta...@vger.kernel.org
---
This is a temporary solution only, but fixes a minor security hole when
kptr_restrict=1. I am working to fix this properly, but there is still
some discussion around how to achieve this, see here:
https://lkml.org/lkml
On 15/10/13 08:35, H Hartley Sweeten wrote:
> Convert ep93xx to use the OHCI platform driver and remove the
> ohci-ep93xx bus glue driver.
>
> Signed-off-by: H Hartley Sweeten
> Cc: Alan Stern
> Cc: Greg Kroah-Hartman
> Cc: Ryan Mallon
> ---
> diff --git a/drivers
On 14/10/13 21:17, Djalal Harouni wrote:
> On Fri, Oct 11, 2013 at 02:19:14PM +1100, Ryan Mallon wrote:
>> On 11/10/13 13:20, Eric W. Biederman wrote:
>>> Joe Perches writes:
>>>
>>>> Some setuid binaries will allow reading of files which have r
On 12/10/13 09:37, Eric W. Biederman wrote:
> Ryan Mallon writes:
>
>> The only remaining problem is kernel/module.c:module_sect_show() which
>> is used to write the sysfs files in /sys/module//sections/.
>> Those files are actually are really good target for leaking
On 12/10/13 09:37, Eric W. Biederman wrote:
Ryan Mallon rmal...@gmail.com writes:
The only remaining problem is kernel/module.c:module_sect_show() which
is used to write the sysfs files in /sys/module/modname/sections/.
Those files are actually are really good target for leaking %pK values
On 14/10/13 21:17, Djalal Harouni wrote:
On Fri, Oct 11, 2013 at 02:19:14PM +1100, Ryan Mallon wrote:
On 11/10/13 13:20, Eric W. Biederman wrote:
Joe Perches j...@perches.com writes:
Some setuid binaries will allow reading of files which have read
permission by the real user id
: Ryan Mallon rmal...@gmail.com
---
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index b3f20d7..2c8f2db 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -472,7 +472,7 @@ config USB_CNS3XXX_OHCI
config USB_OHCI_HCD_PLATFORM
tristate
dmesg_restrict.
Signed-off-by: Ryan Mallon rmal...@gmail.com
Cc: sta...@vger.kernel.org
---
This is a temporary solution only, but fixes a minor security hole when
kptr_restrict=1. I am working to fix this properly, but there is still
some discussion around how to achieve this, see here:
https
On 15/10/13 02:47, Hartley Sweeten wrote:
On Friday, October 11, 2013 8:11 PM, Michael Opdenacker wrote:
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
: Ryan Mallon rmal...@gmail.com
Cc'ed Olof, who wanted to see what the patches looked like.
I think the overall code reduction is probably worth the small increase
in arch/arm code size.
~Ryan
---
arch/arm/mach-ep93xx/clock.c | 2 +-
arch/arm/mach-ep93xx/core.c| 45
On 11/10/13 15:42, George Spelvin wrote:
> ebied...@xmission.com (Eric W. Biederman) wrote:
>> Sigh. This is all wrong. The only correct thing to test is
>> file->f_cred. Aka the capabilities of the program that opened the
>> file.
>>
>> Which means that the interface to %pK in the case of
On 11/10/13 15:42, George Spelvin wrote:
ebied...@xmission.com (Eric W. Biederman) wrote:
Sigh. This is all wrong. The only correct thing to test is
file-f_cred. Aka the capabilities of the program that opened the
file.
Which means that the interface to %pK in the case of kptr_restrict
On 11/10/13 16:38, Joe Perches wrote:
> On Fri, 2013-10-11 at 16:31 +1100, Ryan Mallon wrote:
>> On 11/10/13 16:25, Joe Perches wrote:
>>> Printing kernel pointers via %pK has a minor defect when
>>> kptr_restrict is set to 2: the pointer may be emitted
>>> a
On 11/10/13 16:25, Joe Perches wrote:
> Printing kernel pointers via %pK has a minor defect when
> kptr_restrict is set to 2: the pointer may be emitted
> as "pK-error" instead of all 0's when in an interrupt.
NAK. This is not a defect, as I explained earlier. It is really a defect
that it
On 11/10/13 15:42, George Spelvin wrote:
> ebied...@xmission.com (Eric W. Biederman) wrote:
>> Sigh. This is all wrong. The only correct thing to test is
>> file->f_cred. Aka the capabilities of the program that opened the
>> file.
>>
>> Which means that the interface to %pK in the case of
On 11/10/13 13:20, Eric W. Biederman wrote:
> Joe Perches writes:
>
>> Some setuid binaries will allow reading of files which have read
>> permission by the real user id. This is problematic with files which
>> use %pK because the file access permission is checked at open() time,
>> but the
On 11/10/13 13:20, Eric W. Biederman wrote:
Joe Perches j...@perches.com writes:
Some setuid binaries will allow reading of files which have read
permission by the real user id. This is problematic with files which
use %pK because the file access permission is checked at open() time,
but
On 11/10/13 15:42, George Spelvin wrote:
ebied...@xmission.com (Eric W. Biederman) wrote:
Sigh. This is all wrong. The only correct thing to test is
file-f_cred. Aka the capabilities of the program that opened the
file.
Which means that the interface to %pK in the case of kptr_restrict is
On 11/10/13 16:25, Joe Perches wrote:
Printing kernel pointers via %pK has a minor defect when
kptr_restrict is set to 2: the pointer may be emitted
as pK-error instead of all 0's when in an interrupt.
NAK. This is not a defect, as I explained earlier. It is really a defect
that it _doesn't_
On 11/10/13 16:38, Joe Perches wrote:
On Fri, 2013-10-11 at 16:31 +1100, Ryan Mallon wrote:
On 11/10/13 16:25, Joe Perches wrote:
Printing kernel pointers via %pK has a minor defect when
kptr_restrict is set to 2: the pointer may be emitted
as pK-error instead of all 0's when in an interrupt
On 09/10/13 18:55, Mika Westerberg wrote:
> On Tue, Oct 08, 2013 at 05:00:54PM +0200, Romain Baeriswyl wrote:
>> static void __i2c_dw_enable(struct dw_i2c_dev *dev, bool enable)
>> @@ -286,6 +287,7 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
>> u32 input_clock_khz;
>> u32 hcnt, lcnt;
>>
On 10/10/13 10:09, Joe Perches wrote:
> Changes in V3a:
>
> Do the in_irq tests only when kptr_restrict is 1.
> Document the %pK mechanism in vsnprintf
> Add missing documentation for %pV and %pNF too
I really did mean post a follow-up/separate patch, not a different
version of mine. The
On 10/10/13 09:33, Joe Perches wrote:
> On Thu, 2013-10-10 at 09:25 +1100, Ryan Mallon wrote:
>
>> if (kptr_restrict && (in_irq() || in_serving_softirq() ||
>>in_nmi())) {
>>
>> Is making sure that you don't
On 10/10/13 09:14, Joe Perches wrote:
> On Thu, 2013-10-10 at 09:04 +1100, Ryan Mallon wrote:
>> On 10/10/13 09:00, Joe Perches wrote:
> []
>>> Move the interrupt tests and pK-error printk
>>> into case 1:
>>>
>>> It's the only case where CAP_
On 10/10/13 09:00, Joe Perches wrote:
> On Thu, 2013-10-10 at 08:52 +1100, Ryan Mallon wrote:
>> Some setuid binaries will allow reading of files which have read
>> permission by the real user id. This is problematic with files which
>> use %pK because the file access permissi
-by: Ryan Mallon
---
Changes since v2:
* Fixed typo in comment: 'proccess' -> 'process'
* Use a switch statement for the kptr_restrict values
* Updated the sysctl documentation
Changes since v1:
* Fix the description to say 'vsprintf' instead of 'printk'.
* Clarify the open() vs read() t
-by: Ryan Mallon rmal...@gmail.com
---
Changes since v2:
* Fixed typo in comment: 'proccess' - 'process'
* Use a switch statement for the kptr_restrict values
* Updated the sysctl documentation
Changes since v1:
* Fix the description to say 'vsprintf' instead of 'printk'.
* Clarify the open
On 10/10/13 09:00, Joe Perches wrote:
On Thu, 2013-10-10 at 08:52 +1100, Ryan Mallon wrote:
Some setuid binaries will allow reading of files which have read
permission by the real user id. This is problematic with files which
use %pK because the file access permission is checked at open() time
On 10/10/13 09:14, Joe Perches wrote:
On Thu, 2013-10-10 at 09:04 +1100, Ryan Mallon wrote:
On 10/10/13 09:00, Joe Perches wrote:
[]
Move the interrupt tests and pK-error printk
into case 1:
It's the only case where CAP_SYSLOG needs to be
tested so it doesn't need to be above the switch
On 10/10/13 09:33, Joe Perches wrote:
On Thu, 2013-10-10 at 09:25 +1100, Ryan Mallon wrote:
if (kptr_restrict (in_irq() || in_serving_softirq() ||
in_nmi())) {
Is making sure that you don't have kernel code doing something like this:
irqreturn_t
On 10/10/13 10:09, Joe Perches wrote:
Changes in V3a:
Do the in_irq tests only when kptr_restrict is 1.
Document the %pK mechanism in vsnprintf
Add missing documentation for %pV and %pNF too
I really did mean post a follow-up/separate patch, not a different
version of mine. The missing
On 09/10/13 18:55, Mika Westerberg wrote:
On Tue, Oct 08, 2013 at 05:00:54PM +0200, Romain Baeriswyl wrote:
static void __i2c_dw_enable(struct dw_i2c_dev *dev, bool enable)
@@ -286,6 +287,7 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
u32 input_clock_khz;
u32 hcnt, lcnt;
u32
On 09/10/13 13:00, Joe Perches wrote:
> On Wed, 2013-10-09 at 12:55 +1100, Ryan Mallon wrote:
>> On 09/10/13 12:30, Joe Perches wrote:
>>> On Tue, 2013-10-08 at 17:49 -0700, Joe Perches wrote:
>>>> On Wed, 2013-10-09 at 11:15 +1100, Ryan Mallon wrote:
>>>>
On 09/10/13 12:30, Joe Perches wrote:
> On Tue, 2013-10-08 at 17:49 -0700, Joe Perches wrote:
>> On Wed, 2013-10-09 at 11:15 +1100, Ryan Mallon wrote:
>>> Some setuid binaries will allow reading of files which have read
>>> permission by the real user id. This is p
are equal to the
real ids. If a setuid binary reads the contents of a file which uses
%pK then the pointer values will be printed as NULL if the real user
is unprivileged.
Signed-off-by: Ryan Mallon
---
Changes since v1:
* Fix the description to say 'vsprintf' instead of 'printk'.
* Clarify
are equal to the
real ids. If a setuid binary reads the contents of a file which uses
%pK then the pointer values will be printed as NULL if the real user
is unprivileged.
Signed-off-by: Ryan Mallon rmal...@gmail.com
---
Changes since v1:
* Fix the description to say 'vsprintf' instead of 'printk
On 09/10/13 12:30, Joe Perches wrote:
On Tue, 2013-10-08 at 17:49 -0700, Joe Perches wrote:
On Wed, 2013-10-09 at 11:15 +1100, Ryan Mallon wrote:
Some setuid binaries will allow reading of files which have read
permission by the real user id. This is problematic with files which
use %pK
On 09/10/13 13:00, Joe Perches wrote:
On Wed, 2013-10-09 at 12:55 +1100, Ryan Mallon wrote:
On 09/10/13 12:30, Joe Perches wrote:
On Tue, 2013-10-08 at 17:49 -0700, Joe Perches wrote:
On Wed, 2013-10-09 at 11:15 +1100, Ryan Mallon wrote:
Some setuid binaries will allow reading of files which
On 04/10/13 20:30, Janani Venkataraman wrote:
> From:Suzuki K. Poulose
>
> vma_dump_size calculates the file size of a vma area in the core file. It
> assumes the vma belongs to the "current". Make it generic to work for any
> task.
> This will be reused by application core dump infrastructure.
On 04/10/13 20:30, Janani Venkataraman wrote:
From:Suzuki K. Poulose suz...@in.ibm.com
vma_dump_size calculates the file size of a vma area in the core file. It
assumes the vma belongs to the current. Make it generic to work for any
task.
This will be reused by application core dump
On 04/10/13 10:41, Kees Cook wrote:
> On Wed, Aug 28, 2013 at 1:49 PM, Kees Cook wrote:
>
> BTW, this just came to my attention:
> http://marc.info/?l=linux-kernel=138049414321387=2
>
> Same problem, just for /proc/kallsyms. This would benefit from the
> open vs read cred check as well, I
On 04/10/13 10:41, Kees Cook wrote:
On Wed, Aug 28, 2013 at 1:49 PM, Kees Cook keesc...@chromium.org wrote:
snip
BTW, this just came to my attention:
http://marc.info/?l=linux-kernelm=138049414321387w=2
Same problem, just for /proc/kallsyms. This would benefit from the
open vs read cred
On 02/10/13 11:57, Mathieu Rhéaume wrote:
> This patch changes seq_printf for seq_puts in binder.c.
> It fixes the warnings emitted by checkpatch.pl.
>
> Signed-off-by: Mathieu Rhéaume
> ---
> drivers/staging/android/binder.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>
On 02/10/13 11:57, Mathieu Rhéaume wrote:
This patch changes seq_printf for seq_puts in binder.c.
It fixes the warnings emitted by checkpatch.pl.
Signed-off-by: Mathieu Rhéaume math...@codingrhemes.com
---
drivers/staging/android/binder.c | 6 +++---
1 file changed, 3 insertions(+), 3
On 30/09/13 10:41, Dan Rosenberg wrote:
> On 09/29/2013 07:41 PM, George Spelvin wrote:
>>> Right, so the pppd application is actually doing the correct thing.
>> And a CAP_SYSLOG setuid binary that *doesn't* DTRT seems like a more
>> immediate security hole than leaking kernel addresses. After
On 30/09/13 09:15, George Spelvin wrote:
> The basic idea is good, but I'm not sure if this is the correct permission
> check to use.
>
> After all, a setuid program might also want to give filtered access to
> a /proc file with some %pK values.
Yeah. I'm not sure if this will break some
if the real user is unprivileged.
Signed-off-by: Ryan Mallon
---
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 26559bd..b1cd14d 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1312,10 +1312,24 @@ char *pointer(const char *fmt, char *buf, char *end,
void *ptr
if the real user is unprivileged.
Signed-off-by: Ryan Mallon rmal...@gmail.com
---
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 26559bd..b1cd14d 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1312,10 +1312,24 @@ char *pointer(const char *fmt, char *buf, char *end,
void *ptr
On 30/09/13 09:15, George Spelvin wrote:
The basic idea is good, but I'm not sure if this is the correct permission
check to use.
After all, a setuid program might also want to give filtered access to
a /proc file with some %pK values.
Yeah. I'm not sure if this will break some applications
On 30/09/13 10:41, Dan Rosenberg wrote:
On 09/29/2013 07:41 PM, George Spelvin wrote:
Right, so the pppd application is actually doing the correct thing.
And a CAP_SYSLOG setuid binary that *doesn't* DTRT seems like a more
immediate security hole than leaking kernel addresses. After all
On 23/09/13 12:16, Joe Perches wrote:
> On Mon, 2013-09-23 at 11:59 +1000, Ryan Mallon wrote:
>> This seems like a lot of code churn for very little benefit. At a quick
>> glance:
>>
>> git grep extern include/ | wc -l
>> 11427
>>
>> Not all of tho
On 23/09/13 03:32, Joe Perches wrote:
> There are a mix of function prototypes with and without extern
> in the kernel sources. Standardize on not using extern for
> function prototypes.
>
> Function prototypes don't need to be written with extern.
> extern is assumed by the compiler. Its use
On 23/09/13 03:32, Joe Perches wrote:
There are a mix of function prototypes with and without extern
in the kernel sources. Standardize on not using extern for
function prototypes.
Function prototypes don't need to be written with extern.
extern is assumed by the compiler. Its use is as
On 23/09/13 12:16, Joe Perches wrote:
On Mon, 2013-09-23 at 11:59 +1000, Ryan Mallon wrote:
This seems like a lot of code churn for very little benefit. At a quick
glance:
git grep extern include/ | wc -l
11427
Not all of those will need to be removed, but that is still a huge
number
1 - 100 of 278 matches
Mail list logo
