- 17 Sep, 2019 14 commits
-
-
Kangjie Lu authored
BugLink: https://bugs.launchpad.net/bugs/1840081 [ Upstream commit e08f0761 ] In case ioremap fails, the fix returns -ENOMEM to avoid NULL pointer dereference. Signed-off-by:
Kangjie Lu <kjlu@umn.edu> Acked-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Reviewed-by:
Mukesh Ojha <mojha@codeaurora.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Lubomir Rintel authored
BugLink: https://bugs.launchpad.net/bugs/1840081 [ Upstream commit 0c7aa329 ] The commit d790b7ed ("[media] vb2-dma-sg: move dma_(un)map_sg here") left dma_desc_nent unset. It previously contained the number of DMA descriptors as returned from dma_map_sg(). We can now (since the commit referred to above) obtain the same value from the sg_table and drop dma_desc_nent altogether. Tested on OLPC XO-1.75 machine. Doesn't affect the OLPC XO-1's Cafe driver, since that one doesn't do DMA. [mchehab+samsung@kernel.org: fix a checkpatch warning] Fixes: d790b7ed ("[media] vb2-dma-sg: move dma_(un)map_sg here") Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Christophe Leroy authored
BugLink: https://bugs.launchpad.net/bugs/1840081 [ Upstream commit 3e03e792 ] Selftests report the following: [ 2.984845] alg: skcipher: cbc-aes-talitos encryption test failed (wrong output IV) on test vector 0, cfg="in-place" [ 2.995377] 00000000: 3d af ba 42 9d 9e b4 30 b4 22 da 80 2c 9f ac 41 [ 3.032673] alg: skcipher: cbc-des-talitos encryption test failed (wrong output IV) on test vector 0, cfg="in-place" [ 3.043185] 00000000: fe dc ba 98 76 54 32 10 [ 3.063238] alg: skcipher: cbc-3des-talitos encryption test failed (wrong output IV) on test vector 0, cfg="in-place" [ 3.073818] 00000000: 7d 33 88 93 0f 93 b2 42 This above dumps show that the actual output IV is indeed the input IV. This is due to the IV not being copied back into the request. This patch fixes that. Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Reviewed-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Oliver Neukum authored
BugLink: https://bugs.launchpad.net/bugs/1840081 [ Upstream commit 6cf97230 ] dvb_usb_device_exit() frees and uses the device name in that order. Fix by storing the name in a buffer before freeing it. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Reported-by: syzbot+26ec41e9f788b3eba396@syzkaller.appspotmail.com Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Jeremy Sowden authored
BugLink: https://bugs.launchpad.net/bugs/1840081 [ Upstream commit 17f78dd1 ] A handler for BATADV_TVLV_ROAM was being registered when the translation-table was initialized, but not unregistered when the translation-table was freed. Unregister it. Fixes: 122edaa0 ("batman-adv: tvlv - convert roaming adv packet to use tvlv unicast packets") Reported-by: syzbot+d454a826e670502484b8@syzkaller.appspotmail.com Signed-off-by:
Jeremy Sowden <jeremy@azazel.net> Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by:
-
Anilkumar Kolli authored
BugLink: https://bugs.launchpad.net/bugs/1840081 [ Upstream commit d8792393 ] Increase pulse width range from 1-2usec to 0-4usec. During data traffic HW occasionally fails detecting radar pulses, so that SW cannot get enough radar reports to achieve the success rate. Tested ath10k hw and fw: * QCA9888(10.4-3.5.1-00052) * QCA4019(10.4-3.2.1.1-00017) * QCA9984(10.4-3.6-00104) * QCA988X(10.2.4-1.0-00041) Tested ath9k hw: AR9300 Tested-by:
Tamizh chelvam <tamizhr@codeaurora.org> Signed-off-by:
Anilkumar Kolli <akolli@codeaurora.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1840081 [ Upstream commit 5d6751ea ] The "ev->traffic_class" and "reply->ac" variables come from the network and they're used as an offset into the wmi->stream_exist_for_ac[] array. Those variables are u8 so they can be 0-255 but the stream_exist_for_ac[] array only has WMM_NUM_AC (4) elements. We need to add a couple bounds checks to prevent array overflows. I also modified one existing check from "if (traffic_class > 3) {" to "if (traffic_class >= WMM_NUM_AC) {" just to make them all consistent. Fixes: bdcd8170 (" Add ath6kl cleaned up driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Tim Schumacher authored
BugLink: https://bugs.launchpad.net/bugs/1840081 [ Upstream commit 2f90c7e5 ] Right now, if an error is encountered during the SREV register read (i.e. an EIO in ath9k_regread()), that error code gets passed all the way to __ath9k_hw_init(), where it is visible during the "Chip rev not supported" message. ath9k_htc 1-1.4:1.0: ath9k_htc: HTC initialized with 33 credits ath: phy2: Mac Chip Rev 0x0f.3 is not supported by this driver ath: phy2: Unable to initialize hardware; initialization status: -95 ath: phy2: Unable to initialize hardware; initialization status: -95 ath9k_htc: Failed to initialize the device Check for -EIO explicitly in ath9k_hw_read_revisions() and return a boolean based on the success of the operation. Check for that in __ath9k_hw_init() and abort with a more debugging-friendly message if reading the revisions wasn't successful. ath9k_htc 1-1.4:1.0: ath9k_htc: HTC initialized with 33 credits ath: phy2: Failed to read SREV register ath: phy2: Could not read hardware revision ath: phy2: Unable to initialize hardware; initialization status: -95 ath: phy2: Unable to initialize hardware; initialization status: -95 ath9k_htc: Failed to initialize the device This helps when debugging by directly showing the first point of failure and it could prevent possible errors if a 0x0f.3 revision is ever supported. Signed-off-by:
Tim Schumacher <timschumi@gmx.de> Signed-off-by:
-
Surabhi Vishnoi authored
BugLink: https://bugs.launchpad.net/bugs/1840081 [ Upstream commit 97354f2c ] Currently mac80211 do not support probe response template for mesh point. When WMI_SERVICE_BEACON_OFFLOAD is enabled, host driver tries to configure probe response template for mesh, but it fails because the interface type is not NL80211_IFTYPE_AP but NL80211_IFTYPE_MESH_POINT. To avoid this failure, skip sending probe response template to firmware for mesh point. Tested HW: WCN3990/QCA6174/QCA9984 Signed-off-by:
Surabhi Vishnoi <svishnoi@codeaurora.org> Signed-off-by:
-
Sven Van Asbroeck authored
BugLink: https://bugs.launchpad.net/bugs/1840081 [ Upstream commit 2b8066c3 ] If probe() fails anywhere beyond the point where sdma_get_firmware() is called, then a kernel oops may occur. Problematic sequence of events: 1. probe() calls sdma_get_firmware(), which schedules the firmware callback to run when firmware becomes available, using the sdma instance structure as the context 2. probe() encounters an error, which deallocates the sdma instance structure 3. firmware becomes available, firmware callback is called with deallocated sdma instance structure 4. use after free - kernel oops ! Solution: only attempt to load firmware when we're certain that probe() will succeed. This guarantees that the firmware callback's context will remain valid. Note that the remove() path is unaffected by this issue: the firmware loader will increment the driver module's use count, ensuring that the module cannot be unloaded while the firmware callback is pending or running. Signed-off-by:
Sven Van Asbroeck <TheSven73@gmail.com> Reviewed-by:
Robin Gong <yibin.gong@nxp.com> [vkoul: fixed braces for if condition] Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Kevin Darbyshire-Bryant authored
BugLink: https://bugs.launchpad.net/bugs/1840081 [ Upstream commit 1196364f ] calc_vmlinuz_load_addr.c requires SZ_64K to be defined for alignment purposes. It included "../../../../include/linux/sizes.h" to define that size, however "sizes.h" tries to include <linux/const.h> which assumes linux system headers. These may not exist eg. the following error was encountered when building Linux for OpenWrt under macOS: In file included from arch/mips/boot/compressed/calc_vmlinuz_load_addr.c:16: arch/mips/boot/compressed/../../../../include/linux/sizes.h:11:10: fatal error: 'linux/const.h' file not found ^~~~~~~~~~ Change makefile to force building on local linux headers instead of system headers. Also change eye-watering relative reference in include file spec. Thanks to Jo-Philip Wich & Petr Štetiar for assistance in tracking this down & fixing. Suggested-by:
Jo-Philipp Wich <jo@mein.io> Signed-off-by:
Petr Štetiar <ynezz@true.cz> Signed-off-by:
Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk> Signed-off-by:
Paul Burton <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org Signed-off-by:
-
Stefan Hellermann authored
BugLink: https://bugs.launchpad.net/bugs/1840081 [ Upstream commit db13a5ba ] While trying to get the uart with parity working I found setting even parity enabled odd parity insted. Fix the register settings to match the datasheet of AR9331. A similar patch was created by 8devices, but not sent upstream. https://github.com/8devices/openwrt-8devices/commit/77c5586ade3bb72cda010afad3f209ed0c98ea7cSigned-off-by:
Stefan Hellermann <stefan@the2masters.de> Signed-off-by:
-
Bob Peterson authored
CVE-2016-10905 Before this patch, function read_rindex_entry would set a rgrp glock's gl_object pointer to itself before inserting the rgrp into the rgrp rbtree. The problem is: if another process was also reading the rgrp in, and had already inserted its newly created rgrp, then the second call to read_rindex_entry would overwrite that value, then return a bad return code to the caller. Later, other functions would reference the now-freed rgrp memory by way of gl_object. In some cases, that could result in gfs2_rgrp_brelse being called twice for the same rgrp: once for the failed attempt and once for the "real" rgrp release. Eventually the kernel would panic. There are also a number of other things that could go wrong when a kernel module is accessing freed storage. For example, this could result in rgrp corruption because the fake rgrp would point to a fake bitmap in memory too, causing gfs2_inplace_reserve to search some random memory for free blocks, and find some, since we were never setting rgd->rd_bits to NULL before freeing it. This patch fixes the problem by not setting gl_object until we have successfully inserted the rgrp into the rbtree. Also, it sets rd_bits to NULL as it frees them, which will ensure any accidental access to the wrong rgrp will result in a kernel panic rather than file system corruption, which is preferred. Signed-off-by:
Bob Peterson <rpeterso@redhat.com> (backported from commit 36e4ad03) [ Connor Kuehl: Minor context adjustment. The hunk in read_rindex_entry() expected 'PAGE_CACHE_ALIGN' to be 'PAGE_ALIGN' but that rename is introduced in a mainline patch that is not in Xenial: 09cbfeaf "mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros" ] Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
Stefan Bader authored
Ignore: yes Signed-off-by:Stefan Bader <stefan.bader@canonical.com>
-
- 13 Sep, 2019 3 commits
-
-
Juerg Haefliger authored
Signed-off-by:Juerg Haefliger <juergh@canonical.com>
-
yongduan authored
The code assumes log_num < in_num everywhere, and that is true as long as in_num is incremented by descriptor iov count, and log_num by 1. However this breaks if there's a zero sized descriptor. As a result, if a malicious guest creates a vring desc with desc.len = 0, it may cause the host kernel to crash by overflowing the log array. This bug can be triggered during the VM migration. There's no need to log when desc.len = 0, so just don't increment log_num in this case. Fixes: 3a4d5c94 ("vhost_net: a kernel-level virtio server") Reviewed-by:
Lidong Chen <lidongchen@tencent.com> Signed-off-by:
ruippan <ruippan@tencent.com> Signed-off-by:
yongduan <yongduan@tencent.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Reviewed-by:
-
Juerg Haefliger authored
Ignore: yes Signed-off-by:
-
- 27 Aug, 2019 5 commits
-
-
Stefan Bader authored
Signed-off-by: -
Stefan Bader authored
BugLink: https://bugs.launchpad.net/bugs/1658219 This reverts commit 97ac9e61 as it is currently causing regressions in snaps which would break networking for all core16 images. Signed-off-by:
-
Stefan Bader authored
BugLink: https://bugs.launchpad.net/bugs/1841544 Properties: no-test-build Signed-off-by:
-
Stefan Bader authored
Ignore: yes Signed-off-by: -
Stefan Bader authored
BugLink: http://bugs.launchpad.net/bugs/1786013Signed-off-by:
-
- 13 Aug, 2019 18 commits
-
-
Connor Kuehl authored
Signed-off-by: -
Connor Kuehl authored
BugLink: https://bugs.launchpad.net/bugs/1840021 Properties: no-test-build Signed-off-by:
-
Connor Kuehl authored
Ignore: yes Signed-off-by: -
Connor Kuehl authored
BugLink: http://bugs.launchpad.net/bugs/1786013Signed-off-by:
-
Hans de Goede authored
BugLink: https://bugs.launchpad.net/bugs/1837117 Commit 78f3ac76 ("platform/x86: asus-wmi: Tell the EC the OS will handle the display off hotkey") causes the backlight to be permanently off on various EeePC laptop models using the eeepc-wmi driver (Asus EeePC 1015BX, Asus EeePC 1025C). The asus_wmi_set_devstate(ASUS_WMI_DEVID_BACKLIGHT, 2, NULL) call added by that commit is made conditional in this commit and only enabled in the quirk_entry structs in the asus-nb-wmi driver fixing the broken display / backlight on various EeePC laptop models. Cc: João Paulo Rechi Vita <jprvita@endlessm.com> Fixes: 78f3ac76 ("platform/x86: asus-wmi: Tell the EC the OS will handle the display off hotkey") Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> (backported from commit 1dd93f87) [PHLin: context adjustment, only add quirks for models existing in X] Signed-off-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
Eric Dumazet authored
CVE-2019-10638 According to Amit Klein and Benny Pinkas, IP ID generation is too weak and might be used by attackers. Even with recent net_hash_mix() fix (netns: provide pure entropy for net_hash_mix()) having 64bit key and Jenkins hash is risky. It is time to switch to siphash and its 128bit keys. Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Amit Klein <aksecurity@gmail.com> Reported-by:
Benny Pinkas <benny@pinkas.net> Signed-off-by:
David S. Miller <davem@davemloft.net> (backported from commit df453700) [ Connor Kuehl: Adjusted patch to communicate the id return value through the skbuf as the function signature for ipv6_proxy_select_ident is still void (whereas the patch context expects it to return a value). This function signature change doesn't happen until upstream commit: 0c19f846 "net: accept UFO datagrams from tuntap and packet" ] Signed-off-by:
-
Jason A. Donenfeld authored
CVE-2019-10638 SipHash is a 64-bit keyed hash function that is actually a cryptographically secure PRF, like HMAC. Except SipHash is super fast, and is meant to be used as a hashtable keyed lookup function, or as a general PRF for short input use cases, such as sequence numbers or RNG chaining. For the first usage: There are a variety of attacks known as "hashtable poisoning" in which an attacker forms some data such that the hash of that data will be the same, and then preceeds to fill up all entries of a hashbucket. This is a realistic and well-known denial-of-service vector. Currently hashtables use jhash, which is fast but not secure, and some kind of rotating key scheme (or none at all, which isn't good). SipHash is meant as a replacement for jhash in these cases. There are a modicum of places in the kernel that are vulnerable to hashtable poisoning attacks, either via userspace vectors or network vectors, and there's not a reliable mechanism inside the kernel at the moment to fix it. The first step toward fixing these issues is actually getting a secure primitive into the kernel for developers to use. Then we can, bit by bit, port things over to it as deemed appropriate. While SipHash is extremely fast for a cryptographically secure function, it is likely a bit slower than the insecure jhash, and so replacements will be evaluated on a case-by-case basis based on whether or not the difference in speed is negligible and whether or not the current jhash usage poses a real security risk. For the second usage: A few places in the kernel are using MD5 or SHA1 for creating secure sequence numbers, syn cookies, port numbers, or fast random numbers. SipHash is a faster and more fitting, and more secure replacement for MD5 in those situations. Replacing MD5 and SHA1 with SipHash for these uses is obvious and straight-forward, and so is submitted along with this patch series. There shouldn't be much of a debate over its efficacy. Dozens of languages are already using this internally for their hash tables and PRFs. Some of the BSDs already use this in their kernels. SipHash is a widely known high-speed solution to a widely known set of problems, and it's time we catch-up. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by:
Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Eric Biggers <ebiggers3@gmail.com> Cc: David Laight <David.Laight@aculab.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
-
Connor Kuehl authored
CVE-2019-10638 Signed-off-by:
-
John Johansen authored
This is a backport of a fix that landed as part of a larger patch in 4.17 commit 9fcf78cc ("apparmor: update domain transitions that are subsets of confinement at nnp") Domain transitions that add a new profile to the confinement stack when under NO NEW PRIVS is allowed as it can not expand privileges. However such transitions are failing due to how/where the subset test is being applied. Applying the test per profile in the profile transition and profile_onexec call backs is incorrect as it disregards the other profiles in the stack so it can not correctly determine if the old confinement stack is a subset of the new confinement stack. Move the test to after the new confinement stack is constructed. BugLink: http://bugs.launchpad.net/bugs/1839037Signed-off-by:
John Johansen <john.johansen@canonical.com> Acked-by:
-
John Johansen authored
v2. Add fix to profile_transition() also There are 2 cases where a denial in onexec profile transitions can occur that results in an apparmor WARN traceback. The first occurs if onexec is denied by policy, the second if onexec fails due to no-new-privs. A similar failure can occur in profile_transition() when directed to perform a stack, resulting in a simiar traceback with handle_onexec() replaced by profile_transition(). [1140910.816457] ------------[ cut here ]------------ [1140910.816466] WARNING: CPU: 4 PID: 32497 at /build/linux-UdetSb/linux-4.4.0/security/apparmor/file.c:136 aa_audit_file+0x16e/0x180() [1140910.816467] AppArmor WARN aa_audit_file: ((!(&sa)->apparmor_audit_data->request)): [1140910.816469] Modules linked in: [1140910.816470] xt_mark xt_comment ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs xt_REDIRECT nf_nat_redirect xt_nat veth btrfs xor raid6_pq ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs libcrc32c msr nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype br_netfilter pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) xt_CHECKSUM iptable_mangle rfcomm ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables xt_multiport iptable_filter ip_tables x_tables aufs overlay bnep uvcvideo videobuf2_vmalloc btusb videobuf2_memops videobuf2_v4l2 btrtl btbcm videobuf2_core btintel v4l2_common bluetooth videodev media binfmt_misc arc4 [1140910.816508] iwlmvm mac80211 intel_rapl snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek snd_hda_codec_generic iwlwifi joydev input_leds serio_raw cfg80211 snd_hda_intel snd_hda_codec snd_hda_core lpc_ich snd_hwdep thinkpad_acpi nvram snd_pcm snd_seq_midi mei_me snd_seq_midi_event shpchp ie31200_edac mei snd_rawmidi edac_core snd_seq wmi snd_seq_device snd_timer snd soundcore kvm_intel mac_hid kvm irqbypass coretemp parport_pc ppdev lp parport autofs4 drbg ansi_cprng algif_skcipher af_alg dm_crypt hid_generic hid_logitech_hidpp hid_logitech_dj usbhid hid uas usb_storage crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel i915 aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd i2c_algo_bit drm_kms_helper psmouse syscopyarea sysfillrect ahci sysimgblt e1000e [1140910.816544] fb_sys_fops libahci sdhci_pci drm sdhci ptp pps_core fjes video [1140910.816549] CPU: 4 PID: 32497 Comm: runc:[2:INIT] Tainted: G W OE 4.4.0-151-generic #178-Ubuntu [1140910.816551] Hardware name: LENOVO 20EFCTO1WW/20EFCTO1WW, BIOS GNET82WW (2.30 ) 03/21/2017 [1140910.816552] 0000000000000286 312c35d8d7e796cb ffff880637cef9d0 ffffffff8140b481 [1140910.816554] ffff880637cefa18 ffffffff81d02fe8 ffff880637cefa08 ffffffff81085432 [1140910.816555] ffff880108206400 ffff880637cefb6c ffff880825129b88 ffff880637cefd88 [1140910.816557] Call Trace: [1140910.816563] [<ffffffff8140b481>] dump_stack+0x63/0x82 [1140910.816567] [<ffffffff81085432>] warn_slowpath_common+0x82/0xc0 [1140910.816569] [<ffffffff810854cc>] warn_slowpath_fmt+0x5c/0x80 [1140910.816571] [<ffffffff81397ebc>] ? label_match.constprop.9+0x3dc/0x6c0 [1140910.816573] [<ffffffff813a696e>] aa_audit_file+0x16e/0x180 [1140910.816575] [<ffffffff813982dd>] profile_onexec+0x13d/0x3d0 [1140910.816577] [<ffffffff8139a33e>] handle_onexec+0x10e/0x10d0 [1140910.816581] [<ffffffff81242957>] ? vfs_getxattr_alloc+0x67/0x100 [1140910.816584] [<ffffffff81355395>] ? cap_inode_getsecurity+0x95/0x220 [1140910.816588] [<ffffffff8135965d>] ? security_inode_getsecurity+0x5d/0x70 [1140910.816590] [<ffffffff8139b417>] apparmor_bprm_set_creds+0x117/0xa60 [1140910.816591] [<ffffffff81242a8e>] ? vfs_getxattr+0x9e/0xb0 [1140910.816595] [<ffffffffc05be712>] ? ovl_getxattr+0x52/0xb0 [overlay] [1140910.816597] [<ffffffff8135619d>] ? get_vfs_caps_from_disk+0x7d/0x180 [1140910.816599] [<ffffffff81356343>] ? cap_bprm_set_creds+0xa3/0x5f0 [1140910.816601] [<ffffffff81358909>] security_bprm_set_creds+0x39/0x50 [1140910.816605] [<ffffffff812229d5>] prepare_binprm+0x85/0x190 [1140910.816607] [<ffffffff812240f4>] do_execveat_common.isra.31+0x4b4/0x770 [1140910.816610] [<ffffffff8122460a>] SyS_execve+0x3a/0x50 [1140910.816613] [<ffffffff81863ed5>] stub_execve+0x5/0x5 [1140910.816615] [<ffffffff81863b5b>] ? entry_SYSCALL_64_fastpath+0x22/0xcb [1140910.816616] ---[ end trace cf4320c1d43eedd8 ]--- This is because the error is being audited as if onexec was not denied this triggering the AA_BUG check. BugLink: http://bugs.launchpad.net/bugs/1838627Signed-off-by:
-
John Johansen authored
When an open file with cached permissions is checked for the flock permission. The cache check fails and falls through to no error instead of auditing, and returning an error. For the fall through to do a permission check, so it will audit the failed flock permission check. BugLink: https://bugs.launchpad.net/bugs/1838090 BugLink: https://bugs.launchpad.net/bugs/1658219Signed-off-by:
-
Andrea Righi authored
bcache_allocator() can call the following: bch_allocator_thread() -> bch_prio_write() -> bch_bucket_alloc() -> wait on &ca->set->bucket_wait But the wake up event on bucket_wait is supposed to come from bch_allocator_thread() itself => deadlock: [ 1158.490744] INFO: task bcache_allocato:15861 blocked for more than 10 seconds. [ 1158.495929] Not tainted 5.3.0-050300rc3-generic #201908042232 [ 1158.500653] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1158.504413] bcache_allocato D 0 15861 2 0x80004000 [ 1158.504419] Call Trace: [ 1158.504429] __schedule+0x2a8/0x670 [ 1158.504432] schedule+0x2d/0x90 [ 1158.504448] bch_bucket_alloc+0xe5/0x370 [bcache] [ 1158.504453] ? wait_woken+0x80/0x80 [ 1158.504466] bch_prio_write+0x1dc/0x390 [bcache] [ 1158.504476] bch_allocator_thread+0x233/0x490 [bcache] [ 1158.504491] kthread+0x121/0x140 [ 1158.504503] ? invalidate_buckets+0x890/0x890 [bcache] [ 1158.504506] ? kthread_park+0xb0/0xb0 [ 1158.504510] ret_from_fork+0x35/0x40 Fix by making the call to bch_prio_write() non-blocking, so that bch_allocator_thread() never waits on itself. Moreover, make sure to wake up the garbage collector thread when bch_prio_write() is failing to allocate buckets. BugLink: https://bugs.launchpad.net/bugs/1784665 BugLink: https://bugs.launchpad.net/bugs/1796292Signed-off-by:Andrea Righi <andrea.righi@canonical.com> Acked-by:
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1784665 There is couple of functions that are used exclusively in sysfs.c. Move it to there and make them static. Besides above, it will allow further clean up. No functional change intended. Signed-off-by:
Coly Li <colyli@suse.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> (cherry picked from commit ecb37ce9) Signed-off-by:
-
Bart Van Assche authored
BugLink: https://bugs.launchpad.net/bugs/1784665 Add more annotations for sparse to inform it about which functions do not have the same number of spin_lock() and spin_unlock() calls. Signed-off-by:
Bart Van Assche <bart.vanassche@wdc.com> Reviewed-by:
Michael Lyle <mlyle@lyle.org> Signed-off-by:
-
Bart Van Assche authored
BugLink: https://bugs.launchpad.net/bugs/1784665 This patch does not change any functionality. Reviewed-by:
-
Bart Van Assche authored
BugLink: https://bugs.launchpad.net/bugs/1784665Signed-off-by:
-
Bart Van Assche authored
BugLink: https://bugs.launchpad.net/bugs/1784665 Avoid that building with W=1 triggers warnings about the kernel-doc headers. Signed-off-by:
-
Bart Van Assche authored
BugLink: https://bugs.launchpad.net/bugs/1784665 This patch avoids that building with W=1 triggers complaints about switch fall-throughs. Signed-off-by:
-
