- 01 Apr, 2020 40 commits
-
-
Eugeniu Rosca authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 60e3f6e4 upstream. Reviewing a fresh portion of coverity defects in USB core (specifically CID 1458999), Alan Stern noted below in [1]: On Tue, Feb 25, 2020 at 02:39:23PM -0500, Alan Stern wrote: > A revised search finds line 997 in drivers/usb/core/hub.c and lines > 216, 269 in drivers/usb/core/port.c. (I didn't try looking in any > other directories.) AFAICT all three of these should check the > return value, although a error message in the kernel log probably > isn't needed. Factor out the usb_remove_device() change into a standalone patch to allow conflict-free integration on top of the earliest stable branches. [1] https://lore.kernel.org/lkml/Pine.LNX.4.44L0.2002251419120.1485-100000@iolanthe.rowland.org Fixes: 253e0572 ("USB: add a "remove hardware" sysfs attribute") Cc: stable@vger.kernel.org # v2.6.33+ Suggested-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Eugeniu Rosca <erosca@de.adit-jv.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by:
Kelsey Skunberg <kelsey.skunberg@canonical.com>
-
Dan Lazewatsky authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit b96ed52d upstream. LPM on the device appears to cause xHCI host controllers to claim that there isn't enough bandwidth to support additional devices. Signed-off-by:
Dan Lazewatsky <dlaz@chromium.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.com> Link: https://lore.kernel.org/r/20200226143438.1445-1-gustavo.padovan@collabora.comSigned-off-by:
-
Jim Lin authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 86d92f54 upstream. Current driver has 240 (USB2.0) and 2048 (USB3.0) as max_sectors, e.g., /sys/bus/scsi/devices/0:0:0:0/max_sectors If data access times out, driver error handling will issue a port reset. Sometimes Samsung Fit (090C:1000) flash disk will not respond to later Set Address or Get Descriptor command. Adding this quirk to limit max_sectors to 64 sectors to avoid issue occurring. Signed-off-by:
Jim Lin <jilin@nvidia.com> Acked-by:
-
Ronnie Sahlberg authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit fc513fac upstream. If from cifs_revalidate_dentry_attr() the SMB2/QUERY_INFO call fails with an error, such as STATUS_SESSION_EXPIRED, causing the session to be reconnected it is possible we will leak -EAGAIN back to the application even for system calls such as stat() where this is not a valid error. Fix this by re-trying the operation from within cifs_revalidate_dentry_attr() if cifs_get_inode_info*() returns -EAGAIN. This fixes stat() and possibly also other system calls that uses cifs_revalidate_dentry*(). Signed-off-by:
Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Reviewed-by:
Pavel Shilovsky <pshilov@microsoft.com> Reviewed-by:
Aurelien Aptel <aaptel@suse.com> CC: Stable <stable@vger.kernel.org> Signed-off-by:
-
Vasily Averin authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit 8b101a5e ] if seq_file .next fuction does not change position index, read after some lseek can generate unexpected output. Link: https://bugzilla.kernel.org/show_bug.cgi?id=206283 Link: https://lore.kernel.org/r/d44c53a7-9bc1-15c7-6d4a-0c10cb9dffce@virtuozzo.comReviewed-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Vasily Averin <vvs@virtuozzo.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Marco Felsch authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit e9a0e65e ] The da9062 hw has a minimum ping cool down phase of at least 200ms. The driver takes that into account by setting the min_hw_heartbeat_ms to 300ms and the core guarantees that the hw limit is observed for the ping() calls. But the core can't guarantee the required minimum ping cool down phase if a stop() command is send immediately after the ping() command. So it is not allowed to ping the watchdog within the stop() command as the driver does. Remove the ping can be done without doubts because the watchdog gets disabled anyway and a (re)start resets the watchdog counter too. Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20200120091729.16256-1-m.felsch@pengutronix.de [groeck: Updated description] Signed-off-by:
Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by:
-
Marek Vasut authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit 58292104 ] The Micrel KSZ8851-16MLLI datasheet DS00002357B page 12 states that BE[3:0] signals are active high. This contradicts the measurements of the behavior of the actual chip, where these signals behave as active low. For example, to read the CIDER register, the bus must expose 0xc0c0 during the address phase, which means BE[3:0]=4'b1100. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: David S. Miller <davem@davemloft.net> Cc: Lukas Wunner <lukas@wunner.de> Cc: Petr Stetiar <ynezz@true.cz> Cc: YueHaibing <yuehaibing@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Marek Vasut authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit edacb098 ] The packet data written to and read from Micrel KSZ8851-16MLLI must be byte-swapped in 16-bit mode, add this byte-swapping. Signed-off-by:
-
Marek Vasut authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit 69233bba ] This driver is mixing 8-bit and 16-bit bus accessors for reasons unknown, however the speculation is that this was some sort of attempt to support the 8-bit bus mode. As per the KS8851-16MLL documentation, all two registers accessed via the 8-bit accessors are internally 16-bit registers, so reading them using 16-bit accessors is fine. The KS_CCR read can be converted to 16-bit read outright, as it is already a concatenation of two 8-bit reads of that register. The KS_RXQCR accesses are 8-bit only, however writing the top 8 bits of the register is OK as well, since the driver caches the entire 16-bit register value anyway. Finally, the driver is not used by any hardware in the kernel right now. The only hardware available to me is one with 16-bit bus, so I have no way to test the 8-bit bus mode, however it is unlikely this ever really worked anyway. If the 8-bit bus mode is ever required, it can be easily added by adjusting the 16-bit accessors to do 2 consecutive accesses, which is how this should have been done from the beginning. Signed-off-by:
-
Harigovindan P authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit a1028dcf ] Save pll state before dsi host is powered off. Without this change some register values gets resetted. Signed-off-by:
Harigovindan P <harigovi@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@chromium.org> Signed-off-by:
-
John Stultz authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit 7fd2dfc3 ] I was hitting kCFI crashes when building with clang, and after some digging finally narrowed it down to the dsi_mgr_connector_mode_valid() function being implemented as returning an int, instead of an enum drm_mode_status. This patch fixes it, and appeases the opaque word of the kCFI gods (seriously, clang inlining everything makes the kCFI backtraces only really rough estimates of where things went wrong). Thanks as always to Sami for his help narrowing this down. Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: Sami Tolvanen <samitolvanen@google.com> Cc: Todd Kjos <tkjos@google.com> Cc: Alistair Delva <adelva@google.com> Cc: Amit Pundir <amit.pundir@linaro.org> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: freedreno@lists.freedesktop.org Cc: clang-built-linux@googlegroups.com Signed-off-by:
John Stultz <john.stultz@linaro.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Tested-by:
Amit Pundir <amit.pundir@linaro.org> Signed-off-by:
-
Sergey Organov authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit e4bfded5 ] Symptom: application opens /dev/ttyGS0 and starts sending (writing) to it while either USB cable is not connected, or nobody listens on the other side of the cable. If driver circular buffer overflows before connection is established, no data will be written to the USB layer until/unless /dev/ttyGS0 is closed and re-opened again by the application (the latter besides having no means of being notified about the event of establishing of the connection.) Fix: on open and/or connect, kick Tx to flush circular buffer data to USB layer. Signed-off-by:
Sergey Organov <sorganov@gmail.com> Reviewed-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by:
Felipe Balbi <balbi@kernel.org> Signed-off-by:
-
Lars-Peter Clausen authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit 43d56572 ] ffs_aio_cancel() can be called from both interrupt and thread context. Make sure that the current IRQ state is saved and restored by using spin_{un,}lock_irq{save,restore}(). Otherwise undefined behavior might occur. Acked-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by:
-
Daniel Golle authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit 87c5cbf7 ] On AR934x this UART is usually not initialized by the bootloader as it is only used as a secondary serial port while the primary UART is a newly introduced NS16550-compatible. In order to make use of the ar933x-uart on AR934x without RTS/CTS hardware flow control, one needs to set the UART_CS_{RX,TX}_READY_ORIDE bits as other than on AR933x where this UART is used as primary/console, the bootloader on AR934x typically doesn't set those bits. Setting them explicitely on AR933x should not do any harm, so just set them unconditionally. Tested-by:
Chuanhong Guo <gch981213@gmail.com> Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/20200207095335.GA179836@makrotopia.orgSigned-off-by:
-
Paul Moore authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit 75612528 ] This patch ensures that we always check the netlink payload length in audit_receive_msg() before we take any action on the payload itself. Cc: stable@vger.kernel.org Reported-by: syzbot+399c44bf1f43b8747403@syzkaller.appspotmail.com Reported-by: syzbot+e4b12d8d202701f08b6d@syzkaller.appspotmail.com Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Will Deacon authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit a3e32855 upstream. When operating on hugepages with DEBUG_VM enabled, the GUP code checks the compound head for each tail page prior to calling page_cache_add_speculative. This is broken, because on the fast-GUP path (where we don't hold any page table locks) we can be racing with a concurrent invocation of split_huge_page_to_list. split_huge_page_to_list deals with this race by using page_ref_freeze to freeze the page and force concurrent GUPs to fail whilst the component pages are modified. This modification includes clearing the compound_head field for the tail pages, so checking this prior to a successful call to page_cache_add_speculative can lead to false positives: In fact, page_cache_add_speculative *already* has this check once the page refcount has been successfully updated, so we can simply remove the broken calls to VM_BUG_ON_PAGE. Link: http://lkml.kernel.org/r/20170522133604.11392-2-punit.agrawal@arm.comSigned-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Punit Agrawal <punit.agrawal@arm.com> Acked-by:
Steve Capper <steve.capper@arm.com> Acked-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Srivatsa S. Bhat (VMware) <srivatsa@csail.mit.edu> Signed-off-by:
Ajay Kaher <akaher@vmware.com> Signed-off-by:
Vlastimil Babka <vbabka@suse.cz> Signed-off-by:
-
Linus Torvalds authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit f958d7b5 upsteam. We have a VM_BUG_ON() to check that the page reference count doesn't underflow (or get close to overflow) by checking the sign of the count. That's all fine, but we actually want to allow people to use a "get page ref unless it's already very high" helper function, and we want that one to use the sign of the page ref (without triggering this VM_BUG_ON). Change the VM_BUG_ON to only check for small underflows (or _very_ close to overflowing), and ignore overflows which have strayed into negative territory. Acked-by:
Matthew Wilcox <willy@infradead.org> Cc: Jann Horn <jannh@google.com> Cc: stable@kernel.org Signed-off-by:
-
yangerkun authored
BugLink: https://bugs.launchpad.net/bugs/1868628 After include 3b5a3997 ("slip: Fix memory leak in slip_open error path") and e58c1912 ("slip: Fix use-after-free Read in slip_open") with 4.4.y/4.9.y. We will trigger a bug since we can double free sl->dev in slip_open. Actually, we should backport cf124db5 ("net: Fix inconsistent teardown and release of private netdev state.") too since it has delete free_netdev from sl_free_netdev. Fix it by delete free_netdev from slip_open. Signed-off-by:
yangerkun <yangerkun@huawei.com> Signed-off-by:
-
Sean Christopherson authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit fcfbc617 upstream. When reading/writing using the guest/host cache, check for a bad hva before checking for a NULL memslot, which triggers the slow path for handing cross-page accesses. Because the memslot is nullified on error by __kvm_gfn_to_hva_cache_init(), if the bad hva is encountered after crossing into a new page, then the kvm_{read,write}_guest() slow path could potentially write/access the first chunk prior to detecting the bad hva. Arguably, performing a partial access is semantically correct from an architectural perspective, but that behavior is certainly not intended. In the original implementation, memslot was not explicitly nullified and therefore the partial access behavior varied based on whether the memslot itself was null, or if the hva was simply bad. The current behavior was introduced as a seemingly unintentional side effect in commit f1b9dd5e ("kvm: Disallow wraparound in kvm_gfn_to_hva_cache_init"), which justified the change with "since some callers don't check the return code from this function, it sit seems prudent to clear ghc->memslot in the event of an error". Regardless of intent, the partial access is dependent on _not_ checking the result of the cache initialization, which is arguably a bug in its own right, at best simply weird. Fixes: 8f964525 ("KVM: Allow cross page reads and writes from cached translations.") Cc: Jim Mattson <jmattson@google.com> Cc: Andrew Honig <ahonig@google.com> Signed-off-by:
Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Aleksa Sarai authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 2b98149c upstream. It's over-zealous to return hard errors under RCU-walk here, given that a REF-walk will be triggered for all other cases handling ".." under RCU. The original purpose of this check was to ensure that if a rename occurs such that a directory is moved outside of the bind-mount which the resolution started in, it would be detected and blocked to avoid being able to mess with paths outside of the bind-mount. However, triggering a new REF-walk is just as effective a solution. Cc: "Eric W. Biederman" <ebiederm@xmission.com> Fixes: 397d425d ("vfs: Test for and handle paths that are unreachable from their mnt_root") Suggested-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Aleksa Sarai <cyphar@cyphar.com> Signed-off-by:
-
Nikolay Aleksandrov authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 3a20773b upstream. Since nl_groups is a u32 we can't bind more groups via ->bind (netlink_bind) call, but netlink has supported more groups via setsockopt() for a long time and thus nlk->ngroups could be over 32. Recently I added support for per-vlan notifications and increased the groups to 33 for NETLINK_ROUTE which exposed an old bug in the netlink_bind() code causing out-of-bounds access on archs where unsigned long is 32 bits via test_bit() on a local variable. Fix this by capping the maximum groups in netlink_bind() to BITS_PER_TYPE(u32), effectively capping them at 32 which is the minimum of allocated groups and the maximum groups which can be bound via netlink_bind(). CC: Christophe Leroy <christophe.leroy@c-s.fr> CC: Richard Guy Briggs <rgb@redhat.com> Fixes: 4f520900 ("netlink: have netlink per-protocol bind function return an error code.") Reported-by:
Erhard F. <erhard_f@mailbox.org> Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Nathan Chancellor authored
BugLink: https://bugs.launchpad.net/bugs/1868628 When doing the 4.9 merge into certain Android trees, I noticed a warning from Android's deprecated GCC 4.9.4, which causes a build failure in those trees due to basically -Werror: fs/ecryptfs/keystore.c: In function 'ecryptfs_parse_packet_set': fs/ecryptfs/keystore.c:1357:2: warning: 'auth_tok_list_item' may be used uninitialized in this function [-Wmaybe-uninitialized] memset(auth_tok_list_item, 0, ^ fs/ecryptfs/keystore.c:1260:38: note: 'auth_tok_list_item' was declared here struct ecryptfs_auth_tok_list_item *auth_tok_list_item; ^ GCC 9.2.0 was not able to pick up this warning when I tested it. Turns out that Clang warns as well when -Wuninitialized is used, which is not the case in older stable trees at the moment (but shows value in potentially backporting the various warning fixes currently in upstream to get more coverage). fs/ecryptfs/keystore.c:1284:6: warning: variable 'auth_tok_list_item' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] if (data[(*packet_size)++] != ECRYPTFS_TAG_1_PACKET_TYPE) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ fs/ecryptfs/keystore.c:1360:4: note: uninitialized use occurs here auth_tok_list_item); ^~~~~~~~~~~~~~~~~~ fs/ecryptfs/keystore.c:1284:2: note: remove the 'if' if its condition is always false if (data[(*packet_size)++] != ECRYPTFS_TAG_1_PACKET_TYPE) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ fs/ecryptfs/keystore.c:1260:56: note: initialize the variable 'auth_tok_list_item' to silence this warning struct ecryptfs_auth_tok_list_item *auth_tok_list_item; ^ = NULL 1 warning generated. Somehow, commit fe2e082f ("ecryptfs: fix a memory leak bug in parse_tag_1_packet()") upstream was not applied in the correct if block in 4.4.215, 4.9.215, and 4.14.172, which will indeed lead to use of uninitialized memory. Fix it up by undoing the bad backport in those trees then reapplying the patch in the proper location. Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Wolfram Sang authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 9e661ced upstream. The printout for txabrt is way too talkative and is highly annoying with scanning programs like 'i2cdetect'. Reduce it to the minimum, the rest can be gained by I2C core debugging and datasheet information. Also, make it a debug printout, it won't help the regular user. Fixes: ba92222e ("i2c: jz4780: Add i2c bus controller driver for Ingenic JZ4780") Reported-by:
H. Nikolaus Schaller <hns@goldelico.com> Tested-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Christophe JAILLET authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit bef8e2df upstream. Pointer on the memory allocated by 'alloc_progmem()' is stored in 'v->load_addr'. So this is this memory that should be freed by 'release_progmem()'. 'release_progmem()' is only a call to 'kfree()'. With the current code, there is both a double free and a memory leak. Fix it by passing the correct pointer to 'release_progmem()'. Fixes: e01402b1 ("More AP / SP bits for the 34K, the Malta bits and things. Still wants") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Paul Burton <paulburton@kernel.org> Cc: ralf@linux-mips.org Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: kernel-janitors@vger.kernel.org Signed-off-by:
-
dan.carpenter@oracle.com authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 5c02c447 upstream. Syzbot reports that "hiddev" is used after it's free in hiddev_disconnect(). The hiddev_disconnect() function sets "hiddev->exist = 0;" so hiddev_release() can free it as soon as we drop the "existancelock" lock. This patch moves the mutex_unlock(&hiddev->existancelock) until after we have finished using it. Reported-by: syzbot+784ccb935f9900cc7c9e@syzkaller.appspotmail.com Fixes: 7f77897e ("HID: hiddev: fix potential use-after-free") Suggested-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Johan Korsnes authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 84a40626 upstream. We have a HID touch device that reports its opens and shorts test results in HID buffers of size 8184 bytes. The maximum size of the HID buffer is currently set to 4096 bytes, causing probe of this device to fail. With this patch we increase the maximum size of the HID buffer to 8192 bytes, making device probe and acquisition of said buffers succeed. Signed-off-by:
Johan Korsnes <jkorsnes@cisco.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Armando Visconti <armando.visconti@st.com> Cc: Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Johan Korsnes authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 5ebdffd2 upstream. In case a report is greater than HID_MAX_BUFFER_SIZE, it is truncated, but the report-number byte is not correctly handled. This results in a off-by-one in the following memset, causing a kernel Oops and ensuing system crash. Note: With commit 8ec321e9 ("HID: Fix slab-out-of-bounds read in hid_field_extract") I no longer hit the kernel Oops as we instead fail "controlled" at probe if there is a report too long in the HID report-descriptor. hid_report_raw_event() is an exported symbol, so presumabely we cannot always rely on this being the case. Fixes: 966922f2 ("HID: fix a crash in hid_report_raw_event() function.") Signed-off-by:
-
Paul Moore authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 2ad3e17e upstream. Commit 219ca394 ("audit: use union for audit_field values since they are mutually exclusive") combined a number of separate fields in the audit_field struct into a single union. Generally this worked just fine because they are generally mutually exclusive. Unfortunately in audit_data_to_entry() the overlap can be a problem when a specific error case is triggered that causes the error path code to attempt to cleanup an audit_field struct and the cleanup involves attempting to free a stored LSM string (the lsm_str field). Currently the code always has a non-NULL value in the audit_field.lsm_str field as the top of the for-loop transfers a value into audit_field.val (both .lsm_str and .val are part of the same union); if audit_data_to_entry() fails and the audit_field struct is specified to contain a LSM string, but the audit_field.lsm_str has not yet been properly set, the error handling code will attempt to free the bogus audit_field.lsm_str value that was set with audit_field.val at the top of the for-loop. This patch corrects this by ensuring that the audit_field.val is only set when needed (it is cleared when the audit_field struct is allocated with kcalloc()). It also corrects a few other issues to ensure that in case of error the proper error code is returned. Cc: stable@vger.kernel.org Fixes: 219ca394 ("audit: use union for audit_field values since they are mutually exclusive") Reported-by: syzbot+1f4d90ead370d72e450b@syzkaller.appspotmail.com Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 37b0b6b8 upstream. If sbi->s_flex_groups_allocated is zero and the first allocation fails then this code will crash. The problem is that "i--" will set "i" to -1 but when we compare "i >= sbi->s_flex_groups_allocated" then the -1 is type promoted to unsigned and becomes UINT_MAX. Since UINT_MAX is more than zero, the condition is true so we call kvfree(new_groups[-1]). The loop will carry on freeing invalid memory until it crashes. Fixes: 7c990728 ("ext4: fix potential race between s_flex_groups online resizing and access") Reviewed-by:
Suraj Jitindar Singh <surajjs@amazon.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Jason Baron authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit 8a9093c7 ] tc flower rules that are based on src or dst port blocking are sometimes ineffective due to uninitialized stack data. __skb_flow_dissect() extracts ports from the skb for tc flower to match against. However, the port dissection is not done when when the FLOW_DIS_IS_FRAGMENT bit is set in key_control->flags. All callers of __skb_flow_dissect(), zero-out the key_control field except for fl_classify() as used by the flower classifier. Thus, the FLOW_DIS_IS_FRAGMENT may be set on entry to __skb_flow_dissect(), since key_control is allocated on the stack and may not be initialized. Since key_basic and key_control are present for all flow keys, let's make sure they are initialized. Fixes: 62230715 ("flow_dissector: do not dissect l4 ports for fragments") Co-developed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
Jason Baron <jbaron@akamai.com> Signed-off-by:
-
Dmitry Osipenko authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit c3331d2f ] The PN544 driver checks the "enable" polarity during of driver's probe and it's doing that by turning ON and OFF NFC with different polarities until enabling succeeds. It takes some time for the hardware to power-down, and thus, to deassert the IRQ that is raised by turning ON the hardware. Since the delay after last power-down of the polarity-checking process is missed in the code, the interrupt may trigger immediately after installing the IRQ handler (right after the checking is done), which results in IRQ handler trying to touch the disabled HW and ends with marking NFC as 'DEAD' during of the driver's probe: pn544_hci_i2c 1-002a: NFC: nfc_en polarity : active high pn544_hci_i2c 1-002a: NFC: invalid len byte shdlc: llc_shdlc_recv_frame: NULL Frame -> link is dead This patch fixes the occasional NFC initialization failure on Nexus 7 device. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
-
Xin Long authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit 245709ec ] When T2 timer is to be stopped, the asoc should also be deleted, otherwise, there will be no chance to call sctp_association_free and the asoc could last in memory forever. However, in sctp_sf_shutdown_sent_abort(), after adding the cmd SCTP_CMD_TIMER_STOP for T2 timer, it may return error due to the format error from __sctp_sf_do_9_1_abort() and miss adding SCTP_CMD_ASSOC_FAILED where the asoc will be deleted. This patch is to fix it by moving the format error check out of __sctp_sf_do_9_1_abort(), and do it before adding the cmd SCTP_CMD_TIMER_STOP for T2 timer. Thanks Hangbin for reporting this issue by the fuzz testing. v1->v2: - improve the comment in the code as Marcelo's suggestion. Fixes: 96ca468b ("sctp: check invalid value of length parameter in error cause") Reported-by:
Hangbin Liu <liuhangbin@gmail.com> Acked-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Benjamin Poirier authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit e404b8c7 ] After commit 27596472 ("ipv6: fix ECMP route replacement") it is no longer possible to replace an ECMP-able route by a non ECMP-able route. For example, ip route add 2001:db8::1/128 via fe80::1 dev dummy0 ip route replace 2001:db8::1/128 dev dummy0 does not work as expected. Tweak the replacement logic so that point 3 in the log of the above commit becomes: 3. If the new route is not ECMP-able, and no matching non-ECMP-able route exists, replace matching ECMP-able route (if any) or add the new route. We can now summarize the entire replace semantics to: When doing a replace, prefer replacing a matching route of the same "ECMP-able-ness" as the replace argument. If there is no such candidate, fallback to the first route found. Fixes: 27596472 ("ipv6: fix ECMP route replacement") Signed-off-by:
Benjamin Poirier <bpoirier@cumulusnetworks.com> Reviewed-by:
Michal Kubecek <mkubecek@suse.cz> Signed-off-by:
-
Benjamin Poirier authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit afecdb37 ] When splitting an RTA_MULTIPATH request into multiple routes and adding the second and later components, we must not simply remove NLM_F_REPLACE but instead replace it by NLM_F_CREATE. Otherwise, it may look like the netlink message was malformed. For example, ip route add 2001:db8::1/128 dev dummy0 ip route change 2001:db8::1/128 nexthop via fe80::30:1 dev dummy0 \ nexthop via fe80::30:2 dev dummy0 results in the following warnings: [ 1035.057019] IPv6: RTM_NEWROUTE with no NLM_F_CREATE or NLM_F_REPLACE [ 1035.057517] IPv6: NLM_F_CREATE should be set when creating new route This patch makes the nlmsg sequence look equivalent for __ip6_ins_rt() to what it would get if the multipath route had been added in multiple netlink operations: ip route add 2001:db8::1/128 dev dummy0 ip route change 2001:db8::1/128 nexthop via fe80::30:1 dev dummy0 ip route append 2001:db8::1/128 nexthop via fe80::30:2 dev dummy0 Fixes: 27596472 ("ipv6: fix ECMP route replacement") Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Arun Parameswaran authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 6f08e98d upstream. The mii management register in iproc mdio block does not have a retention register so it is lost on suspend. Save and restore value of register while resuming from suspend. Fixes: bb1a6197 ("net: phy: Initialize mdio clock at probe function") Signed-off-by:
Arun Parameswaran <arun.parameswaran@broadcom.com> Signed-off-by:
Scott Branden <scott.branden@broadcom.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Jethro Beekman authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit 540e585a ] In 709772e6, RT_TABLE_COMPAT was added to allow legacy software to deal with routing table numbers >= 256, but the same change to FIB rule queries was overlooked. Signed-off-by:
Jethro Beekman <jethro@fortanix.com> Signed-off-by:
-
Petr Mladek authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit c3fee609 upstream. The commit 97f5f0cd ("Input: implement SysRq as a separate input handler") added pr_fmt() definition. It caused a duplicated message prefix in the sysrq header messages, for example: [ 177.053931] sysrq: SysRq : Show backtrace of all active CPUs [ 742.864776] sysrq: SysRq : HELP : loglevel(0-9) reboot(b) crash(c) Fixes: 97f5f0cd ("Input: implement SysRq as a separate input handler") Signed-off-by:
Petr Mladek <pmladek@suse.com> Reviewed-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Tommi Rantala <tommi.t.rantala@nokia.com> Signed-off-by:
-
Petr Mladek authored
BugLink: https://bugs.launchpad.net/bugs/1868628 commit 075e1a0c upstream. The sysrq header line is printed with an increased loglevel to provide users some positive feedback. The original loglevel is not restored when the sysrq operation is disabled. This bug was introduced in 2.6.12 (pre-git-history) by the commit ("Allow admin to enable only some of the Magic-Sysrq functions"). Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Cc: Tommi Rantala <tommi.t.rantala@nokia.com> Signed-off-by:
-
Sergey Matyukevich authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit ea750801 ] The nl80211_policy is missing for NL80211_ATTR_STATUS_CODE attribute. As a result, for strictly validated commands, it's assumed to not be supported. Signed-off-by:
Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> Link: https://lore.kernel.org/r/20200213131608.10541-2-sergey.matyukevich.os@quantenna.comSigned-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Frank Sorenson authored
BugLink: https://bugs.launchpad.net/bugs/1868628 [ Upstream commit f52aa79d ] A number of the debug statements output file or directory mode in hex. Change these to print using octal. Signed-off-by:
Frank Sorenson <sorenson@redhat.com> Signed-off-by:
-
