-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please revert the accident pull request and use this if you want. #3
Open
ghost
wants to merge
143
commits into
187MoD:master
Choose a base branch
from
Blazko381:Ares-Smg-10
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: SmgKhOaRn <[email protected]>
Signed-off-by: SmgKhOaRn <[email protected]>
Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Reviewed-by: Jean-Philippe Aumasson <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Eric Biggers <[email protected]> Cc: David Laight <[email protected]> Cc: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Ben Hutchings <[email protected]> Signed-off-by: Kevin F. Haggerty <[email protected]> Change-Id: I0af6b25995c1d4f77b1f6c3467571abe54ad182e Signed-off-by: SmgKhOaRn <[email protected]>
Signed-off-by: SmgKhOaRn <[email protected]>
For some reason, External Connector Class (extcon) breaks headset. Signed-off-by: SmgKhOaRn <[email protected]>
Signed-off-by: SmgKhOaRn <[email protected]>
Added Smart Dim Signed-off-by: SmgKhOaRn <[email protected]>
Signed-off-by: SmgKhOaRn <[email protected]>
Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Reported-by: Mathias Payer <[email protected]> Signed-off-by: Hui Peng <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <[email protected]> CVE-2019-15118 Signed-off-by: Kevin F. Haggerty <[email protected]> Change-Id: I634e09d321549304e98012c09ef2c35cd50aa3ac Signed-off-by: SmgKhOaRn <[email protected]>
Check payload size to avoid out-of-boundary memory access before attemptimg memory read. Change-Id: Id22f5c4e50c788053a0529e2d252e497991e1a38 Signed-off-by: Soumya Managoli <[email protected]> [haggertk: Backport to 3.4/msm8974. Path change.] CVE-2019-10626 Signed-off-by: Kevin F. Haggerty <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
* 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 <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> [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 <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> CVE-2019-14053 Signed-off-by: Kevin F. Haggerty <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> CVE-2019-14038 Signed-off-by: Kevin F. Haggerty <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
Do not return 0 if msm_get_session fails on session_id. Change-Id: Iad8b72e33c3a613da3f16693fce9aaf862de9ac5 Signed-off-by: Kevin F. Haggerty <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
Add dev_*_ratelimited() family, dev_* version of pr_*_ratelimited(). Using Joe Perches's proposal/implementation. Signed-off-by: Hiroshi DOYU <[email protected]> Cc: Joe Perches <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Kevin F. Haggerty <[email protected]> Change-Id: I6f0f4f8f61de2dd5331eff202b66c931700bbf27 Signed-off-by: SmgKhOaRn <[email protected]>
Ratelimit log in msm_vb2_buf_cleanup to prevent excessive logging when stream is NULL. Change-Id: Ia687375c8e2a2683a4d32cd0eb984f731b2288e7 Signed-off-by: Trishansh Bhardwaj <[email protected]> Signed-off-by: Kevin F. Haggerty <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Signed-off-by: Kevin F. Haggerty <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Signed-off-by: Trishansh Bhardwaj <[email protected]> [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 <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
Prevent deadlock between tasklet and delete_stream by stopping irq during delete_stream. CRs-Fixed: 2076578 Change-Id: Ibcc9fd44403d24112b01150a7d1f3c6e705ea99a Signed-off-by: Trishansh Bhardwaj <[email protected]> Signed-off-by: VijayaKumar T M <[email protected]> CVE-2017-9704 Signed-off-by: Kevin F. Haggerty <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Signed-off-by: Zhang Xiaoxu <[email protected]> [danvet: augment commit message to point out overflow safety] Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ben Hutchings <[email protected]> CVE-2020-8647 Signed-off-by: Kevin F. Haggerty <[email protected]> Change-Id: I38134ca1efd924ba852e4c1723a5924399c68f24 Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Reported-by: [email protected] References: https://bugzilla.kernel.org/show_bug.cgi?id=206361 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings <[email protected]> Signed-off-by: Kevin F. Haggerty <[email protected]> Change-Id: Ibc7d5164460fab68ca2d247a86c28c8077a76cf4 Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Fixes: 07e6124a1a46 ("vt: selection, close sel_buffer race") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Ben Hutchings <[email protected]> CVE-2020-8648 Signed-off-by: Kevin F. Haggerty <[email protected]> Change-Id: If732e6acb1aab4d19379e2494e10cf2085e6ac65 Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Reported-by: [email protected] Fixes: 07e6124a1a46 ("vt: selection, close sel_buffer race") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Ben Hutchings <[email protected]> CVE-2020-8648 Signed-off-by: Kevin F. Haggerty <[email protected]> Change-Id: I9ee48b7939bfe3973b95f0487898c06f50fdf418 Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Cc: Theodore Ts'o <[email protected]> Signed-off-by: Ben Hutchings <[email protected]> Signed-off-by: Kevin F. Haggerty <[email protected]> Change-Id: Id1aa83660b3f32381c9275373773854e1e197b87 Signed-off-by: SmgKhOaRn <[email protected]>
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/[email protected] Reported-by: [email protected] Reported-by: [email protected] Reported-by: [email protected] Signed-off-by: Theodore Ts'o <[email protected]> [bwh: Backported to 3.16: - Use EIO instead of EFSCORRUPTED - Adjust context] Signed-off-by: Ben Hutchings <[email protected]> CVE-2019-19767 Signed-off-by: Kevin F. Haggerty <[email protected]> Change-Id: I0eaa4612f0c3c11951128c8a5fb1536bd6e0f12b Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
Set up empty UAPI Kbuild files to be populated by the header splitter. Signed-off-by: David Howells <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Acked-by: Paul E. McKenney <[email protected]> Acked-by: Dave Jones <[email protected]> Change-Id: I42537a5421bc18d5e144ecc9870175e194d29f9d Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
…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 <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Acked-by: Paul E. McKenney <[email protected]> Acked-by: Dave Jones <[email protected]> Change-Id: Ib4bf6af7d12dc3b64b73dc72d3c77b41617cc831 Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
…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 <[email protected]> Signed-off-by: David Howells <[email protected]> Acked-by: Josh Boyer <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Change-Id: I87ca9ad8172481c3663e84d052f0a91bebdd09aa Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Change-Id: I3c7bfb8101461d0f100c761176801986d8db7c0f Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Josh Boyer <[email protected]> Cc: "Paul E. McKenney" <[email protected]> Cc: David Howells <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Michal Marek <[email protected]> Change-Id: I46629b2bf34496f96cb04a16746e5fd29d93b22a Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Cc: Michal Marek <[email protected]> Cc: David Howells <[email protected]> Signed-off-by: Michal Marek <[email protected]> Change-Id: I3fda810755088ff1c4eb2de45cba1f06fc95ee01 Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Cc: David Howells <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Cc: <[email protected]> [v3.7+] Signed-off-by: Michal Marek <[email protected]> Change-Id: I61a0383007bce6da99afe2d26c0c1b4ccbd14ab0 Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Tested-by: Bruce Ashfield <[email protected]> Signed-off-by: Michal Marek <[email protected]> Change-Id: Iab77550178922c15318cb191f5464d833e914896 Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
The Makefiles call the respective interpreter explicitly, but this makes it easier to use the scripts manually. Signed-off-by: Michal Marek <[email protected]> Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
- headers_install requires at least two arguments - missed closing quote Signed-off-by: Javier Barrio <[email protected]> Cc: Michal Marek <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Change-Id: Ic0b93bacaa683ee9121cfa52b84962bf11c2d849 Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Acked-by: Paul E. McKenney <[email protected]> Acked-by: Dave Jones <[email protected]> Change-Id: I75836d42fa624a79d50e02c6b6be422471ce560c Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
…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 <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Acked-by: Paul E. McKenney <[email protected]> Acked-by: Dave Jones <[email protected]> Change-Id: If11f5cf1e7bd0994f2fbf0d368348f6aa443e37d Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
Change-Id: I6e9a4eb77005643545ef11b932fecd82c24d1781 Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Acked-by: Hugh Dickins <[email protected]> Cc: Michael Kerrisk <[email protected]> Cc: Ryan Lortie <[email protected]> Cc: Lennart Poettering <[email protected]> Cc: Daniel Mack <[email protected]> Cc: Andy Lutomirski <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Angelo G. Del Regno <[email protected]> Change-Id: I4f4b82bb0ac3103197366fc07a8ed51a6d4faafd Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Reviewed-by: David Herrmann <[email protected]> Signed-off-by: Will Deacon <[email protected]> Change-Id: Ifeb7a8a2d98207e6020cca5fd5016d171f6cd23e Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
Add the memfd_create syscall to ARM. Change-Id: Id8533a24d4c26e0168163a76da91d9f6018dccc8 Signed-off-by: Russell King <[email protected]> Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Signed-off-by: Azhar Shaikh <[email protected]> Signed-off-by: 1bdellatiF <[email protected]> Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
…ger-than=] Change-Id: I127102993718a99c25d784e132012829472f5788 Signed-off-by: Pranav Vashi <[email protected]> Signed-off-by: Chet Kener <[email protected]> Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Signed-off-by: Mohammad Asaadi <[email protected]> Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
Signed-off-by: Mohammad Asaadi <[email protected]> Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Cc: David Herrmann <[email protected]> Cc: Willy Tarreau <[email protected]> Cc: Linus Torvalds <[email protected]> Suggested-by: Linus Torvalds <[email protected]> Signed-off-by: Hannes Frederic Sowa <[email protected]> Signed-off-by: David S. Miller <[email protected]> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <[email protected]> Signed-off-by: Mohammad Asaadi <[email protected]> Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
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 <[email protected]> Signed-off-by: Mohammad Asaadi <[email protected]> Signed-off-by: Samuel Pascua <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
Signed-off-by: SmgKhOaRn <[email protected]>
Signed-off-by: SmgKhOaRn <[email protected]>
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 |
This reverts commit f32ef1a.
[ 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 <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Michal Marek <[email protected]> Cc: Segher Boessenkool <[email protected]> Cc: Sasha Levin <[email protected]> Cc: Anton Blanchard <[email protected]> Cc: Alan Modra <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Khalvat-M <[email protected]> Signed-off-by: SmgKhOaRn <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.