- 16 Mar, 2017 30 commits
-
-
Johan Hovold authored
commit 99e5cde5 upstream. Make sure to drop any device reference taken by vio_find_node() when adding and removing virtual I/O slots. Fixes: 5eeb8c63 ("[PATCH] PCI Hotplug: rpaphp: Move VIO registration") Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Johan Hovold authored
commit 815a7141 upstream. Make sure to drop any reference taken by bus_find_device() when creating devices during init and driver registration. Fixes: 55347cc9 ("[POWERPC] ibmebus: Add device creation and bus probing based on of_device") Signed-off-by:
-
Johan Hovold authored
commit fe0f3168 upstream. Make sure to drop any reference taken by bus_find_device() in the sysfs callbacks that are used to create and destroy devices based on device-tree entries. Fixes: 6bccf755 ("[POWERPC] ibmebus: dynamic addition/removal of adapters, some code cleanup") Signed-off-by:
-
Christopher Spinrath authored
commit 72649a46 upstream. According to the schematics of CompuLab's sbc-fx6 baseboard and the vendor devicetree GPIO_16 is *not* muxed to ENET_REF_CLK but to SPDIF_IN. Remove the wrong pinctrl setting. Fixes: 682d055e ("ARM: dts: Add initial support for cm-fx6.") Signed-off-by:
Christopher Spinrath <christopher.spinrath@rwth-aachen.de> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> [bwh: Backported to 3.16: adjust indentation] Signed-off-by:
-
Alex Porosanu authored
commit d128af17 upstream. The AEAD givenc descriptor relies on moving the IV through the output FIFO and then back to the CTX2 for authentication. The SEQ FIFO STORE could be scheduled before the data can be read from OFIFO, especially since the SEQ FIFO LOAD needs to wait for the SEQ FIFO LOAD SKIP to finish first. The SKIP takes more time when the input is SG than when it's a contiguous buffer. If the SEQ FIFO LOAD is not scheduled before the STORE, the DECO will hang waiting for data to be available in the OFIFO so it can be transferred to C2. In order to overcome this, first force transfer of IV to C2 by starting the "cryptlen" transfer first and then starting to store data from OFIFO to the output buffer. Fixes: 1acebad3 ("crypto: caam - faster aead implementation") Signed-off-by:
Alex Porosanu <alexandru.porosanu@nxp.com> Signed-off-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Linus Walleij authored
commit 295070e9 upstream. The regulator has never been properly enabled, it has been dormant all the time. It's strange that MMC was working at all, but it likely worked by the signals going through the levelshifter and reaching the card anyways. Fixes: 3615a34e ("regulator: add STw481x VMMC driver") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Alan Stern authored
commit ccdb6be9 upstream. The UHCI controllers in Intel chipsets rely on a platform-specific non-PME mechanism for wakeup signalling. They can generate wakeup signals even though they don't support PME. We need to let the USB core know this so that it will enable runtime suspend for UHCI controllers. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Alan Stern authored
commit 6496ebd7 upstream. One some systems, the firmware does not allow certain PCI devices to be put in deep D-states. This can cause problems for wakeup signalling, if the device does not support PME# in the deepest allowed suspend state. For example, Pierre reports that on his system, ACPI does not permit his xHCI host controller to go into D3 during runtime suspend -- but D3 is the only state in which the controller can generate PME# signals. As a result, the controller goes into runtime suspend but never wakes up, so it doesn't work properly. USB devices plugged into the controller are never detected. If the device relies on PME# for wakeup signals but is not capable of generating PME# in the target state, the PCI core should accurately report that it cannot do wakeup from runtime suspend. This patch modifies the pci_dev_run_wake() routine to add this check. Reported-by:
Pierre de Villemereuil <flyos@mailoo.org> Tested-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> CC: Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Kashyap Desai authored
commit 18e1c7f6 upstream. For SRIOV enabled firmware, if there is a OCR(online controller reset) possibility driver set the convert flag to 1, which is not happening if there are outstanding commands even after 180 seconds. As driver does not set convert flag to 1 and still making the OCR to run, VF(Virtual function) driver is directly writing on to the register instead of waiting for 30 seconds. Setting convert flag to 1 will cause VF driver will wait for 30 secs before going for reset. Signed-off-by:
Kiran Kumar Kasturi <kiran-kumar.kasturi@broadcom.com> Signed-off-by:
Sumit Saxena <sumit.saxena@broadcom.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Eric Sandeen authored
commit 4dfce57d upstream. There have been several reports over the years of NULL pointer dereferences in xfs_trans_log_inode during xfs_fsr processes, when the process is doing an fput and tearing down extents on the temporary inode, something like: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 PID: 29439 TASK: ffff880550584fa0 CPU: 6 COMMAND: "xfs_fsr" [exception RIP: xfs_trans_log_inode+0x10] #9 [ffff8800a57bbbe0] xfs_bunmapi at ffffffffa037398e [xfs] #10 [ffff8800a57bbce8] xfs_itruncate_extents at ffffffffa0391b29 [xfs] #11 [ffff8800a57bbd88] xfs_inactive_truncate at ffffffffa0391d0c [xfs] #12 [ffff8800a57bbdb8] xfs_inactive at ffffffffa0392508 [xfs] #13 [ffff8800a57bbdd8] xfs_fs_evict_inode at ffffffffa035907e [xfs] #14 [ffff8800a57bbe00] evict at ffffffff811e1b67 #15 [ffff8800a57bbe28] iput at ffffffff811e23a5 #16 [ffff8800a57bbe58] dentry_kill at ffffffff811dcfc8 #17 [ffff8800a57bbe88] dput at ffffffff811dd06c #18 [ffff8800a57bbea8] __fput at ffffffff811c823b #19 [ffff8800a57bbef0] ____fput at ffffffff811c846e #20 [ffff8800a57bbf00] task_work_run at ffffffff81093b27 #21 [ffff8800a57bbf30] do_notify_resume at ffffffff81013b0c #22 [ffff8800a57bbf50] int_signal at ffffffff8161405d As it turns out, this is because the i_itemp pointer, along with the d_ops pointer, has been overwritten with zeros when we tear down the extents during truncate. When the in-core inode fork on the temporary inode used by xfs_fsr was originally set up during the extent swap, we mistakenly looked at di_nextents to determine whether all extents fit inline, but this misses extents generated by speculative preallocation; we should be using if_bytes instead. This mistake corrupts the in-memory inode, and code in xfs_iext_remove_inline eventually gets bad inputs, causing it to memmove and memset incorrect ranges; this became apparent because the two values in ifp->if_u2.if_inline_ext[1] contained what should have been in d_ops and i_itemp; they were memmoved due to incorrect array indexing and then the original locations were zeroed with memset, again due to an array overrun. Fix this by properly using i_df.if_bytes to determine the number of extents, not di_nextents. Thanks to dchinner for looking at this with me and spotting the root cause. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Reviewed-by:
Brian Foster <bfoster@redhat.com> Signed-off-by:
Dave Chinner <david@fromorbit.com> [bwh: Backported to 3.16: adjust indentation] Signed-off-by:
-
Guenter Roeck authored
commit 328cf692 upstream. If CONFIG_ETRAX_AXISFLASHMAP is not configured, the flash rescue image object file is empty. With recent versions of binutils, this results in the following build error. cris-linux-objcopy: error: the input file 'arch/cris/boot/rescue/rescue.o' has no sections This is seen, for example, when trying to build cris:allnoconfig with recently generated toolchains. Since it does not make sense to build a flash rescue image if there is no flash, only build it if CONFIG_ETRAX_AXISFLASHMAP is enabled. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Fixes: 66ab3a74 ("CRIS: Merge machine dependent boot/compressed ..") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by:
-
Govindarajulu Varadarajan authored
commit 17197236 upstream. Driver sets the skb l4/l3 hash based on NIC_CFG_RSS_HASH_TYPE_*, which is bit mask. This is wrong. Hw actually provides us enum. Use CQ_ENET_RQ_DESC_RSS_TYPE_* to set l3 and l4 hash type. Fixes: bf751ba8 ("driver/net: enic: record q_number and rss_hash for skb") Signed-off-by:
Govindarajulu Varadarajan <_govind@gmx.com> Signed-off-by:
David S. Miller <davem@davemloft.net> [bwh: Backported to 3.16: drop the version bump] Signed-off-by:
-
Patrik Jakobsson authored
commit 0a97c81a upstream. Hook up drm_compat_ioctl to support 32-bit userspace on 64-bit kernels. It turns out that N2600 and N2800 comes with 64-bit enabled. We previously assumed there where no such systems out there. Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20161101144315.2955-1-patrik.r.jakobsson@gmail.comSigned-off-by:
-
Vladimir Zapolskiy authored
commit 1f87aee6 upstream. i.MX31 Clock Control Module controller is found on AIPS2 bus, move it there from SPBA bus to avoid a conflict of device IO space mismatch. Fixes: ef0e4a60 ("ARM: mx31: Replace clk_register_clkdev with clock DT lookup") Signed-off-by:
Vladimir Zapolskiy <vz@mleia.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Vladimir Zapolskiy authored
commit 2e575cbc upstream. The type of AVIC interrupt controller found on i.MX31 is one-cell, namely 31 for CCM DVFS and 53 for CCM, however for clock control module its interrupts are specified as 3-cells, fix it. Fixes: ef0e4a60 ("ARM: mx31: Replace clk_register_clkdev with clock DT lookup") Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Felipe Balbi authored
commit 6b9018d4 upstream. In case of High-Speed, High-Bandwidth endpoints, we need to tell DWC3 that we have more than one packet per interval. We do that by setting PCM1 field of Isochronous-First TRB. Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> [bwh: Backported to 3.16: adjust context] Signed-off-by:
-
Felipe Balbi authored
commit eaa496ff upstream. ep->mult is supposed to be set to Isochronous and Interrupt Endapoint's multiplier value. This value is computed from different places depending on the link speed. If we're dealing with HighSpeed, then it's part of bits [12:11] of wMaxPacketSize. This case wasn't taken into consideration before. While at that, also make sure the ep->mult defaults to one so drivers can use it unconditionally and assume they'll never multiply ep->maxpacket to zero. Signed-off-by:
-
Felipe Balbi authored
commit 541b6fe6 upstream. According to USB Specification 2.0 table 9-4, wMaxPacketSize is a bitfield. Endpoint's maxpacket is laid out in bits 10:0. For high-speed, high-bandwidth isochronous endpoints, bits 12:11 contain a multiplier to tell us how many transactions we want to try per uframe. This means that if we want an isochronous endpoint to issue 3 transfers of 1024 bytes per uframe, wMaxPacketSize should contain the value: 1024 | (2 << 11) or 5120 (0x1400). In order to make Host and Peripheral controller drivers' life easier, we're adding a helper which returns bits 12:11. Note that no care is made WRT to checking endpoint type and gadget's speed. That's left for drivers to handle. Signed-off-by:
-
Felipe Balbi authored
commit e8f29bb7 upstream. usb_endpoint_maxp() returns wMaxPacketSize in its raw form. Without taking into consideration that it also contains other bits reserved for isochronous endpoints. This patch fixes one occasion where this is a problem by making sure that we initialize ep->maxpacket only with lower 10 bits of the value returned by usb_endpoint_maxp(). Note that seperate patches will be necessary to audit all call sites of usb_endpoint_maxp() and make sure that usb_endpoint_maxp() only returns lower 10 bits of wMaxPacketSize. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
commit cf346d5b upstream. Both register_perl_scripting() and register_python_scripting() allocate this variable, fix it by checking if it already was. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Tom Zanussi <tzanussi@gmail.com> Cc: Wang Nan <wangnan0@huawei.com> Fixes: 7e4b21b8 ("perf/scripts: Add Python scripting engine") Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Nicolas Iooss authored
commit 7ec03e60 upstream. Function ite_set_carrier_params() uses variable use_demodulator after having initialized it to false in some if branches, but this variable is never set to true otherwise. This bug has been found using clang -Wsometimes-uninitialized warning flag. Fixes: 620a32bb ("[media] rc: New rc-based ite-cir driver for several ITE CIRs") Signed-off-by:
Nicolas Iooss <nicolas.iooss_linux@m4x.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
commit ecf1e225 upstream. Instead of the one when another syscall takes place while another is being processed (in another CPU, but we show it serialized, so need to "interrupt" the other), and also when finally showing the sys_enter + sys_exit + duration, where we were showing the sample->time for the sys_exit, duh. Before: # perf trace sleep 1 <SNIP> 0.373 ( 0.001 ms): close(fd: 3 ) = 0 1000.626 (1000.211 ms): nanosleep(rqtp: 0x7ffd6ddddfb0) = 0 1000.653 ( 0.003 ms): close(fd: 1 ) = 0 1000.657 ( 0.002 ms): close(fd: 2 ) = 0 1000.667 ( 0.000 ms): exit_group( ) # After: # perf trace sleep 1 <SNIP> 0.336 ( 0.001 ms): close(fd: 3 ) = 0 0.373 (1000.086 ms): nanosleep(rqtp: 0x7ffe303e9550) = 0 1000.481 ( 0.002 ms): close(fd: 1 ) = 0 1000.485 ( 0.001 ms): close(fd: 2 ) = 0 1000.494 ( 0.000 ms): exit_group( ) [root@jouet linux]# Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-ecbzgmu2ni6glc6zkw8p1zmx@git.kernel.org Fixes: 752fde44 ("perf trace: Support interrupted syscalls") Signed-off-by:
-
Shmulik Ladkani authored
commit d65f2fa6 upstream. META_COLLECTOR int_vlan_tag() assumes that if the accel tag (vlan_tci) is zero, then no vlan accel tag is present. This is incorrect for zero VID vlan accel packets, making the following match fail: tc filter add ... basic match 'meta(vlan mask 0xfff eq 0)' ... Apparently 'int_vlan_tag' was implemented prior VLAN_TAG_PRESENT was introduced in 05423b24 "vlan: allow null VLAN ID to be used" (and at time introduced, the 'vlan_tx_tag_get' call in em_meta was not adapted). Fix, testing skb_vlan_tag_present instead of testing skb_vlan_tag_get's value. Fixes: 05423b24 ("vlan: allow null VLAN ID to be used") Fixes: 1a31f204 ("netsched: Allow meta match on vlan tag on receive") Signed-off-by:
Shmulik Ladkani <shmulik.ladkani@gmail.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
-
Ard Biesheuvel authored
commit caf4b9e2 upstream. Emit the XTS tweak literal constants in the appropriate order for a single 128-bit scalar literal load. Fixes: 49788fe2 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions") Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
Ard Biesheuvel authored
commit a2c435cc upstream. The AES implementation using pure NEON instructions relies on the generic AES key schedule generation routines, which store the round keys as arrays of 32-bit quantities stored in memory using native endianness. This means we should refer to these round keys using 4x4 loads rather than 16x1 loads. In addition, the ShiftRows tables are loading using a single scalar load, which is also affected by endianness, so emit these tables in the correct order depending on whether we are building for big endian or not. Fixes: 49788fe2 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions") Signed-off-by:
-
Ard Biesheuvel authored
commit 56e4e76c upstream. The AES-CCM implementation that uses ARMv8 Crypto Extensions instructions refers to the AES round keys as pairs of 64-bit quantities, which causes failures when building the code for big endian. In addition, it byte swaps the input counter unconditionally, while this is only required for little endian builds. So fix both issues. Fixes: 12ac3efe ("arm64/crypto: use crypto instructions to generate AES key schedule") Signed-off-by:
-
Ard Biesheuvel authored
commit 174122c3 upstream. The SHA256 digest is an array of 8 32-bit quantities, so we should refer to them as such in order for this code to work correctly when built for big endian. So replace 16 byte scalar loads and stores with 4x32 vector ones where appropriate. Fixes: 6ba6c74d ("arm64/crypto: SHA-224/SHA-256 using ARMv8 Crypto Extensions") Signed-off-by:
-
Ard Biesheuvel authored
commit ee71e5f1 upstream. The SHA1 digest is an array of 5 32-bit quantities, so we should refer to them as such in order for this code to work correctly when built for big endian. So replace 16 byte scalar loads and stores with 4x4 vector ones where appropriate. Fixes: 2c98833a ("arm64/crypto: SHA-1 using ARMv8 Crypto Extensions") Signed-off-by:
-
Ard Biesheuvel authored
commit 9c433ad5 upstream. The GHASH key and digest are both pairs of 64-bit quantities, but the GHASH code does not always refer to them as such, causing failures when built for big endian. So replace the 16x1 loads and stores with 2x8 ones. Fixes: b913a640 ("arm64/crypto: improve performance of GHASH algorithm") Signed-off-by:
-
Eva Rachel Retuya authored
commit b321a38d upstream. The oversampling ratio is controlled using the oversampling pins, OS [2:0] with OS2 being the MSB control bit, and OS0 the LSB control bit. The gpio connected to the OS2 pin is not being set correctly, only OS0 and OS1 pins are being set. Fix the typo to allow proper control of the oversampling pins. Signed-off-by:
Eva Rachel Retuya <eraretuya@gmail.com> Fixes: b9618c0c ("staging: IIO: ADC: New driver for AD7606/AD7606-6/AD7606-4") Acked-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
- 26 Feb, 2017 10 commits
-
-
Ben Hutchings authored
-
Eric Dumazet authored
commit ccf7abb9 upstream. Splicing from TCP socket is vulnerable when a packet with URG flag is received and stored into receive queue. __tcp_splice_read() returns 0, and sk_wait_data() immediately returns since there is the problematic skb in queue. This is a nice way to burn cpu (aka infinite loop) and trigger soft lockups. Again, this gem was found by syzkaller tool. Fixes: 9c55e01c ("[TCP]: Splice receive support.") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Dmitry Vyukov <dvyukov@google.com> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by:
-
Andrey Konovalov authored
commit 5edabca9 upstream. In the current DCCP implementation an skb for a DCCP_PKT_REQUEST packet is forcibly freed via __kfree_skb in dccp_rcv_state_process if dccp_v6_conn_request successfully returns. However, if IPV6_RECVPKTINFO is set on a socket, the address of the skb is saved to ireq->pktopts and the ref count for skb is incremented in dccp_v6_conn_request, so skb is still in use. Nevertheless, it gets freed in dccp_rcv_state_process. Fix by calling consume_skb instead of doing goto discard and therefore calling __kfree_skb. Similar fixes for TCP: fb7e2399 [TCP]: skb is unexpectedly freed. 0aea76d3 tcp: SYN packets are now simply consumed Signed-off-by:
Andrey Konovalov <andreyknvl@google.com> Acked-by:
-
Eric Dumazet authored
commit 34b2cef2 upstream. Andrey Konovalov got crashes in __ip_options_echo() when a NULL skb->dst is accessed. ipv4_pktinfo_prepare() should not drop the dst if (evil) IP options are present. We could refine the test to the presence of ts_needtime or srr, but IP options are not often used, so let's be conservative. Thanks to syzkaller team for finding this bug. Fixes: d826eb14 ("ipv4: PKTINFO doesnt need dst reference") Signed-off-by:
-
Eric Dumazet authored
commit 7892032c upstream. Andrey Konovalov reported out of bound accesses in ip6gre_err() If GRE flags contains GRE_KEY, the following expression *(((__be32 *)p) + (grehlen / 4) - 1) accesses data ~40 bytes after the expected point, since grehlen includes the size of IPv6 headers. Let's use a "struct gre_base_hdr *greh" pointer to make this code more readable. p[1] becomes greh->protocol. grhlen is the GRE header length. Fixes: c12b395a ("gre: Support GRE over IPv6") Signed-off-by:
-
Gu Zheng authored
commit 497de07d upstream. This change was missed the tmpfs modification in In CVE-2016-7097 commit 07393101 ("posix_acl: Clear SGID bit when setting file permissions") It can test by xfstest generic/375, which failed to clear setgid bit in the following test case on tmpfs: touch $testfile chown 100:100 $testfile chmod 2755 $testfile _runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile Signed-off-by:
Gu Zheng <guzheng1@huawei.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Johan Hovold authored
commit 146cc8a1 upstream. The current implementation failed to detect short transfers when attempting to read the line state, and also, to make things worse, logged the content of the uninitialised heap transfer buffer. Fixes: abf492e7 ("USB: kl5kusb105: fix DMA buffers on stack") Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reviewed-by:
-
Stephen Smalley authored
commit 0c461cb7 upstream. SELinux tries to support setting/clearing of /proc/pid/attr attributes from the shell by ignoring terminating newlines and treating an attribute value that begins with a NUL or newline as an attempt to clear the attribute. However, the test for clearing attributes has always been wrong; it has an off-by-one error, and this could further lead to reading past the end of the allocated buffer since commit bb646cdb ("proc_pid_attr_write(): switch to memdup_user()"). Fix the off-by-one error. Even with this fix, setting and clearing /proc/pid/attr attributes from the shell is not straightforward since the interface does not support multiple write() calls (so shells that write the value and newline separately will set and then immediately clear the attribute, requiring use of echo -n to set the attribute), whereas trying to use echo -n "" to clear the attribute causes the shell to skip the write() call altogether since POSIX says that a zero-length write causes no side effects. Thus, one must use echo -n to set and echo without -n to clear, as in the following example: $ echo -n unconfined_u:object_r:user_home_t:s0 > /proc/$$/attr/fscreate $ cat /proc/$$/attr/fscreate unconfined_u:object_r:user_home_t:s0 $ echo "" > /proc/$$/attr/fscreate $ cat /proc/$$/attr/fscreate Note the use of /proc/$$ rather than /proc/self, as otherwise the cat command will read its own attribute value, not that of the shell. There are no users of this facility to my knowledge; possibly we should just get rid of it. UPDATE: Upon further investigation it appears that a local process with the process:setfscreate permission can cause a kernel panic as a result of this bug. This patch fixes CVE-2017-2618. Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov> [PM: added the update about CVE-2017-2618 to the commit description] Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
James Morris <james.l.morris@oracle.com> Signed-off-by:
-
Steve Rutherford authored
commit 129a72a0 upstream. Introduces segemented_write_std. Switches from emulated reads/writes to standard read/writes in fxsave, fxrstor, sgdt, and sidt. This fixes CVE-2017-2584, a longstanding kernel memory leak. Since commit 283c95d0 ("KVM: x86: emulate FXSAVE and FXRSTOR", 2016-11-09), which is luckily not yet in any final release, this would also be an exploitable kernel memory *write*! Reported-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Steve Rutherford <srutherford@google.com> Signed-off-by:
-
Paolo Bonzini authored
commit 33ab9110 upstream. This is CVE-2017-2583. On Intel this causes a failed vmentry because SS's type is neither 3 nor 7 (even though the manual says this check is only done for usable SS, and the dmesg splat says that SS is unusable!). On AMD it's worse: svm.c is confused and sets CPL to 0 in the vmcb. The fix fabricates a data segment descriptor when SS is set to a null selector, so that CPL and SS.DPL are set correctly in the VMCS/vmcb. Furthermore, only allow setting SS to a NULL selector if SS.RPL < 3; this in turn ensures CPL < 3 because RPL must be equal to CPL. Thanks to Andy Lutomirski and Willy Tarreau for help in analyzing the bug and deciphering the manuals. Reported-by:
Xiaohan Zhang <zhangxiaohan1@huawei.com> Fixes: 79d5b4c3 Cc: stable@nongnu.org Signed-off-by:
-
