user/sven/linux.git/lib/vsprintf.c, branch v3.18.24

lib/vsprintf: add %*pE[achnops] format specifier

2014-10-14T00:18:26Z

This allows user to print a given buffer as an escaped string. The rules are applied according to an optional mix of flags provided by additional format letters. For example, if the given buffer is: 1b 62 20 5c 43 07 22 90 0d 5d The result strings would be: %*pE "\eb \C\a"\220\r]" %*pEhp "\x1bb \C\x07"\x90\x0d]" %*pEa "\e\142\040\\\103\a\042\220\r\135" Please, read Documentation/printk-formats.txt and lib/string_helpers.c kernel documentation to get further information. [akpm@linux-foundation.org: tidy up comment layout, per Joe] Signed-off-by: Andy Shevchenko Suggested-by: Joe Perches Cc: "John W . Linville" Cc: Johannes Berg Cc: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Documentation: Docbook: Fix generated DocBook/kernel-api.xml

2014-09-09T08:34:56Z

This patch fix spelling typo found in DocBook/kernel-api.xml. It is because the file is generated from the source comments, I have to fix the comments in source codes. Signed-off-by: Masanari Iida Acked-by: Randy Dunlap Signed-off-by: Jiri Kosina

lib/vsprintf.c: fix comparison to bool

2014-06-04T23:54:18Z

Fixing 2 coccinelle warnings: lib/vsprintf.c:2350:2-9: WARNING: Assignment of bool to 0/1 lib/vsprintf.c:2389:3-10: WARNING: Assignment of bool to 0/1 Signed-off-by: Fabian Frederick Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

vsprintf: remove %n handling

2014-04-03T23:21:07Z

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 Mallon Acked-by: Kees Cook Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

vsprintf: Add support for IORESOURCE_UNSET in %pR

2014-02-26T21:42:09Z

Sometimes we have a struct resource where we know the type (MEM/IO/etc.) and the size, but we haven't assigned address space for it. The IORESOURCE_UNSET flag is a way to indicate this situation. For these "unset" resources, the start address is meaningless, so print only the size, e.g., - pci 0000:0c:00.0: reg 184: [mem 0x00000000-0x00001fff 64bit] + pci 0000:0c:00.0: reg 184: [mem size 0x2000 64bit] For %pr (printing with raw flags), we still print the address range, because %pr is mostly used for debugging anyway. Thanks to Fengguang Wu for suggesting resource_size(). Signed-off-by: Bjorn Helgaas

vsprintf: add %pad extension for dma_addr_t use

2014-01-24T00:36:56Z

dma_addr_t's can be either u32 or u64 depending on a CONFIG option. There are a few hundred dma_addr_t's printed via either cast to unsigned long long, unsigned long or no cast at all. Add %pad to be able to emit them without the cast. Update Documentation/printk-formats.txt too. Signed-off-by: Joe Perches Cc: "Shevchenko, Andriy" Cc: Rob Landley Cc: Laurent Pinchart Cc: Julia Lawall Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

vsprintf: ignore %n again

2013-11-15T00:32:20Z

This ignores %n in printf again, as was originally documented. Implementing %n poses a greater security risk than utility, so it should stay ignored. To help anyone attempting to use %n, a warning will be emitted if it is encountered. Based on an earlier patch by Joe Perches. Because %n was designed to write to pointers on the stack, it has been frequently used as an attack vector when bugs are found that leak user-controlled strings into functions that ultimately process format strings. While this class of bug can still be turned into an information leak, removing %n eliminates the common method of elevating such a bug into an arbitrary kernel memory writing primitive, significantly reducing the danger of this class of bug. For seq_file users that need to know the length of a written string for padding, please see seq_setwidth() and seq_pad() instead. Signed-off-by: Kees Cook Cc: Joe Perches Cc: Tetsuo Handa Cc: David Miller Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

lib/vsprintf.c: document formats for dentry and struct file

2013-11-13T03:09:22Z

Looks like these were added to Documentation/printk-formats.txt but not the in-file table. Signed-off-by: Olof Johansson Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

vsprintf: check real user/group id for %pK

2013-11-13T03:09:14Z

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 kptr_restrict setting is checked at read() time. If a setuid binary opens a %pK file as an unprivileged user, and then elevates permissions before reading the file, then kernel pointer values may be leaked. This happens for example with the setuid pppd application on Ubuntu 12.04: $ head -1 /proc/kallsyms 00000000 T startup_32 $ pppd file /proc/kallsyms pppd: In file /proc/kallsyms: unrecognized option 'c1000000' This will only leak the pointer value from the first line, but other setuid binaries may leak more information. Fix this by adding a check that in addition to the current process having CAP_SYSLOG, that effective user and group ids 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. Update the sysctl documentation to reflect the changes, and also correct the documentation to state the kptr_restrict=0 is the default. This is a only temporary solution to the issue. The correct solution is to do the permission check at open() time on files, and to replace %pK with a function which checks the open() time permission. %pK uses in printk should be removed since no sane permission check can be done, and instead protected by using dmesg_restrict. Signed-off-by: Ryan Mallon Cc: Kees Cook Cc: Alexander Viro Cc: Joe Perches Cc: "Eric W. Biederman" Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

add formats for dentry/file pathnames

2013-09-04T04:13:11Z

New formats: %p[dD][234]?. The next pointer is interpreted as struct dentry * or struct file * resp. ('d' => dentry, 'D' => file) and the last component(s) of pathname are printed (%pd => just the last one, %pd2 => the last two, etc.) Signed-off-by: Al Viro