Skip to content

Please revert the accident pull request and use this if you want.#3

Open
ghost wants to merge 143 commits into187MoD:masterfrom
Blazko381:Ares-Smg-10
Open

Please revert the accident pull request and use this if you want.#3
ghost wants to merge 143 commits into187MoD:masterfrom
Blazko381:Ares-Smg-10

Conversation

@ghost
Copy link
Copy Markdown

@ghost ghost commented Jun 17, 2020

This one isn't messy on commits. This includes basic support for android 10 (still need to add full support for los17.1), smartdim feature, and add upstream changes.

SmgKhOaRn and others added 30 commits June 17, 2020 12:19
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
commit 2c956a60778cbb6a27e0c7a8a52a91378c90e1d1 upstream.

SipHash is a 64-bit keyed hash function that is actually a
cryptographically secure PRF, like HMAC. Except SipHash is super fast,
and is meant to be used as a hashtable keyed lookup function, or as a
general PRF for short input use cases, such as sequence numbers or RNG
chaining.

For the first usage:

There are a variety of attacks known as "hashtable poisoning" in which an
attacker forms some data such that the hash of that data will be the
same, and then preceeds to fill up all entries of a hashbucket. This is
a realistic and well-known denial-of-service vector. Currently
hashtables use jhash, which is fast but not secure, and some kind of
rotating key scheme (or none at all, which isn't good). SipHash is meant
as a replacement for jhash in these cases.

There are a modicum of places in the kernel that are vulnerable to
hashtable poisoning attacks, either via userspace vectors or network
vectors, and there's not a reliable mechanism inside the kernel at the
moment to fix it. The first step toward fixing these issues is actually
getting a secure primitive into the kernel for developers to use. Then
we can, bit by bit, port things over to it as deemed appropriate.

While SipHash is extremely fast for a cryptographically secure function,
it is likely a bit slower than the insecure jhash, and so replacements
will be evaluated on a case-by-case basis based on whether or not the
difference in speed is negligible and whether or not the current jhash usage
poses a real security risk.

For the second usage:

A few places in the kernel are using MD5 or SHA1 for creating secure
sequence numbers, syn cookies, port numbers, or fast random numbers.
SipHash is a faster and more fitting, and more secure replacement for MD5
in those situations. Replacing MD5 and SHA1 with SipHash for these uses is
obvious and straight-forward, and so is submitted along with this patch
series. There shouldn't be much of a debate over its efficacy.

Dozens of languages are already using this internally for their hash
tables and PRFs. Some of the BSDs already use this in their kernels.
SipHash is a widely known high-speed solution to a widely known set of
problems, and it's time we catch-up.

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Eric Biggers <ebiggers3@gmail.com>
Cc: David Laight <David.Laight@aculab.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I0af6b25995c1d4f77b1f6c3467571abe54ad182e
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
For some reason, External Connector Class (extcon) breaks headset.

Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Added Smart Dim

Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
commit 19bce474c45be69a284ecee660aa12d8f1e88f18 upstream.

`check_input_term` recursively calls itself with input from
device side (e.g., uac_input_terminal_descriptor.bCSourceID)
as argument (id). In `check_input_term`, if `check_input_term`
is called with the same `id` argument as the caller, it triggers
endless recursive call, resulting kernel space stack overflow.

This patch fixes the bug by adding a bitmap to `struct mixer_build`
to keep track of the checked ids and stop the execution if some id
has been checked (similar to how parse_audio_unit handles unitid
argument).

Reported-by: Hui Peng <benquike@gmail.com>
Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
Signed-off-by: Hui Peng <benquike@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2019-15118
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I634e09d321549304e98012c09ef2c35cd50aa3ac
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Check payload size to avoid out-of-boundary memory
access before attemptimg memory read.

Change-Id: Id22f5c4e50c788053a0529e2d252e497991e1a38
Signed-off-by: Soumya Managoli <smanag@codeaurora.org>
[haggertk: Backport to 3.4/msm8974. Path change.]
CVE-2019-10626
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
* Proper resolution of a UAF CVE requires nulling clk_ptr[i]
  but this log message requires dereferencing this item. The
  log message is worthless, so ditch it.

Change-Id: I07d21ff30ef4d2908f2fd1036921773ded32ef24
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
currently only NULL pointer check is used to validate the return
value from clk_get, this change to handle all the failures.
This snapshot is taken from msm-4.9
Ported it from 4.9 to 3.18

Change-Id: Icd8b7e33d0f235a7c5dde2307972a594908e6a60
Signed-off-by: Sumalatha Malothu <smalot@codeaurora.org>
[haggertk: Backport to 3.4/msm8974. Note that this includes patching
 the non-standard camera_ll implementation as well on this kernel.]
CVE-2019-10524
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
XFRM mode parameters passed as part of the user templates
in the IP_XFRM_POLICY are never properly validated. Passing
values other than valid XFRM modes can cause stack-out-of-bounds
reads to occur later in the XFRM processing:

[  140.535608] ================================================================
[  140.543058] BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x17e4/0x1cc4
[  140.550306] Read of size 4 at addr ffffffc0238a7a58 by task repro/5148
[  140.557369]
[  140.558927] Call trace:
[  140.558936] dump_backtrace+0x0/0x388
[  140.558940] show_stack+0x24/0x30
[  140.558946] __dump_stack+0x24/0x2c
[  140.558949] dump_stack+0x8c/0xd0
[  140.558956] print_address_description+0x74/0x234
[  140.558960] kasan_report+0x240/0x264
[  140.558963] __asan_report_load4_noabort+0x2c/0x38
[  140.558967] xfrm_state_find+0x17e4/0x1cc4
[  140.558971] xfrm_resolve_and_create_bundle+0x40c/0x1fb8
[  140.558975] xfrm_lookup+0x238/0x1444
[  140.558977] xfrm_lookup_route+0x48/0x11c
[  140.558984] ip_route_output_flow+0x88/0xc4
[  140.558991] raw_sendmsg+0xa74/0x266c
[  140.558996] inet_sendmsg+0x258/0x3b0
[  140.559002] sock_sendmsg+0xbc/0xec
[  140.559005] SyS_sendto+0x3a8/0x5a8
[  140.559008] el0_svc_naked+0x34/0x38
[  140.559009]
[  140.592245] page dumped becaus: kasan: bad access detected
[  140.597981] page_owner info is not active (free page?)
[  140.603267]
[  140.653503] ================================================================

Change-Id: I5d2fa78a9d950c79d83d759bfd4d0f399fed18a4
Signed-off-by: Sean Tranchetti <stranche@codeaurora.org>
CVE-2019-14053
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
For ADM_CMDRSP_GET_PP_PARAMS_V5 cmd response,
the check for data payload_size is incorrect.
Modify the check condition to make sure there
is enough data to copy, size is contained in
payload[3].

Change-Id: I2f155ad8b302e89131ee85cfc72e4009dda617d3
Signed-off-by: Soumya Managoli <smanag@codeaurora.org>
CVE-2019-14038
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Do not return 0 if msm_get_session fails on session_id.

Change-Id: Iad8b72e33c3a613da3f16693fce9aaf862de9ac5
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Add dev_*_ratelimited() family, dev_* version of pr_*_ratelimited().

Using Joe Perches's proposal/implementation.

Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I6f0f4f8f61de2dd5331eff202b66c931700bbf27
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Ratelimit log in msm_vb2_buf_cleanup to prevent excessive logging when
stream is NULL.

Change-Id: Ia687375c8e2a2683a4d32cd0eb984f731b2288e7
Signed-off-by: Trishansh Bhardwaj <tbhardwa@codeaurora.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
The camera generic buffer manager and isp buffer
manager keep references of vb2 buffers locally during
buffer circulation. If for some reason the vb2 buffers
are freed from a cleanup call from mediaserver. The memory
for the buffers is freed. But the camera buffer managers
still access them for a fraction of time before the cleanup
call is triggered from daemon process. Hence make sure
to access the vb2 buffers only after checking for
the existence in vb2 queues to avoid memory corruption.

Change-Id: I7a1e5f9a3af3345e0c37d3208facbab107a6b9ed
Signed-off-by: Lakshmi Narayana Kalavala <lkalaval@codeaurora.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
There is no syncronization between msm_vb2_get_buf
and msm_delete_stream which can lead to use after
free.
Fixed it by using read/write lock.

Change-Id: I8e80d70ec866253aab8836457a28ae14175f5d61
Signed-off-by: Manish Poddar <mpoddar@codeaurora.org>
Signed-off-by: Trishansh Bhardwaj <tbhardwa@codeaurora.org>
[haggertk: Backport to 3.4/msm8974. Note that this includes patching
 the non-standard camera_ll implementation as well on this kernel.]
CVE-2017-9704
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Prevent deadlock between tasklet and delete_stream by stopping
irq during delete_stream.

CRs-Fixed: 2076578
Change-Id: Ibcc9fd44403d24112b01150a7d1f3c6e705ea99a
Signed-off-by: Trishansh Bhardwaj <tbhardwa@codeaurora.org>
Signed-off-by: VijayaKumar T M <vtmuni@codeaurora.org>
CVE-2017-9704
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
commit 513dc792d6060d5ef572e43852683097a8420f56 upstream.

When syzkaller tests, there is a UAF:
  BUG: KASan: use after free in vgacon_invert_region+0x9d/0x110 at addr
    ffff880000100000
  Read of size 2 by task syz-executor.1/16489
  page:ffffea0000004000 count:0 mapcount:-127 mapping:          (null)
  index:0x0
  page flags: 0xfffff00000000()
  page dumped because: kasan: bad access detected
  CPU: 1 PID: 16489 Comm: syz-executor.1 Not tainted
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
  rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
  Call Trace:
    [<ffffffffb119f309>] dump_stack+0x1e/0x20
    [<ffffffffb04af957>] kasan_report+0x577/0x950
    [<ffffffffb04ae652>] __asan_load2+0x62/0x80
    [<ffffffffb090f26d>] vgacon_invert_region+0x9d/0x110
    [<ffffffffb0a39d95>] invert_screen+0xe5/0x470
    [<ffffffffb0a21dcb>] set_selection+0x44b/0x12f0
    [<ffffffffb0a3bfae>] tioclinux+0xee/0x490
    [<ffffffffb0a1d114>] vt_ioctl+0xff4/0x2670
    [<ffffffffb0a0089a>] tty_ioctl+0x46a/0x1a10
    [<ffffffffb052db3d>] do_vfs_ioctl+0x5bd/0xc40
    [<ffffffffb052e2f2>] SyS_ioctl+0x132/0x170
    [<ffffffffb11c9b1b>] system_call_fastpath+0x22/0x27
    Memory state around the buggy address:
     ffff8800000fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     00 00
     ffff8800000fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00
     00 00 00
    >ffff880000100000: ff ff ff ff ff ff ff ff ff ff ff ff ff
     ff ff ff

It can be reproduce in the linux mainline by the program:
  #include <stdio.h>
  #include <stdlib.h>
  #include <unistd.h>
  #include <fcntl.h>
  #include <sys/types.h>
  #include <sys/stat.h>
  #include <sys/ioctl.h>
  #include <linux/vt.h>

  struct tiocl_selection {
    unsigned short xs;      /* X start */
    unsigned short ys;      /* Y start */
    unsigned short xe;      /* X end */
    unsigned short ye;      /* Y end */
    unsigned short sel_mode; /* selection mode */
  };

  #define TIOCL_SETSEL    2
  struct tiocl {
    unsigned char type;
    unsigned char pad;
    struct tiocl_selection sel;
  };

  int main()
  {
    int fd = 0;
    const char *dev = "/dev/char/4:1";

    struct vt_consize v = {0};
    struct tiocl tioc = {0};

    fd = open(dev, O_RDWR, 0);

    v.v_rows = 3346;
    ioctl(fd, VT_RESIZEX, &v);

    tioc.type = TIOCL_SETSEL;
    ioctl(fd, TIOCLINUX, &tioc);

    return 0;
  }

When resize the screen, update the 'vc->vc_size_row' to the new_row_size,
but when 'set_origin' in 'vgacon_set_origin', vgacon use 'vga_vram_base'
for 'vc_origin' and 'vc_visible_origin', not 'vc_screenbuf'. It maybe
smaller than 'vc_screenbuf'. When TIOCLINUX, use the new_row_size to calc
the offset, it maybe larger than the vga_vram_size in vgacon driver, then
bad access.
Also, if set an larger screenbuf firstly, then set an more larger
screenbuf, when copy old_origin to new_origin, a bad access may happen.

So, If the screen size larger than vga_vram, resize screen should be
failed. This alse fix CVE-2020-8649 and CVE-2020-8647.

Linus pointed out that overflow checking seems absent. We're saved by
the existing bounds checks in vc_do_resize() with rather strict
limits:

	if (cols > VC_RESIZE_MAXCOL || lines > VC_RESIZE_MAXROW)
		return -EINVAL;

Fixes: 0aec4867dca14 ("[PATCH] SVGATextMode fix")
Reference: CVE-2020-8647 and CVE-2020-8649
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
[danvet: augment commit message to point out overflow safety]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304022429.37738-1-zhangxiaoxu5@huawei.com
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2020-8647
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I38134ca1efd924ba852e4c1723a5924399c68f24
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
commit 07e6124a1a46b4b5a9b3cacc0c306b50da87abf5 upstream.

syzkaller reported this UAF:
BUG: KASAN: use-after-free in n_tty_receive_buf_common+0x2481/0x2940 drivers/tty/n_tty.c:1741
Read of size 1 at addr ffff8880089e40e9 by task syz-executor.1/13184

CPU: 0 PID: 13184 Comm: syz-executor.1 Not tainted 5.4.7 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
Call Trace:
...
 kasan_report+0xe/0x20 mm/kasan/common.c:634
 n_tty_receive_buf_common+0x2481/0x2940 drivers/tty/n_tty.c:1741
 tty_ldisc_receive_buf+0xac/0x190 drivers/tty/tty_buffer.c:461
 paste_selection+0x297/0x400 drivers/tty/vt/selection.c:372
 tioclinux+0x20d/0x4e0 drivers/tty/vt/vt.c:3044
 vt_ioctl+0x1bcf/0x28d0 drivers/tty/vt/vt_ioctl.c:364
 tty_ioctl+0x525/0x15a0 drivers/tty/tty_io.c:2657
 vfs_ioctl fs/ioctl.c:47 [inline]

It is due to a race between parallel paste_selection (TIOCL_PASTESEL)
and set_selection_user (TIOCL_SETSEL) invocations. One uses sel_buffer,
while the other frees it and reallocates a new one for another
selection. Add a mutex to close this race.

The mutex takes care properly of sel_buffer and sel_buffer_lth only. The
other selection global variables (like sel_start, sel_end, and sel_cons)
are protected only in set_selection_user. The other functions need quite
some more work to close the races of the variables there. This is going
to happen later.

This likely fixes (I am unsure as there is no reproducer provided) bug
206361 too. It was marked as CVE-2020-8648.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-by: syzbot+59997e8d5cbdc486e6f6@syzkaller.appspotmail.com
References: https://bugzilla.kernel.org/show_bug.cgi?id=206361
Link: https://lore.kernel.org/r/20200210081131.23572-2-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: Ibc7d5164460fab68ca2d247a86c28c8077a76cf4
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
commit 4b70dd57a15d2f4685ac6e38056bad93e81e982f upstream.

We need to nest the console lock in sel_lock, so we have to push it down
a bit. Fortunately, the callers of set_selection_* just lock the console
lock around the function call. So moving it down is easy.

In the next patch, we switch the order.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Fixes: 07e6124a1a46 ("vt: selection, close sel_buffer race")
Link: https://lore.kernel.org/r/20200228115406.5735-1-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2020-8648
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: If732e6acb1aab4d19379e2494e10cf2085e6ac65
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
commit e8c75a30a23c6ba63f4ef6895cbf41fd42f21aa2 upstream.

sel_lock cannot nest in the console lock. Thanks to syzkaller, the
kernel states firmly:

> WARNING: possible circular locking dependency detected
> 5.6.0-rc3-syzkaller #0 Not tainted
> ------------------------------------------------------
> syz-executor.4/20336 is trying to acquire lock:
> ffff8880a2e952a0 (&tty->termios_rwsem){++++}, at: tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
>
> but task is already holding lock:
> ffffffff89462e70 (sel_lock){+.+.}, at: paste_selection+0x118/0x470 drivers/tty/vt/selection.c:374
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #2 (sel_lock){+.+.}:
>        mutex_lock_nested+0x1b/0x30 kernel/locking/mutex.c:1118
>        set_selection_kernel+0x3b8/0x18a0 drivers/tty/vt/selection.c:217
>        set_selection_user+0x63/0x80 drivers/tty/vt/selection.c:181
>        tioclinux+0x103/0x530 drivers/tty/vt/vt.c:3050
>        vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364

This is ioctl(TIOCL_SETSEL).
Locks held on the path: console_lock -> sel_lock

> -> #1 (console_lock){+.+.}:
>        console_lock+0x46/0x70 kernel/printk/printk.c:2289
>        con_flush_chars+0x50/0x650 drivers/tty/vt/vt.c:3223
>        n_tty_write+0xeae/0x1200 drivers/tty/n_tty.c:2350
>        do_tty_write drivers/tty/tty_io.c:962 [inline]
>        tty_write+0x5a1/0x950 drivers/tty/tty_io.c:1046

This is write().
Locks held on the path: termios_rwsem -> console_lock

> -> #0 (&tty->termios_rwsem){++++}:
>        down_write+0x57/0x140 kernel/locking/rwsem.c:1534
>        tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
>        mkiss_receive_buf+0x12aa/0x1340 drivers/net/hamradio/mkiss.c:902
>        tty_ldisc_receive_buf+0x12f/0x170 drivers/tty/tty_buffer.c:465
>        paste_selection+0x346/0x470 drivers/tty/vt/selection.c:389
>        tioclinux+0x121/0x530 drivers/tty/vt/vt.c:3055
>        vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364

This is ioctl(TIOCL_PASTESEL).
Locks held on the path: sel_lock -> termios_rwsem

> other info that might help us debug this:
>
> Chain exists of:
>   &tty->termios_rwsem --> console_lock --> sel_lock

Clearly. From the above, we have:
 console_lock -> sel_lock
 sel_lock -> termios_rwsem
 termios_rwsem -> console_lock

Fix this by reversing the console_lock -> sel_lock dependency in
ioctl(TIOCL_SETSEL). First, lock sel_lock, then console_lock.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-by: syzbot+26183d9746e62da329b8@syzkaller.appspotmail.com
Fixes: 07e6124a1a46 ("vt: selection, close sel_buffer race")
Link: https://lore.kernel.org/r/20200228115406.5735-2-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2020-8648
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I9ee48b7939bfe3973b95f0487898c06f50fdf418
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Based on commit 7bc04c5c2cc4 "ext4: fix use-after-free race with
debug_want_extra_isize".  We don't have that bug but this will make it
easier to backport commit 4ea99936a163 "ext4: add more paranoia
checking in ext4_expand_extra_isize handling".

Cc: Barret Rhoden <brho@google.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: Id1aa83660b3f32381c9275373773854e1e197b87
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
commit 4ea99936a1630f51fc3a2d61a58ec4a1c4b7d55a upstream.

It's possible to specify a non-zero s_want_extra_isize via debugging
option, and this can cause bad things(tm) to happen when using a file
system with an inode size of 128 bytes.

Add better checking when the file system is mounted, as well as when
we are actually doing the trying to do the inode expansion.

Link: https://lore.kernel.org/r/20191110121510.GH23325@mit.edu
Reported-by: syzbot+f8d6f8386ceacdbfff57@syzkaller.appspotmail.com
Reported-by: syzbot+33d7ea72e47de3bdf4e1@syzkaller.appspotmail.com
Reported-by: syzbot+44b6763edfc17144296f@syzkaller.appspotmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
[bwh: Backported to 3.16:
 - Use EIO instead of EFSCORRUPTED
 - Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2019-19767
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I0eaa4612f0c3c11951128c8a5fb1536bd6e0f12b
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
If f2fs_new_inode() is failed, the bad inode will invalidate 0'th node page
during f2fs_evict_inode(), which doesn't need to do.

Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
This patch fixes that SSR can overwrite previous warm node block consisting of
a node chain since the last checkpoint.

Fixes: 5b6c6be2d878 ("f2fs: use SSR for warm node as well")
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
dhowells and others added 25 commits June 21, 2020 17:58
Set up empty UAPI Kbuild files to be populated by the header splitter.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Dave Jones <davej@redhat.com>
Change-Id: I42537a5421bc18d5e144ecc9870175e194d29f9d
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
…ecking

Plumb the UAPI Kbuilds into the user header installation and checking system.
As the headers are split the entries will be transferred across from the old
Kbuild files to the UAPI Kbuild files.

The changes made in this commit are:

 (1) Exported generated files (of which there are currently four) are moved to
     uapi/ directories under the appropriate generated/ directory, thus we
     get:

	include/generated/uapi/linux/version.h
	arch/x86/include/generated/uapi/asm/unistd_32.h
	arch/x86/include/generated/uapi/asm/unistd_64.h
	arch/x86/include/generated/uapi/asm/unistd_x32.h

     These paths were added to the build as -I flags in a previous patch.

 (2) scripts/Makefile.headersinst is now given the UAPI path to install from
     rather than the old path.

     It then determines the old path from that and includes that Kbuild also
     if it exists, thus permitting the headers to exist in either directory
     during the changeover.

     I also renamed the "install" variable to "installdir" as it refers to a
     directory not the install program.

 (3) scripts/headers_install.pl is altered to take a list of source file paths
     instead of just their names so that the makefile can tell it exactly
     where to find each file.

     For the moment, files can be obtained from one of four places for each
     output directory:

	.../include/uapi/foo/
	.../include/generated/uapi/foo/
	.../include/foo/
	.../include/generated/foo/

     The non-UAPI paths will be dropped later.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Dave Jones <davej@redhat.com>
Change-Id: Ib4bf6af7d12dc3b64b73dc72d3c77b41617cc831
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
…ation

Strip the _UAPI prefix from header guards during header installation so
that any userspace dependencies aren't affected.  glibc, for example,
checks for linux/types.h, linux/kernel.h, linux/compiler.h and
linux/list.h by their guards - though the last two aren't actually
exported.

  libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -Wall -Werror -Wformat -Wformat-security -D_FORTIFY_SOURCE=2 -fno-delete-null-pointer-checks -fstack-protector -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -c child.c  -fPIC -DPIC -o .libs/child.o
  In file included from cli.c:20:0:
  common.h:152:8: error: redefinition of 'struct sysinfo'
  In file included from /usr/include/linux/kernel.h:4:0,
  		 from /usr/include/linux/sysctl.h:25,
  		 from /usr/include/sys/sysctl.h:43,
  		 from common.h:50,
  		 from cli.c:20:
  /usr/include/linux/sysinfo.h:7:8: note: originally defined here

Reported-by: Tomasz Torcz <tomek@pipebreaker.pl>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Change-Id: I87ca9ad8172481c3663e84d052f0a91bebdd09aa
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Commit 56c176c9cac9 ("UAPI: strip the _UAPI prefix from header guards
during header installation") strips the _UAPI prefix from header guards,
but only if there's a single space between the cpp directive and the
label.

Make it more flexible and able to handle tabs and multiple white space
characters.

Signed-off-by: David Howells <dhowell@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Change-Id: I3c7bfb8101461d0f100c761176801986d8db7c0f
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Remove perl from make headers_install by replacing a perl script (doing a
simple regex search and replace) with a smaller, faster, simpler,
POSIX-2008 shell script implementation.  The new shell script is a single
for loop calling sed and piping its output through unifdef to produce the
target file.

Same as last time except for minor tweak to deal with code review from
here: http://lkml.indiana.edu/hypermail/linux/kernel/1302.3/00078.html

(Note that this drops the "arch" argument, which isn't used. Kbuild
already points to the right input files on the command line.)

Signed-off-by: Rob Landley <rob@landley.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: David Howells <dhowell@redhat.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Change-Id: I46629b2bf34496f96cb04a16746e5fd29d93b22a
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Commit 10b63956fce7f369cc37fd4d994f09bd5203efe4 which plumbed in UAPI
broke the destination-y functionality of scripts/Makefile.headersinst.

The variable destination-y is used in a := assignment and so is expanded at
declaration time, and the include of the Kbuild fragments that set
destination-y to something is after this time, so it now always expands empty.

There are no in-tree users of destination-y, but it allows any
Kbuild-fragment to redirect where headers are installed.

Just move the assignment of the variable that uses it below the include
of the Kbuild fragment.

Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Change-Id: I3fda810755088ff1c4eb2de45cba1f06fc95ee01
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Commit 10b63956 ("UAPI: Plumb the UAPI Kbuilds into the user header
installation and checking") introduced a dependency of make 3.81
due to use of $(or ...)

We do not want to lift the requirement to gmake 3.81 just yet...
Included are a straightforward conversion to $(if ...)

Bisected-and-tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: <stable@vger.kernel.org> [v3.7+]
Signed-off-by: Michal Marek <mmarek@suse.cz>
Change-Id: I61a0383007bce6da99afe2d26c0c1b4ccbd14ab0
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
If headers_install is executed from a deep/long directory structure, the
shell's maximum argument length can be execeeded, which breaks the operation
with:

| make[2]: execvp: /bin/sh: Argument list too long
| make[2]: ***

Instead of passing each files name with the entire path, I give only the file
name without the source path and give this path as a new argument to
headers_install.pl.

Because there is three possible paths, I have tree input-files list, one per
path.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Tested-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Change-Id: Iab77550178922c15318cb191f5464d833e914896
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
The Makefiles call the respective interpreter explicitly, but this makes
it easier to use the scripts manually.

Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
- headers_install requires at least two arguments

- missed closing quote

Signed-off-by: Javier Barrio <javier.barrio.mart@gmail.com>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Change-Id: Ic0b93bacaa683ee9121cfa52b84962bf11c2d849
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Set up uapi/asm/Kbuild.asm.  This requires the mandatory headers to be
dynamically detected.  The same goes for include/asm/Kbuild.asm.  The problem
is that the header files will be split or moved one at a time, but each header
file in Kbuild.asm's list applies to all arch headers of that name
simultaneously.

The dynamic detection of mandatory files can be undone later.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Dave Jones <davej@redhat.com>
Change-Id: I75836d42fa624a79d50e02c6b6be422471ce560c
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
…ectories

Partition the header include path flags into two sets, one for kernelspace
builds and one for userspace builds.

Add the following directories to build after the ordinary include directories
so that #include will pick up the UAPI header directly if the kernel header
has been moved there.

The userspace set (represented by the USERINCLUDE make variable) contains:

	-I $(srctree)/arch/$(hdr-arch)/include/uapi
	-I arch/$(hdr-arch)/include/generated/uapi
	-I $(srctree)/include/uapi
	-I include/generated/uapi
	-include $(srctree)/include/linux/kconfig.h

and the kernelspace set (represented by the LINUXINCLUDE make variable)
contains:

	-I $(srctree)/arch/$(hdr-arch)/include
	-I arch/$(hdr-arch)/include/generated
	-I $(srctree)/include
	-I include		--- if not building in the source tree

plus everything in the USERINCLUDE set.

Then use USERINCLUDE in building the x86 boot code.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Dave Jones <davej@redhat.com>
Change-Id: If11f5cf1e7bd0994f2fbf0d368348f6aa443e37d
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Change-Id: I6e9a4eb77005643545ef11b932fecd82c24d1781
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor
that you can pass to mmap().  It can support sealing and avoids any
connection to user-visible mount-points.  Thus, it's not subject to quotas
on mounted file-systems, but can be used like malloc()'ed memory, but with
a file-descriptor to it.

memfd_create() returns the raw shmem file, so calls like ftruncate() can
be used to modify the underlying inode.  Also calls like fstat() will
return proper information and mark the file as regular file.  If you want
sealing, you can specify MFD_ALLOW_SEALING.  Otherwise, sealing is not
supported (like on all other regular files).

Compared to O_TMPFILE, it does not require a tmpfs mount-point and is not
subject to a filesystem size limit.  It is still properly accounted to
memcg limits, though, and to the same overcommit or no-overcommit
accounting as all user memory.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Ryan Lortie <desrt@desrt.ca>
Cc: Lennart Poettering <lennart@poettering.net>
Cc: Daniel Mack <zonque@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Angelo G. Del Regno <kholk11@gmail.com>
Change-Id: I4f4b82bb0ac3103197366fc07a8ed51a6d4faafd
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Commit 9183df25fe7b ("shm: add memfd_create() syscall") added a new
system call (memfd_create) but didn't update the asm-generic unistd
header.

This patch adds the new system call to the asm-generic version of
unistd.h so that it can be used by architectures such as arm64.

Cc: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Change-Id: Ifeb7a8a2d98207e6020cca5fd5016d171f6cd23e
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Add the memfd_create syscall to ARM.

Change-Id: Id8533a24d4c26e0168163a76da91d9f6018dccc8
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
MTP usb device node created as a part of mtp function init call.
Userspace can read/write to MTP device using this node. If MTP is
not enabled in the composition and trying to read mtp_usb dev node
from the userspace leading to null pointer access in mtp_read.

Do not access ep OUT maxpacket size in mtp_read. First block on mtp_read
until the state become online which doesn't wakeup from the thread and
expecting for the read completion or state change which occurs as
a part of set_alt.

Change-Id: Icbee5fe7ae2c02b2bca185a0dc7587eb4940058a
Signed-off-by: ChandanaKishori Chiluveru <cchilu@codeaurora.org>
Signed-off-by: Azhar Shaikh <azhars@codeaurora.org>
Signed-off-by: 1bdellatiF <ptaoubi@gmail.com>
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
If F_FS (or ADB) function is selected in the composition, android
gadget driver keeps USB gadget disabled until it receives function
descriptors from userspace. This is signalled by F_FS when it calls
functionfs_ready_callback.
There could be a scenario (mainly due to userspace ignorance) that
before enabling F_FS (ADB) in the composition, descriptors are already
passed to F_FS. This results in a crash later on cable connection
in ffs_set_alt due to missing contexts initialization as functionfs_bind
never got called.

Fix this by calling functionfs_bind when F_FS is enabled by user and
it already has received the descriptors.

CRs-fixed: 585542
Change-Id: I52d680cdcd7f5d4a3eb90eb64785ea176c832849
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
…ger-than=]

Change-Id: I127102993718a99c25d784e132012829472f5788
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: Chet Kener <Cl3Kener@gmail.com>
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
The service info structure is allocated with uninitialized memory for the
max number of services and returns the complete structure to the usersapce
resulting in the information leak if lookup operation finds less number of
services than the requested number.

Check the minimum of requested and available services and copy the minimum
information to the user-space.

CRs-Fixed: 965934
Change-Id: Ic97f875855fdc6440c1db1d8d0338ee8b03a9d0a
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
Signed-off-by: Mohammad Asaadi <mmba313@gmail.com>
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Signed-off-by: Mohammad Asaadi <mmba313@gmail.com>
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
commit 415e3d3e90ce9e18727e8843ae343eda5a58fad6 upstream.

The commit referenced in the Fixes tag incorrectly accounted the number
of in-flight fds over a unix domain socket to the original opener
of the file-descriptor. This allows another process to arbitrary
deplete the original file-openers resource limit for the maximum of
open files. Instead the sending processes and its struct cred should
be credited.

To do so, we add a reference counted struct user_struct pointer to the
scm_fp_list and use it to account for the number of inflight unix fds.

Fixes: 712f4aad406bb1 ("unix: properly account for FDs passed over unix sockets")
Change-Id: I98379047cfac33de9baa6e757c91eef046d80944
Reported-by: David Herrmann <dh.herrmann@gmail.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Mohammad Asaadi <mmba313@gmail.com>
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
buffer->size is controlled by the outer ion layer, don't modify it
inside the heap.  Instead, compute the rounded up allocated size
on demand.

Change-Id: I288ffc1221ce96cfe2591468502ac3279065bde4
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Mohammad Asaadi <mmba313@gmail.com>
Signed-off-by: Samuel Pascua <pascua.samuel.14@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
@TheSkater187
Copy link
Copy Markdown
Contributor

Sorry, haven't been on much. Been having health issues. Is there an easy way to revert these commits or should I just delete and re-push my local repo?

@TheSkater187 TheSkater187 reopened this Jun 23, 2020
@ghost
Copy link
Copy Markdown
Author

ghost commented Jun 24, 2020

Sorry, haven't been on much. Been having health issues. Is there an easy way to revert these commits or should I just delete and re-push my local repo?

Revert "merged" commit will revert all related commits

SmgKhOaRn and others added 2 commits June 29, 2020 09:59
[ Upstream commit f320793e52aee78f0fbb8bcaf10e6614d2e67bfc ]

[ Upstream commit cb984d101b30eb7478d32df56a0023e4603cba7f ]

As gcc major version numbers are going to advance rather rapidly in the
future, there's no real value in separate files for each compiler
version.

Deduplicate some of the macros #defined in each file too.

Neaten comments using normal kernel commenting style.

Change-Id: I57ed22addc33ec4dfdac84c233fe7352d071f9be
Signed-off-by: Joe Perches <joe@perches.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Sasha Levin <levinsasha928@gmail.com>
Cc: Anton Blanchard <anton@samba.org>
Cc: Alan Modra <amodra@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Khalvat-M <mmba313@gmail.com>
Signed-off-by: SmgKhOaRn <smgkhoarn@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.