- 06 Jan, 2020 3 commits
-
-
Pavel Shilovsky authored
BugLink: https://bugs.launchpad.net/bugs/1856949 Currently when the client creates a cifsFileInfo structure for a newly opened file, it allocates a list of byte-range locks with a pointer to the new cfile and attaches this list to the inode's lock list. The latter happens before initializing all other fields, e.g. cfile->tlink. Thus a partially initialized cifsFileInfo structure becomes available to other threads that walk through the inode's lock list. One example of such a thread may be an oplock break worker thread that tries to push all cached byte-range locks. This causes NULL-pointer dereference in smb2_push_mandatory_locks() when accessing cfile->tlink: [598428.945633] BUG: kernel NULL pointer dereference, address: 0000000000000038 ... [598428.945749] Workqueue: cifsoplockd cifs_oplock_break [cifs] [598428.945793] RIP: 0010:smb2_push_mandatory_locks+0xd6/0x5a0 [cifs] ... [598428.945834] Call Trace: [598428.945870] ? cifs_revalidate_mapping+0x45/0x90 [cifs] [598428.945901] cifs_oplock_break+0x13d/0x450 [cifs] [598428.945909] process_one_work+0x1db/0x380 [598428.945914] worker_thread+0x4d/0x400 [598428.945921] kthread+0x104/0x140 [598428.945925] ? process_one_work+0x380/0x380 [598428.945931] ? kthread_park+0x80/0x80 [598428.945937] ret_from_fork+0x35/0x40 Fix this by reordering initialization steps of the cifsFileInfo structure: initialize all the fields first and then add the new byte-range lock list to the inode's lock list. Cc: Stable <stable@vger.kernel.org> Signed-off-by:
Pavel Shilovsky <pshilov@microsoft.com> Reviewed-by:
Aurelien Aptel <aaptel@suse.com> Signed-off-by:
Steve French <stfrench@microsoft.com> (cherry picked from commit 6f582b27) Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Acked-by:
Connor Kuehl <connor.kuehl@canonical.com> Acked-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Paolo Bonzini authored
CVE-2019-19332 The bounds check was present in KVM_GET_SUPPORTED_CPUID but not KVM_GET_EMULATED_CPUID. Reported-by: syzbot+e3f4897236c4eeb8af4f@syzkaller.appspotmail.com Fixes: 84cffe49 ("kvm: Emulate MOVBE", 2013-10-29) Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> (backported from commit 433f4ba1) [ Connor Kuehl: offset adjustments ] Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Signed-off-by:
-
Navid Emamdoost authored
CVE-2019-19062 In crypto_report, a new skb is created via nlmsg_new(). This skb should be released if crypto_report_alg() fails. Fixes: a38f7907 ("crypto: Add userspace configuration API") Cc: <stable@vger.kernel.org> Signed-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> (backported from commit ffdde593) [PHLin: crypto_user.c not renamed yet, backported with the same logic] Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
- 18 Dec, 2019 1 commit
-
-
Seth Forshee authored
BugLink: https://bugs.launchpad.net/bugs/1820063 The hv_kvp_daemon service requires the hv_kvp device and should be started when the device appears and stopped in it disappears. Solution is based off the one provided at https://bugzilla.redhat.com/show_bug.cgi?id=1195029#c22. Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
- 10 Dec, 2019 36 commits
-
-
Po-Hsu Lin authored
BugLink: https://bugs.launchpad.net/bugs/1825778 The run_afpackettests will be marked as passed regardless the return value of those sub-tests in the script: -------------------- running psock_tpacket test -------------------- [FAIL] selftests: run_afpackettests [PASS] Fix this by changing the return value for each tests. Signed-off-by:
David S. Miller <davem@davemloft.net> (backported from commit 8c03557c) [PHLin: backported with the same logic] Signed-off-by:
-
Connor Kuehl authored
BugLink: https://bugs.launchpad.net/bugs/1855313 Ignore: yes Signed-off-by:
-
Connor Kuehl authored
BugLink: https://bugs.launchpad.net/bugs/1855313Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1855313Signed-off-by:
-
Hans de Goede authored
BugLink: https://bugs.launchpad.net/bugs/1855313 commit 16245db1 upstream. The HP WMI calls may take up to 128 bytes of data as input, and the AML methods implementing the WMI calls, declare a couple of fields for accessing input in different sizes, specifycally the HWMC method contains: CreateField (Arg1, 0x80, 0x0400, D128) Even though we do not use any of the WMI command-types which need a buffer of this size, the APCI interpreter still tries to create it as it is declared in generoc code at the top of the HWMC method which runs before the code looks at which command-type is requested. This results in many of these errors on many different HP laptop models: [ 14.459261] ACPI Error: Field [D128] at 1152 exceeds Buffer [NULL] size 160 (bits) (20170303/dsopcode-236) [ 14.459268] ACPI Error: Method parse/execution failed [\HWMC] (Node ffff8edcc61507f8), AE_AML_BUFFER_LIMIT (20170303/psparse-543) [ 14.459279] ACPI Error: Method parse/execution failed [\_SB.WMID.WMAA] (Node ffff8edcc61523c0), AE_AML_BUFFER_LIMIT (20170303/psparse-543) This commit increases the size of the data element of the bios_args struct to 128 bytes fixing these errors. Cc: stable@vger.kernel.org BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197007 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201981 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Lionel Debieve authored
BugLink: https://bugs.launchpad.net/bugs/1855313 commit af0d4442 upstream. No remove function implemented yet in the driver. Without remove function, the pm_runtime implementation complains when removing and probing again the driver. Signed-off-by:
Lionel Debieve <lionel.debieve@st.com> Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Candle Sun authored
BugLink: https://bugs.launchpad.net/bugs/1855313 commit 1cb0d2ae upstream. Upstream commit 58e75155 ("HID: core: move Usage Page concatenation to Main item") adds support for Usage Page item after Usage ID items (such as keyboards manufactured by Primax). Usage Page concatenation in Main item works well for following report descriptor patterns: USAGE_PAGE (Keyboard) 05 07 USAGE_MINIMUM (Keyboard LeftControl) 19 E0 USAGE_MAXIMUM (Keyboard Right GUI) 29 E7 LOGICAL_MINIMUM (0) 15 00 LOGICAL_MAXIMUM (1) 25 01 REPORT_SIZE (1) 75 01 REPORT_COUNT (8) 95 08 INPUT (Data,Var,Abs) 81 02 ------------- USAGE_MINIMUM (Keyboard LeftControl) 19 E0 USAGE_MAXIMUM (Keyboard Right GUI) 29 E7 LOGICAL_MINIMUM (0) 15 00 LOGICAL_MAXIMUM (1) 25 01 REPORT_SIZE (1) 75 01 REPORT_COUNT (8) 95 08 USAGE_PAGE (Keyboard) 05 07 INPUT (Data,Var,Abs) 81 02 But it makes the parser act wrong for the following report descriptor pattern(such as some Gamepads): USAGE_PAGE (Button) 05 09 USAGE (Button 1) 09 01 USAGE (Button 2) 09 02 USAGE (Button 4) 09 04 USAGE (Button 5) 09 05 USAGE (Button 7) 09 07 USAGE (Button 8) 09 08 USAGE (Button 14) 09 0E USAGE (Button 15) 09 0F USAGE (Button 13) 09 0D USAGE_PAGE (Consumer Devices) 05 0C USAGE (Back) 0a 24 02 USAGE (HomePage) 0a 23 02 LOGICAL_MINIMUM (0) 15 00 LOGICAL_MAXIMUM (1) 25 01 REPORT_SIZE (1) 75 01 REPORT_COUNT (11) 95 0B INPUT (Data,Var,Abs) 81 02 With Usage Page concatenation in Main item, parser recognizes all the 11 Usages as consumer keys, it is not the HID device's real intention. This patch checks whether Usage Page is really defined after Usage ID items by comparing usage page using status. Usage Page concatenation on currently defined Usage Page will always do in local parsing when Usage ID items encountered. When Main item is parsing, concatenation will do again with last defined Usage Page if this page has not been used in the previous usages concatenation. Signed-off-by:
Candle Sun <candle.sun@unisoc.com> Signed-off-by:
Nianfu Bai <nianfu.bai@unisoc.com> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Cc: Siarhei Vishniakou <svv@google.com> Signed-off-by:
-
Dust Li authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit 14e54ab9 ] When a classful qdisc's child qdisc has set the flag TCQ_F_CPUSTATS (pfifo_fast for example), the child qdisc's cpu_bstats should be passed to gnet_stats_copy_basic(), but many classful qdisc didn't do that. As a result, `tc -s class show dev DEV` always return 0 for bytes and packets in this case. Pass the child qdisc's cpu_bstats to gnet_stats_copy_basic() to fix this issue. The qstats also has this problem, but it has been fixed in 5dd431b6 ("net: sched: introduce and use qstats read...") and bstats still remains buggy. Fixes: 22e0f8b9 ("net: sched: make bstats per cpu and estimator RCU safe") Signed-off-by:
Dust Li <dust.li@linux.alibaba.com> Signed-off-by:
Tony Lu <tonylu@linux.alibaba.com> Acked-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
John Rutherford authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit fd567ac2 ] In commit 4f07b80c ("tipc: check msg->req data len in tipc_nl_compat_bearer_disable") the same patch code was copied into routines: tipc_nl_compat_bearer_disable(), tipc_nl_compat_link_stat_dump() and tipc_nl_compat_link_reset_stats(). The two link routine occurrences should have been modified to check the maximum link name length and not bearer name length. Fixes: 4f07b80c ("tipc: check msg->reg data len in tipc_nl_compat_bearer_disable") Signed-off-by:
John Rutherford <john.rutherford@dektech.com.au> Acked-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
Paolo Abeni authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit 8a574f86 ] If we can't build the flow del notification, we can simply delete the flow, no need to crash the kernel. Still keep a WARN_ON to preserve debuggability. Note: the BUG_ON() predates the Fixes tag, but this change can be applied only after the mentioned commit. v1 -> v2: - do not leak an skb on error Fixes: aed06778 ("openvswitch: Minimize ovs_flow_cmd_del critical section.") Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Paolo Abeni authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit 8ffeb03f ] All the callers of ovs_flow_cmd_build_info() already deal with error return code correctly, so we can handle the error condition in a more gracefull way. Still dump a warning to preserve debuggability. v1 -> v2: - clarify the commit message - clean the skb and report the error (DaveM) Fixes: ccb1352e ("net: Add Open vSwitch kernel components.") Signed-off-by:
-
Jouni Hogander authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit e58c1912 ] 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: 3b5a3997 ("slip: Fix memory leak in slip_open error path") Reported-by: syzbot+4d5170758f3762109542@syzkaller.appspotmail.com Cc: David Miller <davem@davemloft.net> Cc: Oliver Hartkopp <socketcan@hartkopp.net> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by:
Jouni Hogander <jouni.hogander@unikie.com> Signed-off-by:
-
Paolo Abeni authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit 4e81c0b3 ] When user-space sets the OVS_UFID_F_OMIT_* flags, and the relevant flow has no UFID, we can exceed the computed size, as ovs_nla_put_identifier() will always dump an OVS_FLOW_ATTR_KEY attribute. Take the above in account when computing the flow command message size. Fixes: 74ed7ab9 ("openvswitch: Add support for unique flow IDs.") Reported-by:
Qi Jun Ding <qding@redhat.com> Signed-off-by:
-
Menglong Dong authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit 1d7ea556 ] While enqueueing a broadcast skb to port->bc_queue, schedule_work() is called to add port->bc_work, which processes the skbs in bc_queue, to "events" work queue. If port->bc_queue is full, the skb will be discarded and schedule_work(&port->bc_work) won't be called. However, if port->bc_queue is full and port->bc_work is not running or pending, port->bc_queue will keep full and schedule_work() won't be called any more, and all broadcast skbs to macvlan will be discarded. This case can happen: macvlan_process_broadcast() is the pending function of port->bc_work, it moves all the skbs in port->bc_queue to the queue "list", and processes the skbs in "list". During this, new skbs will keep being added to port->bc_queue in macvlan_broadcast_enqueue(), and port->bc_queue may already full when macvlan_process_broadcast() return. This may happen, especially when there are a lot of real-time threads and the process is preempted. Fix this by calling schedule_work(&port->bc_work) even if port->bc_work is full in macvlan_broadcast_enqueue(). Fixes: 412ca155 ("macvlan: Move broadcasts into a work queue") Signed-off-by:
Menglong Dong <dong.menglong@zte.com.cn> Signed-off-by:
-
Uwe Kleine-König authored
BugLink: https://bugs.launchpad.net/bugs/1855313 commit e926b12c upstream. After a PWM is disposed by its user the per chip data becomes invalid. Clear the data in common code instead of the device drivers to get consistent behaviour. Before this patch only three of nine drivers cleaned up here. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Luca Ceresoli authored
BugLink: https://bugs.launchpad.net/bugs/1855313 commit f413cbb3 upstream. Errors are negative numbers. Using %u shows them as very large positive numbers such as 4294967277 that don't make sense. Use the %d format instead, and get a much nicer -19. Signed-off-by:
Luca Ceresoli <luca@lucaceresoli.net> Fixes: b48e0bab ("net: macb: Migrate to devm clock interface") Fixes: 93b31f48 ("net/macb: unify clock management") Fixes: 421d9df0 ("net/macb: merge at91_ether driver into macb driver") Fixes: aead88bd ("net: ethernet: macb: Add support for rx_clk") Fixes: f5473d1d ("net: macb: Support clock management for tsu_clk") Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Eugen Hristev authored
BugLink: https://bugs.launchpad.net/bugs/1855313 commit a0816e50 upstream. Control DO_WHITE_BALANCE is a button, with read only and execute-on-write flags. Adding this control in the proper list in the fill function. After adding it here, we can see output of v4l2-ctl -L do_white_balance 0x0098090d (button) : flags=write-only, execute-on-write Signed-off-by:
Eugen Hristev <eugen.hristev@microchip.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Alexander Usyskin authored
BugLink: https://bugs.launchpad.net/bugs/1855313 commit 7a2b9e6e upstream. Add parent device name to the name of devices on bus to avoid device names collisions for same client UUID available from different MEI heads. Namely this prevents sysfs collision under /sys/bus/mei/device/ In the device part leave just UUID other parameters that are required for device matching are not required here and are just bloating the name. Cc: <stable@vger.kernel.org> Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Link: https://lore.kernel.org/r/20191105150514.14010-1-tomas.winkler@intel.comSigned-off-by:
-
Fabio D'Urso authored
BugLink: https://bugs.launchpad.net/bugs/1855313 commit c1a1f273 upstream. This device presents itself as a USB hub with three attached devices: - An ACM serial port connected to the GPS module (not affected by this commit) - An FTDI serial port connected to the GPS module (1546:0502) - Another FTDI serial port connected to the ODIN-W2 radio module (1546:0503) This commit registers U-Blox's VID and the PIDs of the second and third devices. Datasheet: https://www.u-blox.com/sites/default/files/C099-F9P-AppBoard-Mbed-OS3-FW_UserGuide_%28UBX-18063024%29.pdfSigned-off-by:
Fabio D'Urso <fabiodurso@hotmail.it> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Pan Bian authored
BugLink: https://bugs.launchpad.net/bugs/1855313 commit b7aa39a2 upstream. The variable skb is released via kfree_skb() when the return value of _rtl92e_tx is not zero. However, after that, skb is accessed again to read its length, which may result in a use after free bug. This patch fixes the bug by moving the release operation to where skb is never used later. Signed-off-by:
Pan Bian <bianpan2016@163.com> Reviewed-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1572965351-6745-1-git-send-email-bianpan2016@163.comSigned-off-by:
-
Boris Brezillon authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit bda2ab56 ] Commit 2b6f0090 ("mtd: Check add_mtd_device() ret code") contained a leftover of the debug session that led to this bug fix. Remove this pr_info(). Fixes: 2b6f0090 ("mtd: Check add_mtd_device() ret code") Signed-off-by:
Boris Brezillon <bbrezillon@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
-
John Garry authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit 01929a65 ] Currently the SMP PHY control execution result is checked, however the function result for the command is not. As such, we may be missing all potential errors, like SMP FUNCTION FAILED, INVALID REQUEST FRAME LENGTH, etc., meaning the PHY control request has failed. In some scenarios we need to ensure the function result is accepted, so add a check for this. Tested-by:
Jian Luo <luojian5@huawei.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
James Morse authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit 0ac234be ] The ghes code is careful to parse and round firmware's advertised memory requirements for CPER records, up to a maximum of 64K. However when ghes_estatus_pool_expand() does its work, it splits the requested size into PAGE_SIZE granules. This means if firmware generates 5K of CPER records, and correctly describes this in the table, __process_error() will silently fail as it is unable to allocate more than PAGE_SIZE. Switch the estatus pool to vmalloc() memory. On x86 vmalloc() memory may fault and be fixed up by vmalloc_fault(). To prevent this call vmalloc_sync_all() before an NMI handler could discover the memory. Signed-off-by:
James Morse <james.morse@arm.com> Reviewed-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
John Garry authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit cec9771d ] +----------+ +----------+ | | | | | |--- 3.0 G ---| |--- 6.0 G --- SAS disk | | | | | |--- 3.0 G ---| |--- 6.0 G --- SAS disk |initiator | | | | device |--- 3.0 G ---| Expander |--- 6.0 G --- SAS disk | | | | | |--- 3.0 G ---| |--- 6.0 G --- SATA disk -->failed to connect | | | | | | | |--- 6.0 G --- SATA disk -->failed to connect | | | | +----------+ +----------+ According to Serial Attached SCSI - 1.1 (SAS-1.1): If an expander PHY attached to a SATA PHY is using a physical link rate greater than the maximum connection rate supported by the pathway from an STP initiator port, a management application client should use the SMP PHY CONTROL function (see 10.4.3.10) to set the PROGRAMMED MAXIMUM PHYSICAL LINK RATE field of the expander PHY to the maximum connection rate supported by the pathway from that STP initiator port. Currently libsas does not support checking if this condition occurs, nor rectifying when it does. Such a condition is not at all common, however it has been seen on some pre-silicon environments where the initiator PHY only supports a 1.5 Gbit maximum linkrate, mated with 12G expander PHYs and 3/6G SATA phy. This patch adds support for checking and rectifying this condition during initial device discovery only. We do support checking min pathway connection rate during revalidation phase, when new devices can be detected in the topology. However we do not support in the case of the the user reprogramming PHY linkrates, such that min pathway condition is not met/maintained. A note on root port PHY rates: The libsas root port PHY rates calculation is broken. Libsas sets the rates (min, max, and current linkrate) of a root port to the same linkrate of the first PHY member of that same port. In doing so, it assumes that all other PHYs which subsequently join the port to have the same negotiated linkrate, when they could actually be different. In practice this doesn't happen, as initiator and expander PHYs are normally initialised with consistent min/max linkrates. This has not caused an issue so far, so leave alone for now. Tested-by:
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit f4d7b3e2 ] 1 << 31 is Undefined Behaviour according to the C standard. Use U type modifier to avoid theoretical overflow. Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit 5bf325a5 ] With many active TCP sockets, fat TCP sockets could fool __sk_mem_raise_allocated() thanks to an overflow. They would increase their share of the memory, instead of decreasing it. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Bert Kenward authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit c6528542 ] The bitmap of found partitions in efx_ef10_mtd_probe was not initialised, causing partitions to be suppressed based off whatever value was in the bitmap at the start. Fixes: 33664635 ("sfc: suppress duplicate nvmem partition types in efx_ef10_mtd_probe") Signed-off-by:
Bert Kenward <bkenward@solarflare.com> Signed-off-by:
-
Hoang Le authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit 7384b538 ] When we free skb at tipc_data_input, we return a 'false' boolean. Then, skb passed to subcalling tipc_link_input in tipc_link_rcv, <snip> 1303 int tipc_link_rcv: ... 1354 if (!tipc_data_input(l, skb, l->inputq)) 1355 rc |= tipc_link_input(l, skb, l->inputq); </snip> Fix it by simple changing to a 'true' boolean when skb is being free-ed. Then, tipc_link_rcv will bypassed to subcalling tipc_link_input as above condition. Acked-by:
Ying Xue <ying.xue@windriver.com> Acked-by:
Jon Maloy <maloy@donjonn.com> Signed-off-by:
Hoang Le <hoang.h.le@dektech.com.au> Signed-off-by:
-
Johannes Berg authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit 50c29366 ] Digging through the ioctls with Al because of the previous patches, we found that on 64-bit decnet's dn_dev_ioctl() is wrong, because struct ifreq::ifr_ifru is actually 24 bytes (not 16 as expected from struct sockaddr) due to the ifru_map and ifru_settings members. Clearly, decnet expects the ioctl to be called with a struct like struct ifreq_dn { char ifr_name[IFNAMSIZ]; struct sockaddr_dn ifr_addr; }; since it does struct ifreq *ifr = ...; struct sockaddr_dn *sdn = (struct sockaddr_dn *)&ifr->ifr_addr; This means that DN_IFREQ_SIZE is too big for what it wants on 64-bit, as it is sizeof(struct ifreq) - sizeof(struct sockaddr) + sizeof(struct sockaddr_dn) This assumes that sizeof(struct sockaddr) is the size of ifr_ifru but that isn't true. Fix this to use offsetof(struct ifreq, ifr_ifru). This indeed doesn't really matter much - the result is that we copy in/out 8 bytes more than we should on 64-bit platforms. In case the "struct ifreq_dn" lands just on the end of a page though it might lead to faults. As far as I can tell, it has been like this forever, so it seems very likely that nobody cares. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Edward Cree authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit 33664635 ] Use a bitmap to keep track of which partition types we've already seen; for duplicates, return -EEXIST from efx_ef10_mtd_probe_partition() and thus skip adding that partition. Duplicate partitions occur because of the A/B backup scheme used by newer sfc NICs. Prior to this patch they cause sysfs_warn_dup errors because they have the same name, causing us not to expose any MTDs at all. Signed-off-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
-
Konstantin Khlebnikov authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit 01b833ab ] This should be 1 for normal allocations, 0 disables leak reporting. Signed-off-by:
Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Reported-by:
-
Konstantin Khlebnikov authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit 85704cb8 ] This fixes false-positive kmemleak reports about leaked neighbour entries: unreferenced object 0xffff8885c6e4d0a8 (size 1024): comm "softirq", pid 0, jiffies 4294922664 (age 167640.804s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 20 2c f3 83 ff ff ff ff ........ ,...... 08 c0 ef 5f 84 88 ff ff 01 8c 7d 02 01 00 00 00 ..._......}..... backtrace: [<00000000748509fe>] ip6_finish_output2+0x887/0x1e40 [<0000000036d7a0d8>] ip6_output+0x1ba/0x600 [<0000000027ea7dba>] ip6_send_skb+0x92/0x2f0 [<00000000d6e2111d>] udp_v6_send_skb.isra.24+0x680/0x15e0 [<000000000668a8be>] udpv6_sendmsg+0x18c9/0x27a0 [<000000004bd5fa90>] sock_sendmsg+0xb3/0xf0 [<000000008227b29f>] ___sys_sendmsg+0x745/0x8f0 [<000000008698009d>] __sys_sendmsg+0xde/0x170 [<00000000889dacf1>] do_syscall_64+0x9b/0x400 [<0000000081cdb353>] entry_SYSCALL_64_after_hwframe+0x49/0xbe [<000000005767ed39>] 0xffffffffffffffff Signed-off-by:
-
Gustavo A. R. Silva authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit f87d8ad9 ] There is a memory leak in case genlmsg_put fails. Fix this by freeing *args* before return. Addresses-Coverity-ID: 1476406 ("Resource leak") Fixes: 46273cf7 ("tipc: fix a missing check of genlmsg_put") Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by:
-
Boris Brezillon authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit 2b6f0090 ] add_mtd_device() can fail. We should always check its return value and gracefully handle the failure case. Fix the call sites where this not done (in mtdpart.c) and add a __must_check attribute to the prototype to avoid this kind of mistakes. Signed-off-by:
-
Olof Johansson authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit 35004f2e ] Fixes build break on most ARM/ARM64 defconfigs: lib/genalloc.c: In function 'gen_pool_add_virt': lib/genalloc.c:190:10: error: implicit declaration of function 'vzalloc_node'; did you mean 'kzalloc_node'? lib/genalloc.c:190:8: warning: assignment to 'struct gen_pool_chunk *' from 'int' makes pointer from integer without a cast [-Wint-conversion] lib/genalloc.c: In function 'gen_pool_destroy': lib/genalloc.c:254:3: error: implicit declaration of function 'vfree'; did you mean 'kfree'? Fixes: 6862d2fc ('lib/genalloc.c: use vzalloc_node() to allocate the bitmap') Cc: Huang Shijie <sjhuang@iluvatar.ai> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Alexey Skidanov <alexey.skidanov@intel.com> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Huang Shijie authored
BugLink: https://bugs.launchpad.net/bugs/1855313 [ Upstream commit 6862d2fc ] Some devices may have big memory on chip, such as over 1G. In some cases, the nbytes maybe bigger then 4M which is the bounday of the memory buddy system (4K default). So use vzalloc_node() to allocate the bitmap. Also use vfree to free it. Link: http://lkml.kernel.org/r/20181225015701.6289-1-sjhuang@iluvatar.aiSigned-off-by:
Huang Shijie <sjhuang@iluvatar.ai> Reviewed-by:
Andrew Morton <akpm@linux-foundation.org> Cc: Alexey Skidanov <alexey.skidanov@intel.com> Signed-off-by:
-
