commit 16f3f0d74b2069038a24f69952f0c19ad7c48d9a Author: Ben Hutchings Date: Thu Jun 11 19:06:00 2020 +0100 Linux 3.16.85 commit d03daec2e50aa2a0b6de2c3572af5e1d61f9d132 Author: Alexander Potapenko Date: Wed May 27 22:20:52 2020 -0700 fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info() commit 1d605416fb7175e1adf094251466caa52093b413 upstream. KMSAN reported uninitialized data being written to disk when dumping core. As a result, several kilobytes of kmalloc memory may be written to the core file and then read by a non-privileged user. Reported-by: sam Signed-off-by: Alexander Potapenko Signed-off-by: Andrew Morton Acked-by: Kees Cook Cc: Al Viro Cc: Alexey Dobriyan Link: http://lkml.kernel.org/r/20200419100848.63472-1-glider@google.com Link: https://github.com/google/kmsan/issues/76 Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 493b4e7e4ed9cb671788d886bbc0f8d26ae10dba Author: Jason A. Donenfeld Date: Fri Feb 21 21:10:37 2020 +0100 random: always use batched entropy for get_random_u{32,64} commit 69efea712f5b0489e67d07565aad5c94e09a3e52 upstream. It turns out that RDRAND is pretty slow. Comparing these two constructions: for (i = 0; i < CHACHA_BLOCK_SIZE; i += sizeof(ret)) arch_get_random_long(&ret); and long buf[CHACHA_BLOCK_SIZE / sizeof(long)]; extract_crng((u8 *)buf); it amortizes out to 352 cycles per long for the top one and 107 cycles per long for the bottom one, on Coffee Lake Refresh, Intel Core i9-9880H. And importantly, the top one has the drawback of not benefiting from the real rng, whereas the bottom one has all the nice benefits of using our own chacha rng. As get_random_u{32,64} gets used in more places (perhaps beyond what it was originally intended for when it was introduced as get_random_{int,long} back in the md5 monstrosity era), it seems like it might be a good thing to strengthen its posture a tiny bit. Doing this should only be stronger and not any weaker because that pool is already initialized with a bunch of rdrand data (when available). This way, we get the benefits of the hardware rng as well as our own rng. Another benefit of this is that we no longer hit pitfalls of the recent stream of AMD bugs in RDRAND. One often used code pattern for various things is: do { val = get_random_u32(); } while (hash_table_contains_key(val)); That recent AMD bug rendered that pattern useless, whereas we're really very certain that chacha20 output will give pretty distributed numbers, no matter what. So, this simplification seems better both from a security perspective and from a performance perspective. Signed-off-by: Jason A. Donenfeld Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20200221201037.30231-1-Jason@zx2c4.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: Only get_random_int() exists here] Signed-off-by: Ben Hutchings commit 948cfe9d8a2e3f0465340d5dea9d61f282df00e7 Author: Josh Poimboeuf Date: Mon Apr 27 20:46:13 2020 +0200 x86/speculation: Add Ivy Bridge to affected list commit 3798cc4d106e91382bfe016caa2edada27c2bb3f upstream. Make the docs match the code. Signed-off-by: Josh Poimboeuf Signed-off-by: Thomas Gleixner Signed-off-by: Ben Hutchings commit 0d314e817a11e62ab223b27166de0c6b3859e0e7 Author: Mark Gross Date: Tue Apr 28 16:58:21 2020 +0200 x86/speculation: Add SRBDS vulnerability and mitigation documentation commit 7222a1b5b87417f22265c92deea76a6aecd0fb0f upstream. Add documentation for the SRBDS vulnerability and its mitigation. [ bp: Massage. jpoimboe: sysfs table strings. ] Signed-off-by: Mark Gross Signed-off-by: Borislav Petkov Reviewed-by: Tony Luck Reviewed-by: Josh Poimboeuf Signed-off-by: Ben Hutchings commit 8c95356f8493c164c8878134d25f30cbd6d7ae5c Author: Mark Gross Date: Tue Apr 28 16:58:20 2020 +0200 x86/speculation: Add Special Register Buffer Data Sampling (SRBDS) mitigation commit 7e5b3c267d256822407a22fdce6afdf9cd13f9fb upstream. SRBDS is an MDS-like speculative side channel that can leak bits from the random number generator (RNG) across cores and threads. New microcode serializes the processor access during the execution of RDRAND and RDSEED. This ensures that the shared buffer is overwritten before it is released for reuse. While it is present on all affected CPU models, the microcode mitigation is not needed on models that enumerate ARCH_CAPABILITIES[MDS_NO] in the cases where TSX is not supported or has been disabled with TSX_CTRL. The mitigation is activated by default on affected processors and it increases latency for RDRAND and RDSEED instructions. Among other effects this will reduce throughput from /dev/urandom. * Enable administrator to configure the mitigation off when desired using either mitigations=off or srbds=off. * Export vulnerability status via sysfs * Rename file-scoped macros to apply for non-whitelist table initializations. [ bp: Massage, - s/VULNBL_INTEL_STEPPING/VULNBL_INTEL_STEPPINGS/g, - do not read arch cap MSR a second time in tsx_fused_off() - just pass it in, - flip check in cpu_set_bug_bits() to save an indentation level, - reflow comments. jpoimboe: s/Mitigated/Mitigation/ in user-visible strings tglx: Dropped the fused off magic for now ] Signed-off-by: Mark Gross Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Reviewed-by: Tony Luck Reviewed-by: Pawan Gupta Reviewed-by: Josh Poimboeuf Tested-by: Neelima Krishnan [bwh: Backported to 3.16: - CPU feature words and bugs are numbered differently - Adjust filename for ] Signed-off-by: Ben Hutchings commit 98a637c406eefe95f2428739c1397f250bb7fadd Author: Mark Gross Date: Tue Apr 28 16:58:20 2020 +0200 x86/cpu: Add 'table' argument to cpu_matches() commit 93920f61c2ad7edb01e63323832585796af75fc9 upstream. To make cpu_matches() reusable for other matching tables, have it take a pointer to a x86_cpu_id table as an argument. [ bp: Flip arguments order. ] Signed-off-by: Mark Gross Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Reviewed-by: Josh Poimboeuf Signed-off-by: Ben Hutchings commit bed86e750bb02981a5efe110b7e9ae3d989a2e73 Author: Mark Gross Date: Tue Apr 28 16:58:20 2020 +0200 x86/cpu: Add a steppings field to struct x86_cpu_id commit e9d7144597b10ff13ff2264c059f7d4a7fbc89ac upstream. Intel uses the same family/model for several CPUs. Sometimes the stepping must be checked to tell them apart. On x86 there can be at most 16 steppings. Add a steppings bitmask to x86_cpu_id and a X86_MATCH_VENDOR_FAMILY_MODEL_STEPPING_FEATURE macro and support for matching against family/model/stepping. [ bp: Massage. tglx: Lightweight variant for backporting ] Signed-off-by: Mark Gross Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Reviewed-by: Tony Luck Reviewed-by: Josh Poimboeuf Signed-off-by: Ben Hutchings commit 582f3009d4511bdd12a4d88ae52da46359cd88aa Author: Jia Zhang Date: Mon Jan 1 09:52:10 2018 +0800 x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping commit b399151cb48db30ad1e0e93dd40d68c6d007b637 upstream. x86_mask is a confusing name which is hard to associate with the processor's stepping. Additionally, correct an indent issue in lib/cpu.c. Signed-off-by: Jia Zhang [ Updated it to more recent kernels. ] Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: bp@alien8.de Cc: tony.luck@intel.com Link: http://lkml.kernel.org/r/1514771530-70829-1-git-send-email-qianyue.zj@alibaba-inc.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: - Drop changes in arch/x86/lib/cpu.c - Adjust filenames, context] Signed-off-by: Ben Hutchings commit 53b7a2eb6f94f439bce973593ce177592d34c63f Author: Shijie Luo Date: Mon Feb 10 20:17:52 2020 -0500 ext4: add cond_resched() to ext4_protect_reserved_inode commit af133ade9a40794a37104ecbcc2827c0ea373a3c upstream. When journal size is set too big by "mkfs.ext4 -J size=", or when we mount a crafted image to make journal inode->i_size too big, the loop, "while (i < num)", holds cpu too long. This could cause soft lockup. [ 529.357541] Call trace: [ 529.357551] dump_backtrace+0x0/0x198 [ 529.357555] show_stack+0x24/0x30 [ 529.357562] dump_stack+0xa4/0xcc [ 529.357568] watchdog_timer_fn+0x300/0x3e8 [ 529.357574] __hrtimer_run_queues+0x114/0x358 [ 529.357576] hrtimer_interrupt+0x104/0x2d8 [ 529.357580] arch_timer_handler_virt+0x38/0x58 [ 529.357584] handle_percpu_devid_irq+0x90/0x248 [ 529.357588] generic_handle_irq+0x34/0x50 [ 529.357590] __handle_domain_irq+0x68/0xc0 [ 529.357593] gic_handle_irq+0x6c/0x150 [ 529.357595] el1_irq+0xb8/0x140 [ 529.357599] __ll_sc_atomic_add_return_acquire+0x14/0x20 [ 529.357668] ext4_map_blocks+0x64/0x5c0 [ext4] [ 529.357693] ext4_setup_system_zone+0x330/0x458 [ext4] [ 529.357717] ext4_fill_super+0x2170/0x2ba8 [ext4] [ 529.357722] mount_bdev+0x1a8/0x1e8 [ 529.357746] ext4_mount+0x44/0x58 [ext4] [ 529.357748] mount_fs+0x50/0x170 [ 529.357752] vfs_kern_mount.part.9+0x54/0x188 [ 529.357755] do_mount+0x5ac/0xd78 [ 529.357758] ksys_mount+0x9c/0x118 [ 529.357760] __arm64_sys_mount+0x28/0x38 [ 529.357764] el0_svc_common+0x78/0x130 [ 529.357766] el0_svc_handler+0x38/0x78 [ 529.357769] el0_svc+0x8/0xc [ 541.356516] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [mount:18674] Link: https://lore.kernel.org/r/20200211011752.29242-1-luoshijie1@huawei.com Reviewed-by: Jan Kara Signed-off-by: Shijie Luo Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Ben Hutchings commit 71bfaf9e30125ec5b408fd328e412abf3b23214d Author: Theodore Ts'o Date: Wed May 22 10:27:01 2019 -0400 ext4: don't perform block validity checks on the journal inode commit 0a944e8a6c66ca04c7afbaa17e22bf208a8b37f0 upstream. Since the journal inode is already checked when we added it to the block validity's system zone, if we check it again, we'll just trigger a failure. This was causing failures like this: [ 53.897001] EXT4-fs error (device sda): ext4_find_extent:909: inode #8: comm jbd2/sda-8: pblk 121667583 bad header/extent: invalid extent entries - magic f30a, entries 8, max 340(340), depth 0(0) [ 53.931430] jbd2_journal_bmap: journal block not found at offset 49 on sda-8 [ 53.938480] Aborting journal on device sda-8. ... but only if the system was under enough memory pressure that logical->physical mapping for the journal inode gets pushed out of the extent cache. (This is why it wasn't noticed earlier.) Fixes: 345c0dbf3a30 ("ext4: protect journal inode's blocks using block_validity") Reported-by: Dan Rue Signed-off-by: Theodore Ts'o Tested-by: Naresh Kamboju [bwh: Backported to 3.16: Use EXT4_HAS_COMPAT_FEATURE()] Signed-off-by: Ben Hutchings commit a8a1d01018f66c5cc3cb2a4c194e55edcf0e50ec Author: Theodore Ts'o Date: Wed May 15 00:51:19 2019 -0400 ext4: fix block validity checks for journal inodes using indirect blocks commit 170417c8c7bb2cbbdd949bf5c443c0c8f24a203b upstream. Commit 345c0dbf3a30 ("ext4: protect journal inode's blocks using block_validity") failed to add an exception for the journal inode in ext4_check_blockref(), which is the function used by ext4_get_branch() for indirect blocks. This caused attempts to read from the ext3-style journals to fail with: [ 848.968550] EXT4-fs error (device sdb7): ext4_get_branch:171: inode #8: block 30343695: comm jbd2/sdb7-8: invalid block Fix this by adding the missing exception check. Fixes: 345c0dbf3a30 ("ext4: protect journal inode's blocks using block_validity") Reported-by: Arthur Marsh Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: Use EXT4_HAS_COMPAT_FEATURE] Signed-off-by: Ben Hutchings commit 310dac05e090433b1de043eff9d0b0c389ba843f Author: Colin Ian King Date: Fri May 10 22:06:38 2019 -0400 ext4: unsigned int compared against zero commit fbbbbd2f28aec991f3fbc248df211550fbdfd58c upstream. There are two cases where u32 variables n and err are being checked for less than zero error values, the checks is always false because the variables are not signed. Fix this by making the variables ints. Addresses-Coverity: ("Unsigned compared against 0") Fixes: 345c0dbf3a30 ("ext4: protect journal inode's blocks using block_validity") Signed-off-by: Colin Ian King Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings commit 51890201da4d654f6ca131bc45a0e892bb10de1d Author: Theodore Ts'o Date: Tue Apr 9 23:37:08 2019 -0400 ext4: protect journal inode's blocks using block_validity commit 345c0dbf3a30872d9b204db96b5857cd00808cae upstream. Add the blocks which belong to the journal inode to block_validity's system zone so attempts to deallocate or overwrite the journal due a corrupted file system where the journal blocks are also claimed by another inode. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202879 Signed-off-by: Theodore Ts'o Cc: stable@kernel.org [bwh: Backported to 3.16: - Use EXT4_HAS_COMPAT_FEATURE() - Use EIO instead of EFSCORRUPTED] Signed-off-by: Ben Hutchings commit f9c6ffd9190290d3d2502c297e3df4aef3d034c0 Author: Tahsin Erdogan Date: Thu May 17 18:23:04 2018 +0200 ext4: Make checks for metadata_csum feature safer This is just a small part of commit dec214d00e0d7 "ext4: xattr inode deduplication" that makes checks for metadata_csum feature safer and is actually needed by following fixes. Signed-off-by: Tahsin Erdogan Acked-by: Jan Kara [bwh: Ported to 3.16: Use EXT4_HAS_RO_COMPAT_FEATURE()] Signed-off-by: Ben Hutchings commit d126cf46f829d146dde3e6a8963e095ac6cfcd1c Author: Kyungtae Kim Date: Sun May 10 05:43:34 2020 +0000 USB: gadget: fix illegal array access in binding with UDC commit 15753588bcd4bbffae1cca33c8ced5722477fe1f upstream. FuzzUSB (a variant of syzkaller) found an illegal array access using an incorrect index while binding a gadget with UDC. Reference: https://www.spinics.net/lists/linux-usb/msg194331.html This bug occurs when a size variable used for a buffer is misused to access its strcpy-ed buffer. Given a buffer along with its size variable (taken from user input), from which, a new buffer is created using kstrdup(). Due to the original buffer containing 0 value in the middle, the size of the kstrdup-ed buffer becomes smaller than that of the original. So accessing the kstrdup-ed buffer with the same size variable triggers memory access violation. The fix makes sure no zero value in the buffer, by comparing the strlen() of the orignal buffer with the size variable, so that the access to the kstrdup-ed buffer is safe. BUG: KASAN: slab-out-of-bounds in gadget_dev_desc_UDC_store+0x1ba/0x200 drivers/usb/gadget/configfs.c:266 Read of size 1 at addr ffff88806a55dd7e by task syz-executor.0/17208 CPU: 2 PID: 17208 Comm: syz-executor.0 Not tainted 5.6.8 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xce/0x128 lib/dump_stack.c:118 print_address_description.constprop.4+0x21/0x3c0 mm/kasan/report.c:374 __kasan_report+0x131/0x1b0 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:641 __asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:132 gadget_dev_desc_UDC_store+0x1ba/0x200 drivers/usb/gadget/configfs.c:266 flush_write_buffer fs/configfs/file.c:251 [inline] configfs_write_file+0x2f1/0x4c0 fs/configfs/file.c:283 __vfs_write+0x85/0x110 fs/read_write.c:494 vfs_write+0x1cd/0x510 fs/read_write.c:558 ksys_write+0x18a/0x220 fs/read_write.c:611 __do_sys_write fs/read_write.c:623 [inline] __se_sys_write fs/read_write.c:620 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:620 do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe Signed-off-by: Kyungtae Kim Reported-and-tested-by: Kyungtae Kim Cc: Felipe Balbi Cc: stable Link: https://lore.kernel.org/r/20200510054326.GA19198@pizza01 Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 303c5366d664e0b860041e0647952dafcd71c5a1 Author: Eric W. Biederman Date: Mon Mar 30 19:01:04 2020 -0500 signal: Extend exec_id to 64bits commit d1e7fd6462ca9fc76650fbe6ca800e35b24267da upstream. Replace the 32bit exec_id with a 64bit exec_id to make it impossible to wrap the exec_id counter. With care an attacker can cause exec_id wrap and send arbitrary signals to a newly exec'd parent. This bypasses the signal sending checks if the parent changes their credentials during exec. The severity of this problem can been seen that in my limited testing of a 32bit exec_id it can take as little as 19s to exec 65536 times. Which means that it can take as little as 14 days to wrap a 32bit exec_id. Adam Zabrocki has succeeded wrapping the self_exe_id in 7 days. Even my slower timing is in the uptime of a typical server. Which means self_exec_id is simply a speed bump today, and if exec gets noticably faster self_exec_id won't even be a speed bump. Extending self_exec_id to 64bits introduces a problem on 32bit architectures where reading self_exec_id is no longer atomic and can take two read instructions. Which means that is is possible to hit a window where the read value of exec_id does not match the written value. So with very lucky timing after this change this still remains expoiltable. I have updated the update of exec_id on exec to use WRITE_ONCE and the read of exec_id in do_notify_parent to use READ_ONCE to make it clear that there is no locking between these two locations. Link: https://lore.kernel.org/kernel-hardening/20200324215049.GA3710@pi3.com.pl Fixes: 2.3.23pre2 Cc: stable@vger.kernel.org Signed-off-by: "Eric W. Biederman" [bwh: Backported to 3.16: - Use ACCESS_ONCE() - Adjust context] Signed-off-by: Ben Hutchings commit f5eb337df20a24a9f9c7f96181ace9d61b590def Author: Wu Bo Date: Tue Apr 14 10:13:28 2020 +0800 scsi: sg: add sg_remove_request in sg_write commit 83c6f2390040f188cc25b270b4befeb5628c1aee upstream. If the __copy_from_user function failed we need to call sg_remove_request in sg_write. Link: https://lore.kernel.org/r/610618d9-e983-fd56-ed0f-639428343af7@huawei.com Acked-by: Douglas Gilbert Signed-off-by: Wu Bo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin [groeck: Backport to v5.4.y and older kernels] Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit d3f4ead8e811140787bf39052a4bd2893fbf56b2 Author: Li Bin Date: Mon Apr 13 19:29:21 2020 +0800 scsi: sg: add sg_remove_request in sg_common_write commit 849f8583e955dbe3a1806e03ecacd5e71cce0a08 upstream. If the dxfer_len is greater than 256M then the request is invalid and we need to call sg_remove_request in sg_common_write. Link: https://lore.kernel.org/r/1586777361-17339-1-git-send-email-huawei.libin@huawei.com Fixes: f930c7043663 ("scsi: sg: only check for dxfer_len greater than 256M") Acked-by: Douglas Gilbert Signed-off-by: Li Bin Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit ed1c1e63c58ed1f7067f8bb5c439c958dc1c2d18 Author: Tony Battersby Date: Thu Jul 12 16:30:45 2018 -0400 scsi: sg: fix minor memory leak in error path commit c170e5a8d222537e98aa8d4fddb667ff7a2ee114 upstream. Fix a minor memory leak when there is an error opening a /dev/sg device. Fixes: cc833acbee9d ("sg: O_EXCL and other lock handling") Cc: Reviewed-by: Ewan D. Milne Signed-off-by: Tony Battersby Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 8ffd761c97a83a5eb2ff500afd50a5bb9c3711ed Author: Johannes Thumshirn Date: Wed May 10 09:53:40 2017 +0200 scsi: sg: don't return bogus Sg_requests commit 48ae8484e9fc324b4968d33c585e54bc98e44d61 upstream. If the list search in sg_get_rq_mark() fails to find a valid request, we return a bogus element. This then can later lead to a GPF in sg_remove_scat(). So don't return bogus Sg_requests in sg_get_rq_mark() but NULL in case the list search doesn't find a valid request. Signed-off-by: Johannes Thumshirn Reported-by: Andrey Konovalov Cc: Hannes Reinecke Cc: Christoph Hellwig Cc: Doug Gilbert Reviewed-by: Hannes Reinecke Acked-by: Doug Gilbert Signed-off-by: Martin K. Petersen Cc: Tony Battersby Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit fd3206b7f195b5bdbbf9a535e4fbcbc88c12c9e3 Author: Johannes Thumshirn Date: Thu Jul 27 09:11:26 2017 +0200 scsi: sg: only check for dxfer_len greater than 256M commit f930c7043663188429cd9b254e9d761edfc101ce upstream. Don't make any assumptions on the sg_io_hdr_t::dxfer_direction or the sg_io_hdr_t::dxferp in order to determine if it is a valid request. The only way we can check for bad requests is by checking if the length exceeds 256M. Signed-off-by: Johannes Thumshirn Fixes: 28676d869bbb (scsi: sg: check for valid direction before starting the request) Reported-by: Jason L Tibbitts III Tested-by: Jason L Tibbitts III Suggested-by: Doug Gilbert Cc: Doug Gilbert Cc: Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: Include ] Signed-off-by: Ben Hutchings commit 99b6d6fb8a7e74d56d17808556995822b7ae8eed Author: Johannes Thumshirn Date: Mon Jul 17 15:11:42 2017 +0200 scsi: sg: fix static checker warning in sg_is_valid_dxfer commit 14074aba4bcda3764c9a702b276308b89901d5b6 upstream. dxfer_len is an unsigned int and we always assign a value > 0 to it, so it doesn't make any sense to check if it is < 0. We can't really check dxferp as well as we have both NULL and not NULL cases in the possible call paths. So just return true for SG_DXFER_FROM_DEV transfer in sg_is_valid_dxfer(). Signed-off-by: Johannes Thumshirn Reported-by: Colin Ian King Reported-by: Dan Carpenter Cc: Douglas Gilbert Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 341068a66ab680ab19b4938253b872ca00ec8121 Author: Johannes Thumshirn Date: Fri Jul 7 10:56:38 2017 +0200 scsi: sg: fix SG_DXFER_FROM_DEV transfers commit 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 upstream. SG_DXFER_FROM_DEV transfers do not necessarily have a dxferp as we set it to NULL for the old sg_io read/write interface, but must have a length bigger than 0. This fixes a regression introduced by commit 28676d869bbb ("scsi: sg: check for valid direction before starting the request") Signed-off-by: Johannes Thumshirn Fixes: 28676d869bbb ("scsi: sg: check for valid direction before starting the request") Reported-by: Chris Clayton Tested-by: Chris Clayton Cc: Douglas Gilbert Reviewed-by: Hannes Reinecke Tested-by: Chris Clayton Acked-by: Douglas Gilbert Signed-off-by: Martin K. Petersen Cc: Cristian Crinteanu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 8d1f3b474a89b42f957ba3bae959dd3cd16531ca Author: Hannes Reinecke Date: Fri Apr 7 09:34:17 2017 +0200 scsi: sg: close race condition in sg_remove_sfp_usercontext() commit 97d27b0dd015e980ade63fda111fd1353276e28b upstream. sg_remove_sfp_usercontext() is clearing any sg requests, but needs to take 'rq_list_lock' when modifying the list. Reported-by: Christoph Hellwig Signed-off-by: Hannes Reinecke Reviewed-by: Johannes Thumshirn Tested-by: Johannes Thumshirn Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit ab869b0a8741852d36c9a37709bbed40f0d324b5 Author: Johannes Thumshirn Date: Fri Apr 7 09:34:15 2017 +0200 scsi: sg: check for valid direction before starting the request commit 28676d869bbb5257b5f14c0c95ad3af3a7019dd5 upstream. Check for a valid direction before starting the request, otherwise we risk running into an assertion in the scsi midlayer checking for valid requests. [mkp: fixed typo] Signed-off-by: Johannes Thumshirn Link: http://www.spinics.net/lists/linux-scsi/msg104400.html Reported-by: Dmitry Vyukov Signed-off-by: Hannes Reinecke Tested-by: Johannes Thumshirn Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 0e8d9ca262840625610449e05cac4a2c9d7be83a Author: Hannes Reinecke Date: Fri Apr 7 09:34:12 2017 +0200 scsi: sg: disable SET_FORCE_LOW_DMA commit 745dfa0d8ec26b24f3304459ff6e9eacc5c8351b upstream. The ioctl SET_FORCE_LOW_DMA has never worked since the initial git check-in, and the respective setting is nowadays handled correctly. So disable it entirely. Signed-off-by: Hannes Reinecke Reviewed-by: Johannes Thumshirn Tested-by: Johannes Thumshirn Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 6d391ab54157b36331528d526957688f458a11bf Author: Ben Hutchings Date: Sun Oct 15 18:16:33 2017 +0100 scsi: sg: Re-fix off by one in sg_fill_request_table() commit 587c3c9f286cee5c9cac38d28c8ae1875f4ec85b upstream. Commit 109bade9c625 ("scsi: sg: use standard lists for sg_requests") introduced an off-by-one error in sg_ioctl(), which was fixed by commit bd46fc406b30 ("scsi: sg: off by one in sg_ioctl()"). Unfortunately commit 4759df905a47 ("scsi: sg: factor out sg_fill_request_table()") moved that code, and reintroduced the bug (perhaps due to a botched rebase). Fix it again. Fixes: 4759df905a47 ("scsi: sg: factor out sg_fill_request_table()") Signed-off-by: Ben Hutchings Acked-by: Douglas Gilbert Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit f37de82d22dc41e9748b788655fab4bfea465a02 Author: Hannes Reinecke Date: Fri Sep 15 14:05:16 2017 +0200 scsi: sg: fixup infoleak when using SG_GET_REQUEST_TABLE commit 3e0097499839e0fe3af380410eababe5a47c4cf9 upstream. When calling SG_GET_REQUEST_TABLE ioctl only a half-filled table is returned; the remaining part will then contain stale kernel memory information. This patch zeroes out the entire table to avoid this issue. Signed-off-by: Hannes Reinecke Reviewed-by: Bart Van Assche Reviewed-by: Christoph Hellwig Reviewed-by: Eric Dumazet Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 72e47c58b24aef8c687cbaaffa3aa5f9fe88612c Author: Hannes Reinecke Date: Fri Sep 15 14:05:15 2017 +0200 scsi: sg: factor out sg_fill_request_table() commit 4759df905a474d245752c9dc94288e779b8734dd upstream. Factor out sg_fill_request_table() for better readability. [mkp: typos, applied by hand] Signed-off-by: Hannes Reinecke Reviewed-by: Bart Van Assche Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit af9c32ce054200da0275a735c451b7335b8f14b4 Author: Dan Carpenter Date: Thu Aug 17 10:09:54 2017 +0300 scsi: sg: off by one in sg_ioctl() commit bd46fc406b30d1db1aff8dabaff8d18bb423fdcf upstream. If "val" is SG_MAX_QUEUE then we are one element beyond the end of the "rinfo" array so the > should be >=. Fixes: 109bade9c625 ("scsi: sg: use standard lists for sg_requests") Signed-off-by: Dan Carpenter Acked-by: Douglas Gilbert Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit c9a4746fe451335767c42762b7a659e8f264210e Author: Hannes Reinecke Date: Fri Apr 7 09:34:16 2017 +0200 scsi: sg: use standard lists for sg_requests commit 109bade9c625c89bb5ea753aaa1a0a97e6fbb548 upstream. 'Sg_request' is using a private list implementation; convert it to standard lists. Signed-off-by: Hannes Reinecke Reviewed-by: Johannes Thumshirn Tested-by: Johannes Thumshirn Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit b732e51155580eea241c4c014306cb16e7d5aa59 Author: Hannes Reinecke Date: Fri Apr 7 09:34:13 2017 +0200 scsi: sg: remove 'save_scat_len' commit 136e57bf43dc4babbfb8783abbf707d483cacbe3 upstream. Unused. Signed-off-by: Hannes Reinecke Reviewed-by: Johannes Thumshirn Tested-by: Johannes Thumshirn Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 4eda02ad92142ebdf011218540e1c8d2399fd4e5 Author: Todd Poynor Date: Tue Aug 15 21:48:43 2017 -0700 scsi: sg: recheck MMAP_IO request length with lock held commit 8d26f491116feaa0b16de370b6a7ba40a40fa0b4 upstream. Commit 1bc0eb044615 ("scsi: sg: protect accesses to 'reserved' page array") adds needed concurrency protection for the "reserve" buffer. Some checks that are initially made outside the lock are replicated once the lock is taken to ensure the checks and resulting decisions are made using consistent state. The check that a request with flag SG_FLAG_MMAP_IO set fits in the reserve buffer also needs to be performed again under the lock to ensure the reserve buffer length compared against matches the value in effect when the request is linked to the reserve buffer. An -ENOMEM should be returned in this case, instead of switching over to an indirect buffer as for non-MMAP_IO requests. Signed-off-by: Todd Poynor Acked-by: Douglas Gilbert Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit faf0e0de9c4f9ab9b80e1396128c9c804af09fe2 Author: Todd Poynor Date: Tue Aug 15 22:41:08 2017 -0700 scsi: sg: protect against races between mmap() and SG_SET_RESERVED_SIZE commit 6a8dadcca81fceff9976e8828cceb072873b7bd5 upstream. Take f_mutex around mmap() processing to protect against races with the SG_SET_RESERVED_SIZE ioctl. Ensure the reserve buffer length remains consistent during the mapping operation, and set the "mmap called" flag to prevent further changes to the reserved buffer size as an atomic operation with the mapping. [mkp: fixed whitespace] Signed-off-by: Todd Poynor Acked-by: Douglas Gilbert Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 6c9fe95373f5ac073c657d31beb369df0f14db60 Author: Hannes Reinecke Date: Mon Apr 24 10:26:36 2017 +0200 scsi: sg: reset 'res_in_use' after unlinking reserved array commit e791ce27c3f6a1d3c746fd6a8f8e36c9540ec6f9 upstream. Once the reserved page array is unused we can reset the 'res_in_use' state; here we can do a lazy update without holding the mutex as we only need to check against concurrent access, not concurrent release. [mkp: checkpatch] Fixes: 1bc0eb044615 ("scsi: sg: protect accesses to 'reserved' page array") Signed-off-by: Hannes Reinecke Reviewed-by: Johannes Thumshirn Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Cc: Todd Poynor Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 5bb6526728fd517cae788fc90008fd1f614f31a7 Author: Hannes Reinecke Date: Fri Apr 7 09:34:14 2017 +0200 scsi: sg: protect accesses to 'reserved' page array commit 1bc0eb0446158cc76562176b80623aa119afee5b upstream. The 'reserved' page array is used as a short-cut for mapping data, saving us to allocate pages per request. However, the 'reserved' array is only capable of holding one request, so this patch introduces a mutex for protect 'sg_fd' against concurrent accesses. Signed-off-by: Hannes Reinecke Reviewed-by: Johannes Thumshirn Tested-by: Johannes Thumshirn Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman [toddpoynor@google.com: backport to 3.18-4.9, fixup for bad ioctl SG_SET_FORCE_LOW_DMA code removed in later versions and not modified by the original patch.] Signed-off-by: Hannes Reinecke Reviewed-by: Johannes Thumshirn Tested-by: Johannes Thumshirn Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Todd Poynor Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit f4c55b72c7d3d87945acdee027d7b07cdbc2f8b7 Author: Ben Hutchings Date: Thu May 28 18:54:25 2020 +0100 scsi: sg: Change next_cmd_len handling to mirror upstream Change the type of next_cmd_len to unsigned char, done in upstream commit 65c26a0f3969 "sg: relax 16 byte cdb restriction". Move the range check from sg_write() to sg_ioctl(), which was done by that commit and commit bf33f87dd04c "scsi: sg: check length passed to SG_NEXT_CMD_LEN". Continue limiting the command length to MAX_COMMAND_SIZE (16). Signed-off-by: Ben Hutchings commit fc23502b1025b597c6cf4b479b52a466724944a1 Author: Akinobu Mita Date: Mon Jun 2 22:56:46 2014 +0900 sg: prevent integer overflow when converting from sectors to bytes commit 46f69e6a6bbbf3858617c8729e31895846c15a79 upstream. This prevents integer overflow when converting the request queue's max_sectors from sectors to bytes. However, this is a preparation for extending the data type of max_sectors in struct Scsi_Host and scsi_host_template. So, it is impossible to happen this integer overflow for now, because SCSI low-level drivers can not specify max_sectors greater than 0xffff due to the data type limitation. Signed-off-by: Akinobu Mita Acked by: Douglas Gilbert Signed-off-by: Christoph Hellwig Signed-off-by: Ben Hutchings commit 3a27c0defb0315760100f8b1adc7c4acbe04c884 Author: Douglas Gilbert Date: Wed Jun 25 14:08:03 2014 +0200 sg: O_EXCL and other lock handling commit cc833acbee9db5ca8c6162b015b4c93863c6f821 upstream. This addresses a problem reported by Vaughan Cao concerning the correctness of the O_EXCL logic in the sg driver. POSIX doesn't defined O_EXCL semantics on devices but "allow only one open file descriptor at a time per sg device" is a rough definition. The sg driver's semantics have been to wait on an open() when O_NONBLOCK is not given and there are O_EXCL headwinds. Nasty things can happen during that wait such as the device being detached (removed). So multiple locks are reworked in this patch making it large and hard to break down into digestible bits. This patch is against Linus's current git repository which doesn't include any sg patches sent in the last few weeks. Hence this patch touches as little as possible that it doesn't need to and strips out most SCSI_LOG_TIMEOUT() changes in v3 because Hannes said he was going to rework all that stuff. The sg3_utils package has several test programs written to test this patch. See examples/sg_tst_excl*.cpp . Not all the locks and flags in sg have been re-worked in this patch, notably sg_request::done . That can wait for a follow-up patch if this one meets with approval. Signed-off-by: Douglas Gilbert Reviewed-by: Hannes Reinecke Signed-off-by: Ben Hutchings commit 60a613dc22ee9932c3ba67eadb08de357e36f01f Author: Qing Xu Date: Thu Jan 2 10:39:26 2020 +0800 mwifiex: Fix possible buffer overflows in mwifiex_ret_wmm_get_status() commit 3a9b153c5591548612c3955c9600a98150c81875 upstream. mwifiex_ret_wmm_get_status() calls memcpy() without checking the destination size.Since the source is given from remote AP which contains illegal wmm elements , this may trigger a heap buffer overflow. Fix it by putting the length check before calling memcpy(). Signed-off-by: Qing Xu Signed-off-by: Kalle Valo [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit f0c210c885dbc5000d3c3e27723beedda5988cee Author: Qing Xu Date: Thu Jan 2 10:39:27 2020 +0800 mwifiex: Fix possible buffer overflows in mwifiex_cmd_append_vsie_tlv() commit b70261a288ea4d2f4ac7cd04be08a9f0f2de4f4d upstream. mwifiex_cmd_append_vsie_tlv() calls memcpy() without checking the destination size may trigger a buffer overflower, which a local user could use to cause denial of service or the execution of arbitrary code. Fix it by putting the length check before calling memcpy(). Signed-off-by: Qing Xu Signed-off-by: Kalle Valo [bwh: Backported to 3.16: - Use dev_info() instead of mwifiex_dbg() - Adjust filename] Signed-off-by: Ben Hutchings commit a226f907bd999713e9349bc35aa133cf519a864e Author: Dan Carpenter Date: Tue Jan 14 15:34:14 2020 +0300 scsi: mptfusion: Fix double fetch bug in ioctl commit 28d76df18f0ad5bcf5fa48510b225f0ed262a99b upstream. Tom Hatskevich reported that we look up "iocp" then, in the called functions we do a second copy_from_user() and look it up again. The problem that could cause is: drivers/message/fusion/mptctl.c 674 /* All of these commands require an interrupt or 675 * are unknown/illegal. 676 */ 677 if ((ret = mptctl_syscall_down(iocp, nonblock)) != 0) ^^^^ We take this lock. 678 return ret; 679 680 if (cmd == MPTFWDOWNLOAD) 681 ret = mptctl_fw_download(arg); ^^^ Then the user memory changes and we look up "iocp" again but a different one so now we are holding the incorrect lock and have a race condition. 682 else if (cmd == MPTCOMMAND) 683 ret = mptctl_mpt_command(arg); The security impact of this bug is not as bad as it could have been because these operations are all privileged and root already has enormous destructive power. But it's still worth fixing. This patch passes the "iocp" pointer to the functions to avoid the second lookup. That deletes 100 lines of code from the driver so it's a nice clean up as well. Link: https://lore.kernel.org/r/20200114123414.GA7957@kadam Reported-by: Tom Hatskevich Reviewed-by: Greg Kroah-Hartman Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit b79b2c774d18d9f742c6dee7c8af3d8fd75d1852 Author: Dan Carpenter Date: Thu Jan 25 17:27:27 2018 +0300 scsi: mptfusion: Add bounds check in mptctl_hp_targetinfo() commit a7043e9529f3c367cc4d82997e00be034cbe57ca upstream. My static checker complains about an out of bounds read: drivers/message/fusion/mptctl.c:2786 mptctl_hp_targetinfo() error: buffer overflow 'hd->sel_timeout' 255 <= u32max. It's true that we probably should have a bounds check here. Signed-off-by: Dan Carpenter Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit 575f200adca1fe48df15063b1a5673a9b5f713bd Author: Alan Stern Date: Sat Mar 28 16:18:11 2020 -0400 USB: core: Fix free-while-in-use bug in the USB S-Glibrary commit 056ad39ee9253873522f6469c3364964a322912b upstream. FuzzUSB (a variant of syzkaller) found a free-while-still-in-use bug in the USB scatter-gather library: BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:26 [inline] BUG: KASAN: use-after-free in usb_hcd_unlink_urb+0x5f/0x170 drivers/usb/core/hcd.c:1607 Read of size 4 at addr ffff888065379610 by task kworker/u4:1/27 CPU: 1 PID: 27 Comm: kworker/u4:1 Not tainted 5.5.11 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueue: scsi_tmf_2 scmd_eh_abort_handler Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xce/0x128 lib/dump_stack.c:118 print_address_description.constprop.4+0x21/0x3c0 mm/kasan/report.c:374 __kasan_report+0x153/0x1cb mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:639 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x152/0x1b0 mm/kasan/generic.c:192 __kasan_check_read+0x11/0x20 mm/kasan/common.c:95 atomic_read include/asm-generic/atomic-instrumented.h:26 [inline] usb_hcd_unlink_urb+0x5f/0x170 drivers/usb/core/hcd.c:1607 usb_unlink_urb+0x72/0xb0 drivers/usb/core/urb.c:657 usb_sg_cancel+0x14e/0x290 drivers/usb/core/message.c:602 usb_stor_stop_transport+0x5e/0xa0 drivers/usb/storage/transport.c:937 This bug occurs when cancellation of the S-G transfer races with transfer completion. When that happens, usb_sg_cancel() may continue to access the transfer's URBs after usb_sg_wait() has freed them. The bug is caused by the fact that usb_sg_cancel() does not take any sort of reference to the transfer, and so there is nothing to prevent the URBs from being deallocated while the routine is trying to use them. The fix is to take such a reference by incrementing the transfer's io->count field while the cancellation is in progres and decrementing it afterward. The transfer's URBs are not deallocated until io->complete is triggered, which happens when io->count reaches zero. Signed-off-by: Alan Stern Reported-and-tested-by: Kyungtae Kim CC: Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2003281615140.14837-100000@netrider.rowland.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 07d5d558e8711be09caa3783a8514514b3308e0f Author: David Mosberger Date: Tue Mar 8 14:42:49 2016 -0700 drivers: usb: core: Minimize irq disabling in usb_sg_cancel() commit 5f2e5fb873e269fcb806165715d237f0de4ecf1d upstream. Restructure usb_sg_cancel() so we don't have to disable interrupts while cancelling the URBs. Suggested-by: Alan Stern Signed-off-by: David Mosberger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 371262ec7bbf0ffc4b2a66c3f7c9230ee5e6a2c5 Author: David Mosberger Date: Tue Mar 8 14:42:48 2016 -0700 drivers: usb: core: Don't disable irqs in usb_sg_wait() during URB submit. commit 98b74b0ee57af1bcb6e8b2e76e707a71c5ef8ec9 upstream. usb_submit_urb() may take quite long to execute. For example, a single sg list may have 30 or more entries, possibly leading to that many calls to DMA-map pages. This can cause interrupt latency of several hundred micro-seconds. Avoid the problem by releasing the io->lock spinlock and re-enabling interrupts before calling usb_submit_urb(). This opens races with usb_sg_cancel() and sg_complete(). Handle those races by using usb_block_urb() to stop URBs from being submitted after usb_sg_cancel() or sg_complete() with error. Note that usb_unlink_urb() is guaranteed to return -ENODEV if !io->urbs[i]->dev and since the -ENODEV case is already handled, we don't have to check for !io->urbs[i]->dev explicitly. Before this change, reading 512MB from an ext3 filesystem on a USB memory stick showed a throughput of 12 MB/s with about 500 missed deadlines. With this change, reading the same file gave the same throughput but only one or two missed deadlines. Signed-off-by: David Mosberger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 9592b90cdc99f58e0674e64037c422ea7e9aa367 Author: Paul Moore Date: Tue Apr 28 09:59:02 2020 -0400 selinux: properly handle multiple messages in selinux_netlink_send() commit fb73974172ffaaf57a7c42f35424d9aece1a5af6 upstream. Fix the SELinux netlink_send hook to properly handle multiple netlink messages in a single sk_buff; each message is parsed and subject to SELinux access control. Prior to this patch, SELinux only inspected the first message in the sk_buff. Cc: stable@vger.kernel.org Reported-by: Dmitry Vyukov Reviewed-by: Stephen Smalley Signed-off-by: Paul Moore [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 976dc007c4fde824b46cd40d001a17734ce9e333 Author: Vladis Dronov Date: Thu Dec 24 11:09:41 2015 -0500 selinux: rate-limit netlink message warnings in selinux_nlmsg_perm() commit 76319946f321e30872dd72af7de867cb26e7a373 upstream. Any process is able to send netlink messages with invalid types. Make the warning rate-limited to prevent too much log spam. The warning is supposed to help to find misbehaving programs, so print the triggering command name and pid. Reported-by: Florian Weimer Signed-off-by: Vladis Dronov [PM: subject line tweak to make checkpatch.pl happy] Signed-off-by: Paul Moore Signed-off-by: Ben Hutchings commit b122516be7a9cccceb48dc7ee6ff1717b39e6ae2 Author: Marek Milkovic Date: Thu Jun 4 16:22:16 2015 -0400 selinux: Print 'sclass' as string when unrecognized netlink message occurs commit cded3fffbeab777e6ad2ec05d4a3b62c5caca0f3 upstream. This prints the 'sclass' field as string instead of index in unrecognized netlink message. The textual representation makes it easier to distinguish the right class. Signed-off-by: Marek Milkovic Acked-by: Stephen Smalley [PM: 80-char width fixes] Signed-off-by: Paul Moore Signed-off-by: Ben Hutchings commit 68c46f7a2891110c582a94a807018d231e81eefe Author: Richard Guy Briggs Date: Wed Nov 12 14:01:34 2014 -0500 selinux: convert WARN_ONCE() to printk() in selinux_nlmsg_perm() commit d950f84c1c6658faec2ecbf5b09f7e7191953394 upstream. Convert WARN_ONCE() to printk() in selinux_nlmsg_perm(). After conversion from audit_log() in commit e173fb26, WARN_ONCE() was deemed too alarmist, so switch it to printk(). Signed-off-by: Richard Guy Briggs [PM: Changed to printk(WARNING) so we catch all of the different invalid netlink messages. In Richard's defense, he brought this point up earlier, but I didn't understand his point at the time.] Signed-off-by: Paul Moore Signed-off-by: Ben Hutchings commit bf5cabe51a6441f354d19f5048a6f0aa9f3c9787 Author: Richard Guy Briggs Date: Thu Sep 18 20:50:17 2014 -0400 selinux: cleanup error reporting in selinux_nlmsg_perm() commit e173fb2646a832b424c80904c306b816760ce477 upstream. Convert audit_log() call to WARN_ONCE(). Rename "type=" to nlmsg_type=" to avoid confusion with the audit record type. Added "protocol=" to help track down which protocol (NETLINK_AUDIT?) was used within the netlink protocol family. Signed-off-by: Richard Guy Briggs [Rewrote the patch subject line] Signed-off-by: Paul Moore Signed-off-by: Ben Hutchings commit fd394f42092fe81e28e2564265311b995ec4f5dc Author: Jouni Hogander Date: Tue Dec 17 13:46:34 2019 +0200 net-sysfs: Call dev_hold always in rx_queue_add_kobject commit ddd9b5e3e765d8ed5a35786a6cb00111713fe161 upstream. Dev_hold has to be called always in rx_queue_add_kobject. Otherwise usage count drops below 0 in case of failure in kobject_init_and_add. Fixes: b8eb718348b8 ("net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject") Reported-by: syzbot Cc: Tetsuo Handa Cc: David Miller Cc: Lukas Bulwahn Signed-off-by: Jouni Hogander Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit a7750e90935c481ba6188fb282d87a3368cfcfac Author: Jouni Hogander Date: Thu Dec 5 15:57:07 2019 +0200 net-sysfs: Call dev_hold always in netdev_queue_add_kobject commit e0b60903b434a7ee21ba8d8659f207ed84101e89 upstream. Dev_hold has to be called always in netdev_queue_add_kobject. Otherwise usage count drops below 0 in case of failure in kobject_init_and_add. Fixes: b8eb718348b8 ("net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject") Reported-by: Hulk Robot Cc: Tetsuo Handa Cc: David Miller Cc: Lukas Bulwahn Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 6b07736e72bc1546400d085485d92c256408c5ea Author: Eric Dumazet Date: Wed Nov 20 19:19:07 2019 -0800 net-sysfs: fix netdev_queue_add_kobject() breakage commit 48a322b6f9965b2f1e4ce81af972f0e287b07ed0 upstream. kobject_put() should only be called in error path. Fixes: b8eb718348b8 ("net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject") Signed-off-by: Eric Dumazet Cc: Jouni Hogander Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 3bae3560840ee30c9f2262b69196ba4dbc6086f6 Author: Jouni Hogander Date: Wed Nov 20 09:08:16 2019 +0200 net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject commit b8eb718348b8fb30b5a7d0a8fce26fb3f4ac741b upstream. kobject_init_and_add takes reference even when it fails. This has to be given up by the caller in error handling. Otherwise memory allocated by kobject_init_and_add is never freed. Originally found by Syzkaller: BUG: memory leak unreferenced object 0xffff8880679f8b08 (size 8): comm "netdev_register", pid 269, jiffies 4294693094 (age 12.132s) hex dump (first 8 bytes): 72 78 2d 30 00 36 20 d4 rx-0.6 . backtrace: [<000000008c93818e>] __kmalloc_track_caller+0x16e/0x290 [<000000001f2e4e49>] kvasprintf+0xb1/0x140 [<000000007f313394>] kvasprintf_const+0x56/0x160 [<00000000aeca11c8>] kobject_set_name_vargs+0x5b/0x140 [<0000000073a0367c>] kobject_init_and_add+0xd8/0x170 [<0000000088838e4b>] net_rx_queue_update_kobjects+0x152/0x560 [<000000006be5f104>] netdev_register_kobject+0x210/0x380 [<00000000e31dab9d>] register_netdevice+0xa1b/0xf00 [<00000000f68b2465>] __tun_chr_ioctl+0x20d5/0x3dd0 [<000000004c50599f>] tun_chr_ioctl+0x2f/0x40 [<00000000bbd4c317>] do_vfs_ioctl+0x1c7/0x1510 [<00000000d4c59e8f>] ksys_ioctl+0x99/0xb0 [<00000000946aea81>] __x64_sys_ioctl+0x78/0xb0 [<0000000038d946e5>] do_syscall_64+0x16f/0x580 [<00000000e0aa5d8f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [<00000000285b3d1a>] 0xffffffffffffffff Cc: David Miller Cc: Lukas Bulwahn Signed-off-by: Jouni Hogander Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 78c31fa288ee2f58f84c792cc75d93efd073f4cf Author: yangerkun Date: Wed Feb 26 11:54:35 2020 +0800 slip: not call free_netdev before rtnl_unlock in slip_open commit f596c87005f7b1baeb7d62d9a9e25d68c3dfae10 upstream. As the description before netdev_run_todo, we cannot call free_netdev before rtnl_unlock, fix it by reorder the code. Signed-off-by: yangerkun Reviewed-by: Oliver Hartkopp Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit e143aa385d0d7bd954fe97d4719f8dce933e67f8 Author: Jouni Hogander Date: Mon Nov 25 14:23:43 2019 +0200 slip: Fix use-after-free Read in slip_open commit e58c1912418980f57ba2060017583067f5f71e52 upstream. Slip_open doesn't clean-up device which registration failed from the slip_devs device list. On next open after failure this list is iterated and freed device is accessed. Fix this by calling sl_free_netdev in error path. Here is the trace from the Syzbot: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:634 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132 sl_sync drivers/net/slip/slip.c:725 [inline] slip_open+0xecd/0x11b7 drivers/net/slip/slip.c:801 tty_ldisc_open.isra.0+0xa3/0x110 drivers/tty/tty_ldisc.c:469 tty_set_ldisc+0x30e/0x6b0 drivers/tty/tty_ldisc.c:596 tiocsetd drivers/tty/tty_io.c:2334 [inline] tty_ioctl+0xe8d/0x14f0 drivers/tty/tty_io.c:2594 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xdb6/0x13e0 fs/ioctl.c:696 ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: 3b5a39979daf ("slip: Fix memory leak in slip_open error path") Reported-by: syzbot+4d5170758f3762109542@syzkaller.appspotmail.com Cc: David Miller Cc: Oliver Hartkopp Cc: Lukas Bulwahn Signed-off-by: Jouni Hogander Signed-off-by: David S. Miller [bwh: Backported to 3.16: sl_free_netdev() calls free_netdev() here, so delete the direct call to free_netdev()] Signed-off-by: Ben Hutchings commit 103921f069ae9189806fe5913beb40c1def7ae56 Author: Jouni Hogander Date: Wed Nov 13 13:45:02 2019 +0200 slip: Fix memory leak in slip_open error path commit 3b5a39979dafea9d0cd69c7ae06088f7a84cdafa upstream. Driver/net/can/slcan.c is derived from slip.c. Memory leak was detected by Syzkaller in slcan. Same issue exists in slip.c and this patch is addressing the leak in slip.c. Here is the slcan memory leak trace reported by Syzkaller: BUG: memory leak unreferenced object 0xffff888067f65500 (size 4096): comm "syz-executor043", pid 454, jiffies 4294759719 (age 11.930s) hex dump (first 32 bytes): 73 6c 63 61 6e 30 00 00 00 00 00 00 00 00 00 00 slcan0.......... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000a06eec0d>] __kmalloc+0x18b/0x2c0 [<0000000083306e66>] kvmalloc_node+0x3a/0xc0 [<000000006ac27f87>] alloc_netdev_mqs+0x17a/0x1080 [<0000000061a996c9>] slcan_open+0x3ae/0x9a0 [<000000001226f0f9>] tty_ldisc_open.isra.1+0x76/0xc0 [<0000000019289631>] tty_set_ldisc+0x28c/0x5f0 [<000000004de5a617>] tty_ioctl+0x48d/0x1590 [<00000000daef496f>] do_vfs_ioctl+0x1c7/0x1510 [<0000000059068dbc>] ksys_ioctl+0x99/0xb0 [<000000009a6eb334>] __x64_sys_ioctl+0x78/0xb0 [<0000000053d0332e>] do_syscall_64+0x16f/0x580 [<0000000021b83b99>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [<000000008ea75434>] 0xfffffffffffffff Cc: "David S. Miller" Cc: Oliver Hartkopp Cc: Lukas Bulwahn Signed-off-by: Jouni Hogander Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 8262bc14b32853532c2fba0649524afa951c983b Author: Oliver Hartkopp Date: Sat Mar 21 14:08:29 2020 +0100 slcan: not call free_netdev before rtnl_unlock in slcan_open commit 2091a3d42b4f339eaeed11228e0cbe9d4f92f558 upstream. As the description before netdev_run_todo, we cannot call free_netdev before rtnl_unlock, fix it by reorder the code. This patch is a 1:1 copy of upstream slip.c commit f596c87005f7 ("slip: not call free_netdev before rtnl_unlock in slip_open"). Reported-by: yangerkun Signed-off-by: Oliver Hartkopp Signed-off-by: David S. Miller [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit fc32a080b625b4e9f997468eafbacc537229c7ef Author: Jouni Hogander Date: Wed Nov 27 08:40:26 2019 +0200 can: slcan: Fix use-after-free Read in slcan_open commit 9ebd796e24008f33f06ebea5a5e6aceb68b51794 upstream. Slcan_open doesn't clean-up device which registration failed from the slcan_devs device list. On next open this list is iterated and freed device is accessed. Fix this by calling slc_free_netdev in error path. Driver/net/can/slcan.c is derived from slip.c. Use-after-free error was identified in slip_open by syzboz. Same bug is in slcan.c. Here is the trace from the Syzbot slip report: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:634 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132 sl_sync drivers/net/slip/slip.c:725 [inline] slip_open+0xecd/0x11b7 drivers/net/slip/slip.c:801 tty_ldisc_open.isra.0+0xa3/0x110 drivers/tty/tty_ldisc.c:469 tty_set_ldisc+0x30e/0x6b0 drivers/tty/tty_ldisc.c:596 tiocsetd drivers/tty/tty_io.c:2334 [inline] tty_ioctl+0xe8d/0x14f0 drivers/tty/tty_io.c:2594 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xdb6/0x13e0 fs/ioctl.c:696 ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: ed50e1600b44 ("slcan: Fix memory leak in error path") Cc: Wolfgang Grandegger Cc: Marc Kleine-Budde Cc: David Miller Cc: Oliver Hartkopp Cc: Lukas Bulwahn Signed-off-by: Jouni Hogander Acked-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde [bwh: Backported to 3.16: slc_free_netdev() calls free_netdev() here, so delete the direct call to free_netdev()] Signed-off-by: Ben Hutchings commit ff41ac4dd357b10010949dc50e640c9eb5d5f052 Author: Jouni Hogander Date: Wed Nov 13 12:08:01 2019 +0200 slcan: Fix memory leak in error path commit ed50e1600b4483c049ce76e6bd3b665a6a9300ed upstream. This patch is fixing memory leak reported by Syzkaller: BUG: memory leak unreferenced object 0xffff888067f65500 (size 4096): comm "syz-executor043", pid 454, jiffies 4294759719 (age 11.930s) hex dump (first 32 bytes): 73 6c 63 61 6e 30 00 00 00 00 00 00 00 00 00 00 slcan0.......... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000a06eec0d>] __kmalloc+0x18b/0x2c0 [<0000000083306e66>] kvmalloc_node+0x3a/0xc0 [<000000006ac27f87>] alloc_netdev_mqs+0x17a/0x1080 [<0000000061a996c9>] slcan_open+0x3ae/0x9a0 [<000000001226f0f9>] tty_ldisc_open.isra.1+0x76/0xc0 [<0000000019289631>] tty_set_ldisc+0x28c/0x5f0 [<000000004de5a617>] tty_ioctl+0x48d/0x1590 [<00000000daef496f>] do_vfs_ioctl+0x1c7/0x1510 [<0000000059068dbc>] ksys_ioctl+0x99/0xb0 [<000000009a6eb334>] __x64_sys_ioctl+0x78/0xb0 [<0000000053d0332e>] do_syscall_64+0x16f/0x580 [<0000000021b83b99>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [<000000008ea75434>] 0xffffffffffffffff Cc: Wolfgang Grandegger Cc: Marc Kleine-Budde Cc: Lukas Bulwahn Signed-off-by: Jouni Hogander Signed-off-by: Marc Kleine-Budde Signed-off-by: Ben Hutchings