linux.git/lib/vsprintf.c, branch v5.9-rc2

lib/vsprintf: Force type of flags value for gfp_t

2020-08-01T03:52:57+00:00

Sparse is not happy about restricted type being assigned:
  lib/vsprintf.c:1940:23: warning: incorrect type in assignment (different base types)
  lib/vsprintf.c:1940:23:    expected unsigned long [assigned] flags
  lib/vsprintf.c:1940:23:    got restricted gfp_t [usertype]

Force type of flags value to make sparse happy.

Signed-off-by: Andy Shevchenko 
Reviewed-by: Steven Rostedt (VMware) 
Link: https://lore.kernel.org/r/20200731180825.30575-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Sergey Senozhatsky

lib/vsprintf: Replace custom spec to print decimals with generic one

2020-08-01T03:52:36+00:00

When printing phandle via %pOFp the custom spec is used. First of all,
it has a SMALL flag which makes no sense for decimal numbers. Second,
we have already default spec for decimal numbers. Use the latter in
the %pOFp case as well.

Signed-off-by: Andy Shevchenko 
Reviewed-by: Steven Rostedt (VMware) 
Reviewed-by: Sergey Senozhatsky 
Cc: Pantelis Antoniou 
Cc: Rob Herring 
Cc: Joe Perches 
Cc: Grant Likely 
Link: https://lore.kernel.org/r/20200731180825.30575-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Sergey Senozhatsky

lib/vsprintf: Replace hidden BUILD_BUG_ON() with static_assert()

2020-08-01T03:52:32+00:00

First of all, there is no compile time check for the SMALL
to be ' ' (0x20, i.e. space). Second, for ZEROPAD the check
is hidden in the code.

For better maintenance replace BUILD_BUG_ON() with static_assert()
for ZEROPAD and move it closer to the definition. While at it,
introduce check for SMALL.

Signed-off-by: Andy Shevchenko 
Reviewed-by: Steven Rostedt (VMware) 
Reviewed-by: Sergey Senozhatsky 
Link: https://lore.kernel.org/r/20200731180825.30575-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Sergey Senozhatsky

Replace HTTP links with HTTPS ones: vsprintf

2020-07-03T12:07:00+00:00

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
    For each line:
      If doesn't contain `\bxmlns\b`:
        For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
          If both the HTTP and HTTPS versions
          return 200 OK and serve the same content:
            Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
Reviewed-by: Petr Mladek 
Reviewed-by: Sergey Senozhatsky 
Signed-off-by: Petr Mladek 
Link: https://lore.kernel.org/r/20200702200536.13389-1-grandmaster@al2klimov.de

Merge tag 'printk-for-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux

2020-06-01T19:13:30+00:00

Pull printk updates from Petr Mladek:

 - Benjamin Herrenschmidt solved a problem with non-matched console
   aliases by first checking consoles defined on the command line. It is
   a more conservative approach than the previous attempts.

 - Benjamin also made sure that the console accessible via /dev/console
   always has CON_CONSDEV flag.

 - Andy Shevchenko added the %ptT modifier for printing struct time64_t.
   It extends the existing %ptR handling for struct rtc_time.

 - Bruno Meneguele fixed /dev/kmsg error value returned by unsupported
   SEEK_CUR.

 - Tetsuo Handa removed unused pr_cont_once().

... and a few small fixes.

* tag 'printk-for-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux:
  printk: Remove pr_cont_once()
  printk: handle blank console arguments passed in.
  kernel/printk: add kmsg SEEK_CUR handling
  printk: Fix a typo in comment "interator"->"iterator"
  usb: pulse8-cec: Switch to use %ptT
  ARM: bcm2835: Switch to use %ptT
  lib/vsprintf: Print time64_t in human readable format
  lib/vsprintf: update comment about simple_strto() functions
  printk: Correctly set CON_CONSDEV even when preferred console was not registered
  printk: Fix preferred console selection with multiple matches
  printk: Move console matching logic into a separate function
  printk: Convert a use of sprintf to snprintf in console_unlock

Merge branch 'for-5.8-printf-time64_t' into for-linus

2020-06-01T08:15:43+00:00

lib/vsprintf: Print time64_t in human readable format

2020-05-20T12:54:18+00:00

There are users which print time and date represented by content of
time64_t type in human readable format.

Instead of open coding that each time introduce %ptT[dt][r] specifier.

Few test cases for %ptT specifier has been added as well.

Link: https://lore.kernel.org/r/20200415170046.33374-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko 
Reviewed-by: Alexandre Belloni 
Acked-by: Sergey Senozhatsky 
Rewieved-by: Petr Mladek 
Signed-off-by: Petr Mladek

vsprintf: don't obfuscate NULL and error pointers

2020-05-19T18:35:38+00:00

I don't see what security concern is addressed by obfuscating NULL
and IS_ERR() error pointers, printed with %p/%pK.  Given the number
of sites where %p is used (over 10000) and the fact that NULL pointers
aren't uncommon, it probably wouldn't take long for an attacker to
find the hash that corresponds to 0.  Although harder, the same goes
for most common error values, such as -1, -2, -11, -14, etc.

The NULL part actually fixes a regression: NULL pointers weren't
obfuscated until commit 3e5903eb9cff ("vsprintf: Prevent crash when
dereferencing invalid pointers") which went into 5.2.  I'm tacking
the IS_ERR() part on here because error pointers won't leak kernel
addresses and printing them as pointers shouldn't be any different
from e.g. %d with PTR_ERR_OR_ZERO().  Obfuscating them just makes
debugging based on existing pr_debug and friends excruciating.

Note that the "always print 0's for %pK when kptr_restrict == 2"
behaviour which goes way back is left as is.

Example output with the patch applied:

                             ptr         error-ptr              NULL
 %p:            0000000001f8cc5b  fffffffffffffff2  0000000000000000
 %pK, kptr = 0: 0000000001f8cc5b  fffffffffffffff2  0000000000000000
 %px:           ffff888048c04020  fffffffffffffff2  0000000000000000
 %pK, kptr = 1: ffff888048c04020  fffffffffffffff2  0000000000000000
 %pK, kptr = 2: 0000000000000000  0000000000000000  0000000000000000

Fixes: 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers")
Signed-off-by: Ilya Dryomov 
Reviewed-by: Petr Mladek 
Reviewed-by: Sergey Senozhatsky 
Reviewed-by: Andy Shevchenko 
Acked-by: Steven Rostedt (VMware) 
Signed-off-by: Linus Torvalds

bpf: Restrict bpf_trace_printk()'s %s usage and add %pks, %pus specifier

2020-05-15T15:10:36+00:00

Usage of plain %s conversion specifier in bpf_trace_printk() suffers from the
very same issue as bpf_probe_read{,str}() helpers, that is, it is broken on
archs with overlapping address ranges.

While the helpers have been addressed through work in 6ae08ae3dea2 ("bpf: Add
probe_read_{user, kernel} and probe_read_{user, kernel}_str helpers"), we need
an option for bpf_trace_printk() as well to fix it.

Similarly as with the helpers, force users to make an explicit choice by adding
%pks and %pus specifier to bpf_trace_printk() which will then pick the corresponding
strncpy_from_unsafe*() variant to perform the access under KERNEL_DS or USER_DS.
The %pk* (kernel specifier) and %pu* (user specifier) can later also be extended
for other objects aside strings that are probed and printed under tracing, and
reused out of other facilities like bpf_seq_printf() or BTF based type printing.

Existing behavior of %s for current users is still kept working for archs where it
is not broken and therefore gated through CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE.
For archs not having this property we fall-back to pick probing under KERNEL_DS as
a sensible default.

Fixes: 8d3b7dce8622 ("bpf: add support for %s specifier to bpf_trace_printk()")
Reported-by: Linus Torvalds 
Reported-by: Christoph Hellwig 
Signed-off-by: Daniel Borkmann 
Signed-off-by: Alexei Starovoitov 
Cc: Masami Hiramatsu 
Cc: Brendan Gregg 
Link: https://lore.kernel.org/bpf/20200515101118.6508-4-daniel@iogearbox.net

lib/vsprintf: update comment about simple_strto() functions

2020-02-28T14:38:31+00:00

The commit 885e68e8b7b1 ("kernel.h: update comment about simple_strto()
functions") updated a comment regard to simple_strto() functions, but
missed similar change in the vsprintf.c module.

Update comments in vsprintf.c as well for simple_strto() functions.

Link: https://lore.kernel.org/r/20200221085723.42469-1-andriy.shevchenko@linux.intel.com
Reported-by: Uwe Kleine-König 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Petr Mladek