Skip to main content

Browse the archive

https://github.com/torvalds/linux
05 April 2024, 19:05:47 UTC
sort by:
Revision Author Date Message Commit Date
d47d367 Siarhei Siamashka 20 February 2015, 05:29:59 UTC arm: Use top 4 bits of machine id for u-boot compatibility check This implements ensuring compatibility between the mainline u-boot and the legacy sunxi-3.4 kernels, proposed earlier at http://lists.denx.de/pipermail/u-boot/2014-October/191777.html Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> 15 March 2015, 19:30:43 UTC
dea62f2 Hans de Goede 21 February 2015, 15:47:24 UTC sun5i: clock: Do not change PLL6 frequency Keep the PLL6 frequency as it is set by the bootloader, it may be used as parent for the mbus, and if we change it we may be changing the mbus frequency, all peripherals (*) using pll6 are already capable of dealing with it running at a different frequency. *) Only mmc uses pll6 as a parent by default Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> 15 March 2015, 19:29:53 UTC
16b25a9 Hans de Goede 21 February 2015, 15:47:23 UTC sunxi: axp152: Keep VDD-INT/VDD-DLL at bootloader set value Some fex files contain wrong values, causing stability issues. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> 15 March 2015, 19:29:29 UTC
ade08aa Hans de Goede 15 October 2014, 10:10:45 UTC sunxi: nand: Fix nand clk calculation Before the u-boot dram cleanup u-boot would always set PLL5 factor m to 2 (reg value 1) and div p to 1, and get_cmu_clk in the nand code would calculate the pll5p clk like this: clk = 24 * factor_n * factor_k / div_p / factor_m; aka: clk = 24 * factor_n * factor_k / (div_p * factor_m); This is wrong however, factor_m is not used to calculate pll5p, and div_p is not a straight divider, but it divides by 2 ^ div_p. Since with the m == 2 and p == 1 settings used before the dram cleanup, this happend to do the right thing in the form of dividing by 2. But with the new dram code div_p is 0, and then the old get_cmu_clk code fails with a divide by 0 error. This commit fixes this, by changing the clk calculation to the correct form of: clk = (24 * factor_n * factor_k) >> div_p; Signed-off-by: Hans de Goede <hdegoede@redhat.com> 24 November 2014, 00:17:24 UTC
c4c4664 Hans de Goede 15 October 2014, 10:10:44 UTC sunxi: axp152: Keep DRAM / Vddr at bootloader set value Some fex files contain wrong values, causing stability issues. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> 24 November 2014, 00:17:11 UTC
c9ec08b Andreas Baierl 10 November 2014, 08:06:35 UTC arm:sunxi:defconfig: Enable CONFIG_FHANDLE required for systemd >= 209 Signed-off-by: Andreas Baierl<ichgeh@imkreisrum.de> Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> 23 November 2014, 23:20:03 UTC
1bffd2c Andreas Baierl 10 November 2014, 08:06:31 UTC arm:sunxi:defconfig: Re-Enable symmetric multiprocessing for sun7i Signed-off-by: Andreas Baierl<ichgeh@imkreisrum.de> Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> 23 November 2014, 22:51:05 UTC
50ca729 Andreas Baierl 13 October 2014, 10:31:38 UTC Cleanup sun7i_defconfig based on sun4i_defconfig. 23 October 2014, 22:08:20 UTC
cc0e490 Andreas Baierl 13 October 2014, 10:31:37 UTC Sunxi SATA driver should be built in-kernel in order to allow root filesystems on sata per default. 23 October 2014, 22:08:14 UTC
2e1c5c5 Tim Tisdall 23 October 2014, 15:01:20 UTC remove sunxi_nand from sun7i_defconfig There's a known issue with sunxi_nand on A20 devices where it will try to read a NAND chip and then make modifications such that it becomes corrupted. Until this situation is resolved, the module should _not_ be included in the defconfig for A20 devices. Signed-off-by: Tim Tisdall <tisdall@gmail.com> Acked-by: Luc Verhaegen <libv@skynet.be> 23 October 2014, 21:32:15 UTC
d5b9172 Eddy Beaupre 04 June 2014, 14:36:41 UTC SUNXI-GMAC driver logs every vlan frame... Hello! Don't know if i'm the only one who's using vlan with sunxi-gmac, but the current driver is terribly spammy for the logs, it log every single vlan frame at the INFO level. Personally i don't think that information is useful at all but if you want to keep it enable, it should log it at the DEBUG level instead. So i propose this little simple modification to the source (or better, remove the whole line.): 22 October 2014, 22:45:21 UTC
fde9bcc Alejandro Mery 22 October 2014, 21:54:26 UTC Revert "driver-core: cpu: export total_cpus to fix CPU_FREQ_STAT=m build" This reverts commit 83af5517076a13b5aae81feb425d8a05dcf95803. 22 October 2014, 21:54:26 UTC
a8f8ba9 Alejandro Mery 22 October 2014, 21:53:32 UTC Merge branch 'reference-3.4' into stage/sunxi-3.4 22 October 2014, 21:53:32 UTC
7cf03b1 Alejandro Mery 22 October 2014, 21:51:36 UTC Merge remote-tracking branch 'origin/mirror/android-3.4' into reference-3.4 22 October 2014, 21:51:36 UTC
a4df1cd Alejandro Mery 22 October 2014, 21:50:55 UTC Merge tag 'v3.4.104' into reference-3.4 This is the 3.4.104 stable release 22 October 2014, 21:50:55 UTC
e01bd6b Ruchi Kandoi 21 October 2014, 20:55:04 UTC cpufreq: Avoid using global variable total_cpus The change is to compile on kernels where cpufreq stats are compiled as a module (CONFIG_CPU_FREQ_STAT=m), because total_cpus is not exported for module use. Reported-By: Emilio López <elopez93@gmail.com> Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com> Change-Id: I4f3c74f0fac5e8d9449655b26bf3b407b0fe4290 21 October 2014, 22:10:22 UTC
e4ac161 Ruchi Kandoi 15 October 2014, 00:43:21 UTC power: Avoids bogus error messages for the suspend aborts. Avoids printing bogus error message "tasks refusing to freeze", in cases where pending wakeup source caused the suspend abort. Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com> Change-Id: I913ad290f501b31cd536d039834c8d24c6f16928 16 October 2014, 16:44:22 UTC
9a1cd03 Siarhei Siamashka 04 October 2014, 04:59:35 UTC sunxi: Calculate PLL5P clock divisors for G2D, ACE and DEBE When PLL5P is used as a parent clock for some of the peripherals, the current code just selects some hardcoded divisors. This happens to work, but only under assumption that the PLL5P clock speed is somewhere between 360MHz and 480MHz (the typical DRAM clock speeds). However with some tweaks for the DRAM parameters, it is possible to clock DRAM up to 600MHz and more on some devices: http://lists.denx.de/pipermail/u-boot/2014-July/183981.html And this introduces concerns about the hardcoded divisors in the kernel, which may cause some peripherals to operate at abnormally high clock speeds if the PLL5 clock speed is too fast (PLL5 is used for clocking DRAM). Moreover, it makes sense to avoid pre-dividing PLL5P and make it run even faster than DRAM. This provides better granularity of the clock speed selection for MBUS, G2D and everything else that is using PLL5P as the parent clock. but running PLL5P faster means that the hardcoded divisors become even more inappropriate. This patch improves the clock divisors selection for G2D, ACE and DEBE to insure that they can work correctly with any PLL5P clock speed. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com> 14 October 2014, 18:46:59 UTC
5052b83 Siarhei Siamashka 18 September 2014, 21:42:50 UTC sunxi: axp209: Protect dcdc3 voltage from modification The dcdc3 voltage is expected to be set by the bootloader and the right voltage depends on the DRAM settings (higher clock speed needs more voltage). Allowing to use the 'dcdc3_vol' parameter from the FEX file only introduces an unnecessary fragile dependency between the settings in u-boot and the settings in FEX. So now we ignore this parameter in FEX and keep the original dcdc3 voltage set by the bootloader. The dmesg log now looks like this: [ 2.212941] axp20_ldo1: 1300 mV [ 2.221370] axp20_ldo2: 1800 <--> 3300 mV at 3000 mV [ 2.231662] axp20_ldo3: 700 <--> 3500 mV at 2800 mV [ 2.241747] axp20_ldo4: 1250 <--> 3300 mV at 2800 mV [ 2.251906] axp20_buck2: 700 <--> 2275 mV at 1400 mV [ 2.263430] somebody is trying to set dcdc3 range to (1300000, 1300000) uV [ 2.275327] but we keep dcdc3 = 1250000 uV from the bootloader [ 2.285406] axp20_buck3: 700 <--> 3500 mV at 1250 mV [ 2.295299] axp20_ldoio0: 1800 <--> 3300 mV at 2800 mV Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com> 14 October 2014, 18:46:51 UTC
c4901d9 Paul Kocialkowski 08 October 2014, 17:11:40 UTC sun4i-keyboard: 250Hz LRADC sampling This is required to have fast enough key presses with sun4i-keyboard (actually used on sun4i, sun5i and sun7i) on CWM recovery, an Android initramfs that allows easy flashing of the devices. With any lower sampling rate, close key presses are not distinguished and reported as one long press. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> 14 October 2014, 18:41:44 UTC
0b20c61 David Herrmann 15 July 2013, 17:10:12 UTC HID: input: generic hidinput_input_event handler The hidinput_input_event() callback converts input events written from userspace into HID reports and sends them to the device. We currently implement this in every HID transport driver, even though most of them do the same. This provides a generic hidinput_input_event() implementation which is mostly copied from usbhid. It uses a delayed worker to allow multiple LED events to be collected into a single output event. We use the custom ->request() transport driver callback to allow drivers to adjust the outgoing report and handle the request asynchronously. If no custom ->request() callback is available, we fall back to the generic raw output report handler (which is synchronous). Drivers can still provide custom hidinput_input_event() handlers (see logitech-dj) if the generic implementation doesn't fit their needs. Conflicts: drivers/hid/hid-input.c Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Michael Wright <michaelwr@google.com> Change-Id: I89ccc3f675b3e8a7bbd812a6ebe12588d737cfd6 02 October 2014, 17:35:53 UTC
bb4a05a Zefan Li 25 September 2014, 03:49:19 UTC Linux 3.4.104 25 September 2014, 03:49:19 UTC
618dea4 Michael Cree 30 November 2011, 13:01:40 UTC alpha: add io{read,write}{16,32}be functions commit 25534eb7707821b796fd84f7115367e02f36aa60 upstream. These functions are used in some PCI drivers with big-endian MMIO space. Admittedly it is almost certain that no one this side of the Moon would use such a card in an Alpha but it does get us closer to being able to build allyesconfig or allmodconfig, and it enables the Debian default generic config to build. Tested-by: Raúl Porcel <armin76@gentoo.org> Signed-off-by: Michael Cree <mcree@orcon.net.nz> Signed-off-by: Matt Turner <mattst88@gmail.com> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:19 UTC
3a8f613 Jan Kara 05 November 2013, 00:15:38 UTC ext2: Fix fs corruption in ext2_get_xip_mem() commit 7ba3ec5749ddb61f79f7be17b5fd7720eebc52de upstream. Commit 8e3dffc651cb "Ext2: mark inode dirty after the function dquot_free_block_nodirty is called" unveiled a bug in __ext2_get_block() called from ext2_get_xip_mem(). That function called ext2_get_block() mistakenly asking it to map 0 blocks while 1 was intended. Before the above mentioned commit things worked out fine by luck but after that commit we started returning that we allocated 0 blocks while we in fact allocated 1 block and thus allocation was looping until all blocks in the filesystem were exhausted. Fix the problem by properly asking for one block and also add assertion in ext2_get_blocks() to catch similar problems. Reported-and-tested-by: Andiry Xu <andiry.xu@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Cc: Wang Nan <wangnan0@huawei.com> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:19 UTC
f79bb94 Michael Cree 19 August 2012, 02:41:04 UTC alpha: Fix fall-out from disintegrating asm/system.h commit d1b5153f3ec83789b71d64efaf2a880c8fe6358e upstream. Commit ec2212088c42 ("Disintegrate asm/system.h for Alpha") removed asm/system.h however arch/alpha/oprofile/common.c requires definitions that were shifted from asm/system.h to asm/special_insns.h. Include that. Signed-off-by: Michael Cree <mcree@orcon.net.nz> Acked-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:18 UTC
92a6e26 Guan Xuetao 14 June 2012, 07:39:48 UTC UniCore32-bugfix: fix mismatch return value of __xchg_bad_pointer commit 195d4577d1d7ab1f0398b3190547c116b56f435f upstream. When disintegrate system.h, I left an error in asm/cmpxchg.h, which will result in following error: arch/unicore32/include/asm/cmpxchg.h: In function '__xchg': arch/unicore32/include/asm/cmpxchg.h:38: error: void value not ignored as it ought to be Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:18 UTC
4e36063 Guan Xuetao 14 June 2012, 03:38:25 UTC UniCore32-bugfix: Remove definitions in asm/bug.h to solve difference between native and cross compiler commit 10e1e99e55378a65529c48753703c069aebce7af upstream. For kernel/bound.c being compiled by native compiler, it will generate following errors in gcc 4.4.3: CC kernel/bounds.s In file included from include/linux/bug.h:4, from include/linux/page-flags.h:9, from kernel/bounds.c:9: arch/unicore32/include/asm/bug.h:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void' arch/unicore32/include/asm/bug.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void' So, we moved definitions in asm/bug.h to arch/unicore32/kernel/setup.h to solve the problem. Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:18 UTC
62cdcce Fengguang Wu 05 October 2012, 00:11:23 UTC unicore32: select generic atomic64_t support commit 82e54a6aaf8aec971fb16afa3a4404e238a1b98b upstream. It's required for the core fs/namespace.c and many other basic features. Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:18 UTC
82a938a Paul Gortmaker 25 August 2014, 17:33:20 UTC 8250_pci: fix warnings in backport of Broadcom TruManage support commit 7400ce7ee9595432b2a1402b6ffcac9faf38d9ae (v3.4.92-76-g7400ce7ee959) was a backport of commit ebebd49a8eab5e9aa1b1f8f1614ccc3c2120f886 upstream ("8250/16?50: Add support for Broadcom TruManage redirected serial port") However, in the context of 3.4.x kernels, the pci setup code was expecting a struct uart_port and not a struct uart_8250_port, leading to the following concerning warnings: drivers/tty/serial/8250/8250_pci.c: In function ‘pci_brcm_trumanage_setup’: drivers/tty/serial/8250/8250_pci.c:1086:2: warning: passing argument 3 of ‘pci_default_setup’ from incompatible pointer type [enabled by default] int ret = pci_default_setup(priv, board, port, idx); ^ drivers/tty/serial/8250/8250_pci.c:1036:1: note: expected ‘struct uart_port *’ but argument is of type ‘struct uart_8250_port *’ pci_default_setup(struct serial_private *priv, ^ drivers/tty/serial/8250/8250_pci.c: At top level: drivers/tty/serial/8250/8250_pci.c:1746:3: warning: initialization from incompatible pointer type [enabled by default] .setup = pci_brcm_trumanage_setup, ^ drivers/tty/serial/8250/8250_pci.c:1746:3: warning: (near initialization for ‘pci_serial_quirks[56].setup’) [enabled by default] I'd also expect the initialization to not function correctly, and perhaps dereference random garbage due to this. Since the uart_port is a field within the uart_8250_port, the adaptation to fix these warnings is a straightforward removal of a layer of indirection. Cc: Stephen Hurd <shurd@broadcom.com> Cc: Michael Chan <mchan@broadcom.com> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: Rui Xiang <rui.xiang@huawei.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:18 UTC
69db2d4 Andi Kleen 09 June 2012, 09:40:03 UTC slab/mempolicy: always use local policy from interrupt context commit e7b691b085fda913830e5280ae6f724b2a63c824 upstream. slab_node() could access current->mempolicy from interrupt context. However there's a race condition during exit where the mempolicy is first freed and then the pointer zeroed. Using this from interrupts seems bogus anyways. The interrupt will interrupt a random process and therefore get a random mempolicy. Many times, this will be idle's, which noone can change. Just disable this here and always use local for slab from interrupts. I also cleaned up the callers of slab_node a bit which always passed the same argument. I believe the original mempolicy code did that in fact, so it's likely a regression. v2: send version with correct logic v3: simplify. fix typo. Reported-by: Arun Sharma <asharma@fb.com> Cc: penberg@kernel.org Cc: cl@linux.com Signed-off-by: Andi Kleen <ak@linux.intel.com> [tdmackey@twitter.com: Rework control flow based on feedback from cl@linux.com, fix logic, and cleanup current task_struct reference] Acked-by: David Rientjes <rientjes@google.com> Acked-by: Christoph Lameter <cl@linux.com> Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by: David Mackey <tdmackey@twitter.com> Signed-off-by: Pekka Enberg <penberg@kernel.org> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:17 UTC
ab22539 Stefan Kristiansson 26 February 2013, 06:36:29 UTC openrisc: add missing header inclusion commit 160d83781a32e94a1e337efd6722939001e62398 upstream. Prevents build issue with updated toolchain Reported-by: Jack Thomasson <jkt@moonlitsw.com> Tested-by: Christian Svensson <blue@cmd.nu> Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> Signed-off-by: Jonas Bonn <jonas@southpole.se> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:17 UTC
c1bc007 Ralf Baechle 17 September 2013, 10:44:31 UTC MIPS: Fix accessing to per-cpu data when flushing the cache commit ff522058bd717506b2fa066fa564657f2b86477e upstream. This fixes the following issue BUG: using smp_processor_id() in preemptible [00000000] code: kjournald/1761 caller is blast_dcache32+0x30/0x254 Call Trace: [<8047f02c>] dump_stack+0x8/0x34 [<802e7e40>] debug_smp_processor_id+0xe0/0xf0 [<80114d94>] blast_dcache32+0x30/0x254 [<80118484>] r4k_dma_cache_wback_inv+0x200/0x288 [<80110ff0>] mips_dma_map_sg+0x108/0x180 [<80355098>] ide_dma_prepare+0xf0/0x1b8 [<8034eaa4>] do_rw_taskfile+0x1e8/0x33c [<8035951c>] ide_do_rw_disk+0x298/0x3e4 [<8034a3c4>] do_ide_request+0x2e0/0x704 [<802bb0dc>] __blk_run_queue+0x44/0x64 [<802be000>] queue_unplugged.isra.36+0x1c/0x54 [<802beb94>] blk_flush_plug_list+0x18c/0x24c [<802bec6c>] blk_finish_plug+0x18/0x48 [<8026554c>] journal_commit_transaction+0x3b8/0x151c [<80269648>] kjournald+0xec/0x238 [<8014ac00>] kthread+0xb8/0xc0 [<8010268c>] ret_from_kernel_thread+0x14/0x1c Caches in most systems are identical - but not always, so we can't avoid the use of smp_call_function() by just looking at the boot CPU's data, have to fiddle with preemption instead. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/5835 Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:17 UTC
9a8fa93 Florian Fainelli 19 July 2012, 07:13:52 UTC MIPS: perf: Fix build error caused by unused counters_per_cpu_to_total() commit 6c37c9580409af7dc664bb6af0a85d540d63aeea upstream. cc1: warnings being treated as errors arch/mips/kernel/perf_event_mipsxx.c:166: error: 'counters_per_cpu_to_total' defined but not used make[2]: *** [arch/mips/kernel/perf_event_mipsxx.o] Error 1 make[2]: *** Waiting for unfinished jobs.... It was first introduced by 82091564cfd7ab8def42777a9c662dbf655c5d25 [MIPS: perf: Add support for 64-bit perf counters.] in 3.2. Signed-off-by: Florian Fainelli <florian@openwrt.org> Cc: linux-mips@linux-mips.org Cc: david.daney@cavium.com Patchwork: https://patchwork.linux-mips.org/patch/3357/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:17 UTC
c804743 Johan Hovold 27 August 2014, 09:55:19 UTC USB: serial: fix potential heap buffer overflow commit 5654699fb38512bdbfc0f892ce54fce75bdc2bab upstream. Make sure to verify the number of ports requested by subdriver to avoid writing beyond the end of fixed-size array in interface data. The current usb-serial implementation is limited to eight ports per interface but failed to verify that the number of ports requested by a subdriver (which could have been determined from device descriptors) did not exceed this limit. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [lizf: Backported to 3.4: s/ddev/\&interface->dev/] Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:16 UTC
62148f7 Johan Hovold 27 August 2014, 09:55:18 UTC USB: serial: fix potential stack buffer overflow commit d979e9f9ecab04c1ecca741370e30a8a498893f5 upstream. Make sure to verify the maximum number of endpoints per type to avoid writing beyond the end of a stack-allocated array. The current usb-serial implementation is limited to eight ports per interface but failed to verify that the number of endpoints of a certain type reported by a device did not exceed this limit. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:16 UTC
2f3e285 Mark Rutland 15 August 2014, 11:11:50 UTC ARM: 8129/1: errata: work around Cortex-A15 erratum 830321 using dummy strex commit 2c32c65e3726c773760038910be30cce1b4d4149 upstream. On revisions of Cortex-A15 prior to r3p3, a CLREX instruction at PL1 may falsely trigger a watchpoint exception, leading to potential data aborts during exception return and/or livelock. This patch resolves the issue in the following ways: - Replacing our uses of CLREX with a dummy STREX sequence instead (as we did for v6 CPUs). - Removing the clrex code from v7_exit_coherency_flush and derivatives, since this only exists as a minor performance improvement when non-cached exclusives are in use (Linux doesn't use these). Benchmarking on a variety of ARM cores revealed no measurable performance difference with this change applied, so the change is performed unconditionally and no new Kconfig entry is added. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> [lizf: Backported to 3.4: - Drop changes to arch/arm/include/asm/cacheflush.h and arch/arm/mach-exynos/mcpm-exynos.c] Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:16 UTC
5624bb3 Mark Rutland 15 August 2014, 11:11:49 UTC ARM: 8128/1: abort: don't clear the exclusive monitors commit 85868313177700d20644263a782351262d2aff84 upstream. The ARMv6 and ARMv7 early abort handlers clear the exclusive monitors upon entry to the kernel, but this is redundant: - We clear the monitors on every exception return since commit 200b812d0084 ("Clear the exclusive monitor when returning from an exception"), so this is not necessary to ensure the monitors are cleared before returning from a fault handler. - Any dummy STREX will target a temporary scratch area in memory, and may succeed or fail without corrupting useful data. Its status value will not be used. - Any other STREX in the kernel must be preceded by an LDREX, which will initialise the monitors consistently and will not depend on the earlier state of the monitors. Therefore we have no reason to care about the initial state of the exclusive monitors when a data abort is taken, and clearing the monitors prior to exception return (as we already do) is sufficient. This patch removes the redundant clearing of the exclusive monitors from the early abort handlers. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:16 UTC
e78c127 Jiri Kosina 27 August 2014, 07:13:15 UTC HID: picolcd: sanity check report size in raw_event() callback commit 844817e47eef14141cf59b8d5ac08dd11c0a9189 upstream. The report passed to us from transport driver could potentially be arbitrarily large, therefore we better sanity-check it so that raw_data that we hold in picolcd_pending structure are always kept within proper bounds. Reported-by: Steven Vittitoe <scvitti@google.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> [lizf: Backported to 3.4: adjust filename] Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:15 UTC
e115f02 Jiri Kosina 27 August 2014, 07:12:24 UTC HID: magicmouse: sanity check report size in raw_event() callback commit c54def7bd64d7c0b6993336abcffb8444795bf38 upstream. The report passed to us from transport driver could potentially be arbitrarily large, therefore we better sanity-check it so that magicmouse_emit_touch() gets only valid values of raw_id. Reported-by: Steven Vittitoe <scvitti@google.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:15 UTC
0bfb000 Trond Myklebust 26 August 2014, 02:33:12 UTC NFSv4: Fix problems with close in the presence of a delegation commit aee7af356e151494d5014f57b33460b162f181b5 upstream. In the presence of delegations, we can no longer assume that the state->n_rdwr, state->n_rdonly, state->n_wronly reflect the open stateid share mode, and so we need to calculate the initial value for calldata->arg.fmode using the state->flags. Reported-by: James Drews <drews@engr.wisc.edu> Fixes: 88069f77e1ac5 (NFSv41: Fix a potential state leakage when...) Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> [lizf: Backport to 3.4: adjust context] Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:15 UTC
818ee41 Stephen Hemminger 26 August 2014, 04:07:47 UTC USB: sisusb: add device id for Magic Control USB video commit 5b6b80aeb21091ed3030b9b6aae597d81326f1aa upstream. I have a j5 create (JUA210) USB 2 video device and adding it device id to SIS USB video gets it to work. Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:15 UTC
86d165e Benjamin Tissoires 22 August 2014, 20:16:05 UTC HID: logitech-dj: prevent false errors to be shown commit 5abfe85c1d4694d5d4bbd13ecc166262b937adf0 upstream. Commit "HID: logitech: perform bounds checking on device_id early enough" unfortunately leaks some errors to dmesg which are not real ones: - if the report is not a DJ one, then there is not point in checking the device_id - the receiver (index 0) can also receive some notifications which can be safely ignored given the current implementation Move out the test regarding the report_id and also discards printing errors when the receiver got notified. Fixes: ad3e14d7c5268c2e24477c6ef54bbdf88add5d36 Reported-and-tested-by: Markus Trippelsdorf <markus@trippelsdorf.de> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:14 UTC
2f2c704 James Forshaw 23 August 2014, 21:39:48 UTC USB: whiteheat: Added bounds checking for bulk command response commit 6817ae225cd650fb1c3295d769298c38b1eba818 upstream. This patch fixes a potential security issue in the whiteheat USB driver which might allow a local attacker to cause kernel memory corrpution. This is due to an unchecked memcpy into a fixed size buffer (of 64 bytes). On EHCI and XHCI busses it's possible to craft responses greater than 64 bytes leading a buffer overflow. Signed-off-by: James Forshaw <forshaw@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:14 UTC
1d37c3e Huang Rui 19 August 2014, 12:17:57 UTC usb: xhci: amd chipset also needs short TX quirk commit 2597fe99bb0259387111d0431691f5daac84f5a5 upstream. AMD xHC also needs short tx quirk after tested on most of chipset generations. That's because there is the same incorrect behavior like Fresco Logic host. Please see below message with on USB webcam attached on xHC host: [ 139.262944] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.266934] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.270913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.274937] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.278914] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.282936] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.286915] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.290938] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.294913] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [ 139.298917] xhci_hcd 0000:00:10.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? Reported-by: Arindam Nath <arindam.nath@amd.com> Tested-by: Shriraj-Rai P <shriraj-rai.p@amd.com> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:14 UTC
42494f0 Hans de Goede 19 August 2014, 12:17:56 UTC xhci: Treat not finding the event_seg on COMP_STOP the same as COMP_STOP_INVAL commit 9a54886342e227433aebc9d374f8ae268a836475 upstream. When using a Renesas uPD720231 chipset usb-3 uas to sata bridge with a 120G Crucial M500 ssd, model string: Crucial_ CT120M500SSD1, together with a the integrated Intel xhci controller on a Haswell laptop: 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04) The following error gets logged to dmesg: xhci error: Transfer event TRB DMA ptr not part of current TD Treating COMP_STOP the same as COMP_STOP_INVAL when no event_seg gets found fixes this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:14 UTC
d232e2c Jaša Bartelj 16 August 2014, 10:44:27 UTC USB: ftdi_sio: Added PID for new ekey device commit 646907f5bfb0782c731ae9ff6fb63471a3566132 upstream. Added support to the ftdi_sio driver for ekey Converter USB which uses an FT232BM chip. Signed-off-by: Jaša Bartelj <jasa.bartelj@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:13 UTC
68e9929 Greg KH 15 August 2014, 07:22:21 UTC USB: serial: pl2303: add device id for ztek device commit 91fcb1ce420e0a5f8d92d556d7008a78bc6ce1eb upstream. This adds a new device id to the pl2303 driver for the ZTEK device. Reported-by: Mike Chu <Mike-Chu@prolific.com.tw> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:13 UTC
262548e Johan Hovold 13 August 2014, 15:56:52 UTC USB: ftdi_sio: add Basic Micro ATOM Nano USB2Serial PID commit 6552cc7f09261db2aeaae389aa2c05a74b3a93b4 upstream. Add device id for Basic Micro ATOM Nano USB2Serial adapters. Reported-by: Nicolas Alt <n.alt@mytum.de> Tested-by: Nicolas Alt <n.alt@mytum.de> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:13 UTC
78aea3a Brennan Ashton 06 August 2014, 15:46:44 UTC USB: option: add VIA Telecom CDS7 chipset device id commit d77302739d900bbca5e901a3b7ac48c907ee6c93 upstream. This VIA Telecom baseband processor is used is used by by u-blox in both the FW2770 and FW2760 products and may be used in others as well. This patch has been tested on both of these modem versions. Signed-off-by: Brennan Ashton <bashton@brennanashton.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:13 UTC
c2aa9b7 Mark Einon 10 August 2014, 21:16:55 UTC staging: et131x: Fix errors caused by phydev->addr accesses before initialisation commit ec0a38bf8b28b036202070cf3ef271e343d9eafc upstream. Fix two reported bugs, caused by et131x_adapter->phydev->addr being accessed before it is initialised, by: - letting et131x_mii_write() take a phydev address, instead of using the one stored in adapter by default. This is so et131x_mdio_write() can use it's own addr value. - removing implementation of et131x_mdio_reset(), as it's not needed. - moving a call to et131x_disable_phy_coma() in et131x_pci_setup(), which uses phydev->addr, until after the mdiobus has been registered. Link: https://bugzilla.kernel.org/show_bug.cgi?id=80751 Link: https://bugzilla.kernel.org/show_bug.cgi?id=77121 Signed-off-by: Mark Einon <mark.einon@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [lizf: Backported to 3.4: - adjust context - update more update more et131x_mii_write() calls in et1310_phy_access_mii_bit() and et131x_xcvr_init()] Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:12 UTC
f40751b Max Filippov 31 July 2014, 18:40:57 UTC xtensa: fix a6 and a7 handling in fast_syscall_xtensa commit d1b6ba82a50cecf94be540a3a153aa89d97511a0 upstream. Remove restoring a6 on some return paths and instead modify and restore it in a single place, using symbolic name. Correctly restore a7 from PT_AREG7 in case of illegal a6 value. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:12 UTC
bcf20fd Max Filippov 21 July 2014, 18:01:51 UTC xtensa: fix TLBTEMP_BASE_2 region handling in fast_second_level_miss commit 7128039fe2dd3d59da9e4ffa036f3aaa3ba87b9f upstream. Current definition of TLBTEMP_BASE_2 is always 32K above the TLBTEMP_BASE_1, whereas fast_second_level_miss handler for the TLBTEMP region analyzes virtual address bit (PAGE_SHIFT + DCACHE_ALIAS_ORDER) to determine TLBTEMP region where the fault happened. The size of the TLBTEMP region is also checked incorrectly: not 64K, but twice data cache way size (whicht may as well be less than the instruction cache way size). Fix TLBTEMP_BASE_2 to be TLBTEMP_BASE_1 + data cache way size. Provide TLBTEMP_SIZE that is a greater of doubled data cache way size or the instruction cache way size, and use it to determine if the second level TLB miss occured in the TLBTEMP region. Practical occurence of page faults in the TLBTEMP area is extremely rare, this code can be tested by deletion of all w[di]tlb instructions in the tlbtemp_mapping region. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:12 UTC
fb2ae73 Alan Douglas 23 July 2014, 10:06:40 UTC xtensa: fix address checks in dma_{alloc,free}_coherent commit 1ca49463c44c970b1ab1d71b0f268bfdf8427a7e upstream. Virtual address is translated to the XCHAL_KSEG_CACHED region in the dma_free_coherent, but is checked to be in the 0...XCHAL_KSEG_SIZE range. Change check for end of the range from 'addr >= X' to 'addr > X - 1' to handle the case of X == 0. Replace 'if (C) BUG();' construct with 'BUG_ON(C);'. Signed-off-by: Alan Douglas <adouglas@cadence.com> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:12 UTC
2297927 Max Filippov 19 July 2014, 23:38:53 UTC xtensa: replace IOCTL code definitions with constants commit f61bf8e7d19e0a3456a7a9ed97c399e4353698dc upstream. This fixes userspace code that builds on other architectures but fails on xtensa due to references to structures that other architectures don't refer to. E.g. this fixes the following issue with python-2.7.8: python-2.7.8/Modules/termios.c:861:25: error: invalid application of 'sizeof' to incomplete type 'struct serial_multiport_struct' {"TIOCSERGETMULTI", TIOCSERGETMULTI}, python-2.7.8/Modules/termios.c:870:25: error: invalid application of 'sizeof' to incomplete type 'struct serial_multiport_struct' {"TIOCSERSETMULTI", TIOCSERSETMULTI}, python-2.7.8/Modules/termios.c:900:24: error: invalid application of 'sizeof' to incomplete type 'struct tty_struct' {"TIOCTTYGSTRUCT", TIOCTTYGSTRUCT}, Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> [lizf: Backported to 3.4: adjust filename] Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:12 UTC
483320c Takashi Iwai 15 August 2014, 15:35:00 UTC ALSA: hda/realtek - Avoid setting wrong COEF on ALC269 & co commit f3ee07d8b6e061bf34a7167c3f564e8da4360a99 upstream. ALC269 & co have many vendor-specific setups with COEF verbs. However, some verbs seem specific to some codec versions and they result in the codec stalling. Typically, such a case can be avoided by checking the return value from reading a COEF. If the return value is -1, it implies that the COEF is invalid, thus it shouldn't be written. This patch adds the invalid COEF checks in appropriate places accessing ALC269 and its variants. The patch actually fixes the resume problem on Acer AO725 laptop. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52181 Tested-by: Francesco Muzio <muziofg@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:11 UTC
d06e4b0 Pavel Shilovsky 18 August 2014, 16:49:58 UTC CIFS: Fix wrong directory attributes after rename commit b46799a8f28c43c5264ac8d8ffa28b311b557e03 upstream. When we requests rename we also need to update attributes of both source and target parent directories. Not doing it causes generic/309 xfstest to fail on SMB2 mounts. Fix this by marking these directories for force revalidating. Signed-off-by: Pavel Shilovsky <pshilovsky@samba.org> Signed-off-by: Steve French <smfrench@gmail.com> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:11 UTC
a0e5b9d NeilBrown 12 August 2014, 23:57:07 UTC md/raid6: avoid data corruption during recovery of double-degraded RAID6 commit 9c4bdf697c39805078392d5ddbbba5ae5680e0dd upstream. During recovery of a double-degraded RAID6 it is possible for some blocks not to be recovered properly, leading to corruption. If a write happens to one block in a stripe that would be written to a missing device, and at the same time that stripe is recovering data to the other missing device, then that recovered data may not be written. This patch skips, in the double-degraded case, an optimisation that is only safe for single-degraded arrays. Bug was introduced in 2.6.32 and fix is suitable for any kernel since then. In an older kernel with separate handle_stripe5() and handle_stripe6() functions the patch must change handle_stripe6(). Fixes: 6c0069c0ae9659e3a91b68eaed06a5c6c37f45c8 Cc: Yuri Tikhonov <yur@emcraft.com> Cc: Dan Williams <dan.j.williams@intel.com> Reported-by: "Manibalan P" <pmanibalan@amiindia.co.in> Tested-by: "Manibalan P" <pmanibalan@amiindia.co.in> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1090423 Signed-off-by: NeilBrown <neilb@suse.de> Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:11 UTC
77e5657 Joerg Roedel 05 August 2014, 15:50:15 UTC iommu/amd: Fix cleanup_domain for mass device removal commit 9b29d3c6510407d91786c1cf9183ff4debb3473a upstream. When multiple devices are detached in __detach_device, they are also removed from the domains dev_list. This makes it unsafe to use list_for_each_entry_safe, as the next pointer might also not be in the list anymore after __detach_device returns. So just repeatedly remove the first element of the list until it is empty. Tested-by: Marti Raudsepp <marti@juffo.org> Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:11 UTC
db83744 Arjun Sreedharan 17 August 2014, 14:30:09 UTC pata_scc: propagate return value of scc_wait_after_reset commit 4dc7c76cd500fa78c64adfda4b070b870a2b993c upstream. scc_bus_softreset not necessarily should return zero. Propagate the error code. Signed-off-by: Arjun Sreedharan <arjun024@gmail.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:11 UTC
f0634a3 Michael S. Tsirkin 19 August 2014, 11:14:50 UTC kvm: iommu: fix the third parameter of kvm_iommu_put_pages (CVE-2014-3601) commit 350b8bdd689cd2ab2c67c8a86a0be86cfa0751a7 upstream. The third parameter of kvm_iommu_put_pages is wrong, It should be 'gfn - slot->base_gfn'. By making gfn very large, malicious guest or userspace can cause kvm to go to this error path, and subsequently to pass a huge value as size. Alternatively if gfn is small, then pages would be pinned but never unpinned, causing host memory leak and local DOS. Passing a reasonable but large value could be the most dangerous case, because it would unpin a page that should have stayed pinned, and thus allow the device to DMA into arbitrary memory. However, this cannot happen because of the condition that can trigger the error: - out of memory (where you can't allocate even a single page) should not be possible for the attacker to trigger - when exceeding the iommu's address space, guest pages after gfn will also exceed the iommu's address space, and inside kvm_iommu_put_pages() the iommu_iova_to_phys() will fail. The page thus would not be unpinned at all. Reported-by: Jack Morgenstein <jackm@mellanox.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:10 UTC
33df36f Aaro Koskinen 22 July 2014, 11:51:08 UTC MIPS: OCTEON: make get_system_type() thread-safe commit 608308682addfdc7b8e2aee88f0e028331d88e4d upstream. get_system_type() is not thread-safe on OCTEON. It uses static data, also more dangerous issue is that it's calling cvmx_fuse_read_byte() every time without any synchronization. Currently it's possible to get processes stuck looping forever in kernel simply by launching multiple readers of /proc/cpuinfo: (while true; do cat /proc/cpuinfo > /dev/null; done) & (while true; do cat /proc/cpuinfo > /dev/null; done) & ... Fix by initializing the system type string only once during the early boot. Signed-off-by: Aaro Koskinen <aaro.koskinen@nsn.com> Reviewed-by: Markos Chandras <markos.chandras@imgtec.com> Patchwork: http://patchwork.linux-mips.org/patch/7437/ Signed-off-by: James Hogan <james.hogan@imgtec.com> [lizf: Backport to 3.x: adjust context] Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:10 UTC
5ccd3e2 Jan Kara 17 August 2014, 09:49:57 UTC isofs: Fix unbounded recursion when processing relocated directories commit 410dd3cf4c9b36f27ed4542ee18b1af5e68645a4 upstream. We did not check relocated directory in any way when processing Rock Ridge 'CL' tag. Thus a corrupted isofs image can possibly have a CL entry pointing to another CL entry leading to possibly unbounded recursion in kernel code and thus stack overflow or deadlocks (if there is a loop created from CL entries). Fix the problem by not allowing CL entry to point to a directory entry with CL entry (such use makes no good sense anyway) and by checking whether CL entry doesn't point to itself. Reported-by: Chris Evans <cevans@google.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:10 UTC
c945ed6 Jiri Kosina 21 August 2014, 14:57:17 UTC HID: logitech: perform bounds checking on device_id early enough commit ad3e14d7c5268c2e24477c6ef54bbdf88add5d36 upstream. device_index is a char type and the size of paired_dj_deivces is 7 elements, therefore proper bounds checking has to be applied to device_index before it is used. We are currently performing the bounds checking in logi_dj_recv_add_djhid_device(), which is too late, as malicious device could send REPORT_TYPE_NOTIF_DEVICE_UNPAIRED early enough and trigger the problem in one of the report forwarding functions called from logi_dj_raw_event(). Fix this by performing the check at the earliest possible ocasion in logi_dj_raw_event(). Reported-by: Ben Hawkes <hawkes@google.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:10 UTC
dab2f9b Jiri Kosina 21 August 2014, 14:57:48 UTC HID: fix a couple of off-by-ones commit 4ab25786c87eb20857bbb715c3ae34ec8fd6a214 upstream. There are a few very theoretical off-by-one bugs in report descriptor size checking when performing a pre-parsing fixup. Fix those. Reported-by: Ben Hawkes <hawkes@google.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:09 UTC
9220628 Anton Blanchard 22 August 2014, 01:36:52 UTC ibmveth: Fix endian issues with rx_no_buffer statistic commit cbd5228199d8be45d895d9d0cc2b8ce53835fc21 upstream. Hidden away in the last 8 bytes of the buffer_list page is a solitary statistic. It needs to be byte swapped or else ethtool -S will produce numbers that terrify the user. Since we do this in multiple places, create a helper function with a comment explaining what is going on. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:09 UTC
c27d3b5 Daniel Mack 13 August 2014, 19:51:06 UTC ASoC: pxa-ssp: drop SNDRV_PCM_FMTBIT_S24_LE commit 9301503af016eb537ccce76adec0c1bb5c84871e upstream. This mode is unsupported, as the DMA controller can't do zero-padding of samples. Signed-off-by: Daniel Mack <zonque@gmail.com> Reported-by: Johannes Stezenbach <js@sig21.net> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:09 UTC
b402b72 Dave Chiluk 24 June 2014, 15:11:26 UTC stable_kernel_rules: Add pointer to netdev-FAQ for network patches commit b76fc285337b6b256e9ba20a40cfd043f70c27af upstream. Stable_kernel_rules should point submitters of network stable patches to the netdev_FAQ.txt as requests for stable network patches should go to netdev first. Signed-off-by: Dave Chiluk <chiluk@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Zefan Li <lizefan@huawei.com> 25 September 2014, 03:49:09 UTC
a94cffc Robert Sesek 18 August 2014, 23:14:51 UTC seccomp: Use atomic operations that are present in kernel 3.4. Signed-off-by: Robert Sesek <rsesek@google.com> 17 September 2014, 20:43:14 UTC
f1a3422 Kees Cook 05 June 2014, 07:23:17 UTC seccomp: implement SECCOMP_FILTER_FLAG_TSYNC Applying restrictive seccomp filter programs to large or diverse codebases often requires handling threads which may be started early in the process lifetime (e.g., by code that is linked in). While it is possible to apply permissive programs prior to process start up, it is difficult to further restrict the kernel ABI to those threads after that point. This change adds a new seccomp syscall flag to SECCOMP_SET_MODE_FILTER for synchronizing thread group seccomp filters at filter installation time. When calling seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, filter) an attempt will be made to synchronize all threads in current's threadgroup to its new seccomp filter program. This is possible iff all threads are using a filter that is an ancestor to the filter current is attempting to synchronize to. NULL filters (where the task is running as SECCOMP_MODE_NONE) are also treated as ancestors allowing threads to be transitioned into SECCOMP_MODE_FILTER. If prctrl(PR_SET_NO_NEW_PRIVS, ...) has been set on the calling thread, no_new_privs will be set for all synchronized threads too. On success, 0 is returned. On failure, the pid of one of the failing threads will be returned and no filters will have been applied. The race conditions against another thread are: - requesting TSYNC (already handled by sighand lock) - performing a clone (already handled by sighand lock) - changing its filter (already handled by sighand lock) - calling exec (handled by cred_guard_mutex) The clone case is assisted by the fact that new threads will have their seccomp state duplicated from their parent before appearing on the tasklist. Holding cred_guard_mutex means that seccomp filters cannot be assigned while in the middle of another thread's exec (potentially bypassing no_new_privs or similar). The call to de_thread() may kill threads waiting for the mutex. Changes across threads to the filter pointer includes a barrier. Based on patches by Will Drewry. Suggested-by: Julien Tinnes <jln@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Andy Lutomirski <luto@amacapital.net> Conflicts: include/linux/seccomp.h include/uapi/linux/seccomp.h 17 September 2014, 20:43:14 UTC
4202973 Oleg Nesterov 21 January 2014, 23:49:56 UTC introduce for_each_thread() to replace the buggy while_each_thread() while_each_thread() and next_thread() should die, almost every lockless usage is wrong. 1. Unless g == current, the lockless while_each_thread() is not safe. while_each_thread(g, t) can loop forever if g exits, next_thread() can't reach the unhashed thread in this case. Note that this can happen even if g is the group leader, it can exec. 2. Even if while_each_thread() itself was correct, people often use it wrongly. It was never safe to just take rcu_read_lock() and loop unless you verify that pid_alive(g) == T, even the first next_thread() can point to the already freed/reused memory. This patch adds signal_struct->thread_head and task->thread_node to create the normal rcu-safe list with the stable head. The new for_each_thread(g, t) helper is always safe under rcu_read_lock() as long as this task_struct can't go away. Note: of course it is ugly to have both task_struct->thread_node and the old task_struct->thread_group, we will kill it later, after we change the users of while_each_thread() to use for_each_thread(). Perhaps we can kill it even before we convert all users, we can reimplement next_thread(t) using the new thread_head/thread_node. But we can't do this right now because this will lead to subtle behavioural changes. For example, do/while_each_thread() always sees at least one task, while for_each_thread() can do nothing if the whole thread group has died. Or thread_group_empty(), currently its semantics is not clear unless thread_group_leader(p) and we need to audit the callers before we can change it. So this patch adds the new interface which has to coexist with the old one for some time, hopefully the next changes will be more or less straightforward and the old one will go away soon. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Sergey Dyasly <dserrg@gmail.com> Tested-by: Sergey Dyasly <dserrg@gmail.com> Reviewed-by: Sameer Nanda <snanda@chromium.org> Acked-by: David Rientjes <rientjes@google.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Mandeep Singh Baines <msb@chromium.org> Cc: "Ma, Xindong" <xindong.ma@intel.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: "Tu, Xiaobing" <xiaobing.tu@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Conflicts: kernel/fork.c 17 September 2014, 20:43:14 UTC
a4c269c Kees Cook 27 June 2014, 22:01:35 UTC seccomp: allow mode setting across threads This changes the mode setting helper to allow threads to change the seccomp mode from another thread. We must maintain barriers to keep TIF_SECCOMP synchronized with the rest of the seccomp state. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Andy Lutomirski <luto@amacapital.net> Conflicts: kernel/seccomp.c 17 September 2014, 20:43:14 UTC
4cad9be Kees Cook 27 June 2014, 22:18:48 UTC seccomp: introduce writer locking Normally, task_struct.seccomp.filter is only ever read or modified by the task that owns it (current). This property aids in fast access during system call filtering as read access is lockless. Updating the pointer from another task, however, opens up race conditions. To allow cross-thread filter pointer updates, writes to the seccomp fields are now protected by the sighand spinlock (which is shared by all threads in the thread group). Read access remains lockless because pointer updates themselves are atomic. However, writes (or cloning) often entail additional checking (like maximum instruction counts) which require locking to perform safely. In the case of cloning threads, the child is invisible to the system until it enters the task list. To make sure a child can't be cloned from a thread and left in a prior state, seccomp duplication is additionally moved under the sighand lock. Then parent and child are certain have the same seccomp state when they exit the lock. Based on patches by Will Drewry and David Drysdale. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Andy Lutomirski <luto@amacapital.net> Conflicts: kernel/fork.c 17 September 2014, 20:43:14 UTC
850c366 Kees Cook 27 June 2014, 22:16:33 UTC seccomp: split filter prep from check and apply In preparation for adding seccomp locking, move filter creation away from where it is checked and applied. This will allow for locking where no memory allocation is happening. The validation, filter attachment, and seccomp mode setting can all happen under the future locks. For extreme defensiveness, I've added a BUG_ON check for the calculated size of the buffer allocation in case BPF_MAXINSN ever changes, which shouldn't ever happen. The compiler should actually optimize out this check since the test above it makes it impossible. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Andy Lutomirski <luto@amacapital.net> Conflicts: kernel/seccomp.c 17 September 2014, 20:43:13 UTC
db8ca0a Kees Cook 21 May 2014, 22:23:46 UTC sched: move no_new_privs into new atomic flags Since seccomp transitions between threads requires updates to the no_new_privs flag to be atomic, the flag must be part of an atomic flag set. This moves the nnp flag into a separate task field, and introduces accessors. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Andy Lutomirski <luto@amacapital.net> Conflicts: fs/exec.c include/linux/sched.h kernel/sys.c 17 September 2014, 20:43:13 UTC
13b77e1 Kees Cook 10 June 2014, 22:40:23 UTC ARM: add seccomp syscall Wires up the new seccomp syscall. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Conflicts: arch/arm/include/uapi/asm/unistd.h arch/arm/kernel/calls.S 17 September 2014, 20:43:13 UTC
64d484e Kees Cook 25 June 2014, 23:08:24 UTC seccomp: add "seccomp" syscall This adds the new "seccomp" syscall with both an "operation" and "flags" parameter for future expansion. The third argument is a pointer value, used with the SECCOMP_SET_MODE_FILTER operation. Currently, flags must be 0. This is functionally equivalent to prctl(PR_SET_SECCOMP, ...). In addition to the TSYNC flag later in this patch series, there is a non-zero chance that this syscall could be used for configuring a fixed argument area for seccomp-tracer-aware processes to pass syscall arguments in the future. Hence, the use of "seccomp" not simply "seccomp_add_filter" for this syscall. Additionally, this syscall uses operation, flags, and user pointer for arguments because strictly passing arguments via a user pointer would mean seccomp itself would be unable to trivially filter the seccomp syscall itself. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Andy Lutomirski <luto@amacapital.net> Conflicts: arch/x86/syscalls/syscall_32.tbl arch/x86/syscalls/syscall_64.tbl include/linux/syscalls.h include/uapi/asm-generic/unistd.h include/uapi/linux/seccomp.h kernel/seccomp.c kernel/sys_ni.c 17 September 2014, 20:43:13 UTC
4adf2cd Kees Cook 25 June 2014, 22:55:25 UTC seccomp: split mode setting routines Separates the two mode setting paths to make things more readable with fewer #ifdefs within function bodies. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Andy Lutomirski <luto@amacapital.net> 17 September 2014, 20:43:13 UTC
bd8e1ca Kees Cook 25 June 2014, 22:38:02 UTC seccomp: extract check/assign mode helpers To support splitting mode 1 from mode 2, extract the mode checking and assignment logic into common functions. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Andy Lutomirski <luto@amacapital.net> 17 September 2014, 20:43:12 UTC
1cf256f Kees Cook 21 May 2014, 22:02:11 UTC seccomp: create internal mode-setting function In preparation for having other callers of the seccomp mode setting logic, split the prctl entry point away from the core logic that performs seccomp mode setting. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Andy Lutomirski <luto@amacapital.net> 17 September 2014, 20:43:12 UTC
5255fd2 Kees Cook 18 July 2014, 18:28:33 UTC MAINTAINERS: create seccomp entry Add myself as seccomp maintainer. Suggested-by: James Morris <jmorris@namei.org> Signed-off-by: Kees Cook <keescook@chromium.org> 17 September 2014, 20:43:12 UTC
4e93e06 Will Drewry 27 April 2012, 17:19:46 UTC CHROMIUM: ARM: r1->r0 for get/set arguments ARM reuses r0 as the first argument. This fixes the mistaken assumption in the original patchset. These will be merged into one change when sent upstream. Signed-off-by: Will Drewry <wad@chromium.org> TEST=emerge tegra2_kaen; run seccomp testsuite BUG=chromium-os:27878 Change-Id: Iaaa09995d35f78ee8cef7b600d526e71f3b2fcec Reviewed-on: https://gerrit.chromium.org/gerrit/21342 Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Will Drewry <wad@chromium.org> Tested-by: Will Drewry <wad@chromium.org> Signed-off-by: Sasha Levitskiy <sanek@google.com> 17 September 2014, 20:43:12 UTC
2e48e52 Will Drewry 27 April 2012, 16:25:30 UTC CHROMIUM: seccomp: set -ENOSYS if there is no tracer [Will attempt to add to -next, but this may need to wait until there is a motivating usecase, like ARM, since x86 does the right thing already.] On some arches, -ENOSYS is not set as the default system call return value. This means that a skipped or invalid system call does not yield this response. That behavior is not inline with the stated ABI of seccomp filter. To that end, we ensure we set that value here to avoid arch idiosyncrasies. Signed-off-by: Will Drewry <wad@chromium.org> TEST=tegra2_kaen; boot, strace works, seccomp testsuite trace tests pass BUG=chromium-os:27878 Change-Id: I03a5e633d2fbb5d3d3cc33c067b2887068364c17 Reviewed-on: https://gerrit.chromium.org/gerrit/21337 Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Will Drewry <wad@chromium.org> Tested-by: Will Drewry <wad@chromium.org> Signed-off-by: Sasha Levitskiy <sanek@google.com> 17 September 2014, 20:43:12 UTC
b99d845 Will Drewry 26 April 2012, 20:43:25 UTC CHROMIUM: ARM: arch/arm: allow a scno of -1 to not cause a SIGILL On tracehook-friendly platforms, a system call number of -1 falls through without running much code or taking much action. ARM is different. This adds a lightweight check to arm_syscall() to make sure that ARM behaves the same way. Signed-off-by: Will Drewry <wad@chromium.org> TEST=building on tegra2 now. Will live test with seccomp testsuite. It was through SIGILL. BUG=chromium-os:27878 Change-Id: Ie3896b54e9bfa21c22e0df456a47ad03c8d0aa3f Reviewed-on: https://gerrit.chromium.org/gerrit/21251 Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Will Drewry <wad@chromium.org> Tested-by: Will Drewry <wad@chromium.org> Signed-off-by: Sasha Levitskiy <sanek@google.com> 17 September 2014, 20:43:12 UTC
0d245c7 Will Drewry 16 April 2012, 21:56:17 UTC CHROMIUM: arch/arm: select HAVE_ARCH_SECCOMP_FILTER (I will post this upstream after the 3.5 merge window) Reflect architectural support for seccomp filter. Change-Id: I163078260e73a8fb7b9967ce740bd21f83902b8e Signed-off-by: Will Drewry <wad@chromium.org> BUG=chromium-os:27878 TEST=compiles for arm. Need to test on a live machine. Change-Id: Ic0286cc7d150838fbfa05e259ea908aeeef1b864 Reviewed-on: https://gerrit.chromium.org/gerrit/21377 Reviewed-by: Will Drewry <wad@chromium.org> Tested-by: Will Drewry <wad@chromium.org> Signed-off-by: Sasha Levitskiy <sanek@google.com> 17 September 2014, 20:43:11 UTC
66a240a Will Drewry 16 April 2012, 21:37:17 UTC CHROMIUM: arch/arm: move secure_computing into trace; respect return code There is very little difference in the TIF_SECCOMP and TIF_SYSCALL_TRACE patsh in entry-common.S. In order to add support for CONFIG_HAVE_ARCH_SECCOMP_FILTER without mangling the assembly too badly, seccomp was moved into the syscall_trace() handler. Additionally, the return value for secure_computing() is now checked and a -1 value will result in the system call being skipped. (Reworked for 3.4 merge to just piggyback on the audit enter path.) Signed-off-by: Will Drewry <wad@chromium.org> BUG=chromium-os:27878 TEST=compiles for arm. Need to test on a live machine. Change-Id: I9493f28c30356a10eccb320e0a2d1a141388af9a Reviewed-on: https://gerrit.chromium.org/gerrit/21376 Reviewed-by: Will Drewry <wad@chromium.org> Tested-by: Will Drewry <wad@chromium.org> Signed-off-by: Sasha Levitskiy <sanek@google.com> 17 September 2014, 20:43:11 UTC
1c0d3df Will Drewry 16 April 2012, 19:11:17 UTC CHROMIUM: arch/arm: add asm/syscall.h (I will post this upstream after the 3.5 merge window) Provide an ARM implementation for asm-generic/syscall.h. This is a pre-requisite for CONFIG_HAVE_ARCH_TRACEHOOK and CONFIG_HAVE_ARCH_SECCOMP_FILTER. The latter is the forcing function for this patch. Change-Id: Idc5fa7b72691ec9d75418849733633df33482e53 Signed-off-by: Will Drewry <wad@chromium.org> BUG=chromium-os:27878 TEST=compiles for arm. Need to test on a live machine. Change-Id: I7b911b51085424aedd2beaf40683c3348b6cede1 Reviewed-on: https://gerrit.chromium.org/gerrit/21375 Reviewed-by: Will Drewry <wad@chromium.org> Tested-by: Will Drewry <wad@chromium.org> Signed-off-by: Sasha Levitskiy <sanek@google.com> 17 September 2014, 20:43:11 UTC
0d38273 Will Drewry 18 April 2012, 22:53:16 UTC samples/seccomp: fix dependencies on arch macros This change fixes the compilation error reported for i386 allmodconfig here: http://kisskb.ellerman.id.au/kisskb/buildresult/6123842/ Logic attempting to predict the host architecture has been removed from the Makefile. Instead, the bpf-direct sample should now compile on any architecture, but if the architecture is not supported, it will compile a minimal main() function. This change also ensures the samples are not compiled when there is no seccomp filter support. Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com> Suggested-by: Kees Cook <keescook@chromium.org> Signed-off-by: Will Drewry <wad@chromium.org> 17 September 2014, 20:43:11 UTC
7119ba4 Will Drewry 17 April 2012, 19:48:58 UTC seccomp: fix build warnings when there is no CONFIG_SECCOMP_FILTER If both audit and seccomp filter support are disabled, 'ret' is marked as unused. If just seccomp filter support is disabled, data and skip are considered unused. This change fixes those build warnings. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Will Drewry <wad@chromium.org> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com> 17 September 2014, 20:43:11 UTC
dc46412 Will Drewry 17 April 2012, 19:48:57 UTC seccomp: ignore secure_computing return values This change is inspired by https://lkml.org/lkml/2012/4/16/14 which fixes the build warnings for arches that don't support CONFIG_HAVE_ARCH_SECCOMP_FILTER. In particular, there is no requirement for the return value of secure_computing() to be checked unless the architecture supports seccomp filter. Instead of silencing the warnings with (void) a new static inline is added to encode the expected behavior in a compiler and human friendly way. v2: - cleans things up with a static inline - removes sfr's signed-off-by since it is a different approach v1: - matches sfr's original change Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Will Drewry <wad@chromium.org> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com> 17 September 2014, 20:43:10 UTC
ef7720c Stephen Rothwell 17 April 2012, 02:08:48 UTC seccomp: use a static inline for a function stub Fixes this error message when CONFIG_SECCOMP is not set: arch/powerpc/kernel/ptrace.c: In function 'do_syscall_trace_enter': arch/powerpc/kernel/ptrace.c:1713:2: error: statement with no effect [-Werror=unused-value] Signed-off-by: Stephen Rothwell <sfr@ozlabs.au.ibm.com> Signed-off-by: James Morris <james.l.morris@oracle.com> 17 September 2014, 20:43:10 UTC
3e5a21d Will Drewry 10 January 2012, 20:42:59 UTC Documentation: prctl/seccomp_filter Documents how system call filtering using Berkeley Packet Filter programs works and how it may be used. Includes an example for x86 and a semi-generic example using a macro-based code generator. Acked-by: Eric Paris <eparis@redhat.com> Signed-off-by: Will Drewry <wad@chromium.org> v18: - added acked by - update no new privs numbers v17: - remove @compat note and add Pitfalls section for arch checking (keescook@chromium.org) v16: - v15: - v14: - rebase/nochanges v13: - rebase on to 88ebdda6159ffc15699f204c33feb3e431bf9bdc v12: - comment on the ptrace_event use - update arch support comment - note the behavior of SECCOMP_RET_DATA when there are multiple filters (keescook@chromium.org) - lots of samples/ clean up incl 64-bit bpf-direct support (markus@chromium.org) - rebase to linux-next v11: - overhaul return value language, updates (keescook@chromium.org) - comment on do_exit(SIGSYS) v10: - update for SIGSYS - update for new seccomp_data layout - update for ptrace option use v9: - updated bpf-direct.c for SIGILL v8: - add PR_SET_NO_NEW_PRIVS to the samples. v7: - updated for all the new stuff in v7: TRAP, TRACE - only talk about PR_SET_SECCOMP now - fixed bad JLE32 check (coreyb@linux.vnet.ibm.com) - adds dropper.c: a simple system call disabler v6: - tweak the language to note the requirement of PR_SET_NO_NEW_PRIVS being called prior to use. (luto@mit.edu) v5: - update sample to use system call arguments - adds a "fancy" example using a macro-based generator - cleaned up bpf in the sample - update docs to mention arguments - fix prctl value (eparis@redhat.com) - language cleanup (rdunlap@xenotime.net) v4: - update for no_new_privs use - minor tweaks v3: - call out BPF <-> Berkeley Packet Filter (rdunlap@xenotime.net) - document use of tentative always-unprivileged - guard sample compilation for i386 and x86_64 v2: - move code to samples (corbet@lwn.net) 17 September 2014, 20:43:10 UTC
d4f8f7e Sasha Levitskiy 13 November 2012, 18:14:51 UTC Change-Id: I7c9d49079d4e18390c2d520513a4afd55e6eaa3e 17 September 2014, 20:43:10 UTC
f33422b Will Drewry 09 February 2012, 18:08:39 UTC ptrace,seccomp: Add PTRACE_SECCOMP support This change adds support for a new ptrace option, PTRACE_O_TRACESECCOMP, and a new return value for seccomp BPF programs, SECCOMP_RET_TRACE. When a tracer specifies the PTRACE_O_TRACESECCOMP ptrace option, the tracer will be notified, via PTRACE_EVENT_SECCOMP, for any syscall that results in a BPF program returning SECCOMP_RET_TRACE. The 16-bit SECCOMP_RET_DATA mask of the BPF program return value will be passed as the ptrace_message and may be retrieved using PTRACE_GETEVENTMSG. If the subordinate process is not using seccomp filter, then no system call notifications will occur even if the option is specified. If there is no tracer with PTRACE_O_TRACESECCOMP when SECCOMP_RET_TRACE is returned, the system call will not be executed and an -ENOSYS errno will be returned to userspace. This change adds a dependency on the system call slow path. Any future efforts to use the system call fast path for seccomp filter will need to address this restriction. Signed-off-by: Will Drewry <wad@chromium.org> Acked-by: Eric Paris <eparis@redhat.com> v18: - rebase - comment fatal_signal check - acked-by - drop secure_computing_int comment v17: - ... v16: - update PT_TRACE_MASK to 0xbf4 so that STOP isn't clear on SETOPTIONS call (indan@nul.nu) [note PT_TRACE_MASK disappears in linux-next] v15: - add audit support for non-zero return codes - clean up style (indan@nul.nu) v14: - rebase/nochanges v13: - rebase on to 88ebdda6159ffc15699f204c33feb3e431bf9bdc (Brings back a change to ptrace.c and the masks.) v12: - rebase to linux-next - use ptrace_event and update arch/Kconfig to mention slow-path dependency - drop all tracehook changes and inclusion (oleg@redhat.com) v11: - invert the logic to just make it a PTRACE_SYSCALL accelerator (indan@nul.nu) v10: - moved to PTRACE_O_SECCOMP / PT_TRACE_SECCOMP v9: - n/a v8: - guarded PTRACE_SECCOMP use with an ifdef v7: - introduced 17 September 2014, 20:43:10 UTC
4c4e7da Will Drewry 09 February 2012, 18:01:37 UTC seccomp: Add SECCOMP_RET_TRAP Adds a new return value to seccomp filters that triggers a SIGSYS to be delivered with the new SYS_SECCOMP si_code. This allows in-process system call emulation, including just specifying an errno or cleanly dumping core, rather than just dying. Suggested-by: Markus Gutschke <markus@chromium.org> Suggested-by: Julien Tinnes <jln@chromium.org> Signed-off-by: Will Drewry <wad@chromium.org> Acked-by: Eric Paris <eparis@redhat.com> v18: - acked-by, rebase - don't mention secure_computing_int() anymore v15: - use audit_seccomp/skip - pad out error spacing; clean up switch (indan@nul.nu) v14: - n/a v13: - rebase on to 88ebdda6159ffc15699f204c33feb3e431bf9bdc v12: - rebase on to linux-next v11: - clarify the comment (indan@nul.nu) - s/sigtrap/sigsys v10: - use SIGSYS, syscall_get_arch, updates arch/Kconfig note suggested-by (though original suggestion had other behaviors) v9: - changes to SIGILL v8: - clean up based on changes to dependent patches v7: - introduction 17 September 2014, 20:43:09 UTC
ac119cb Will Drewry 17 February 2012, 17:50:27 UTC signal, x86: add SIGSYS info and make it synchronous. This change enables SIGSYS, defines _sigfields._sigsys, and adds x86 (compat) arch support. _sigsys defines fields which allow a signal handler to receive the triggering system call number, the relevant AUDIT_ARCH_* value for that number, and the address of the callsite. SIGSYS is added to the SYNCHRONOUS_MASK because it is desirable for it to have setup_frame() called for it. The goal is to ensure that ucontext_t reflects the machine state from the time-of-syscall and not from another signal handler. The first consumer of SIGSYS would be seccomp filter. In particular, a filter program could specify a new return value, SECCOMP_RET_TRAP, which would result in the system call being denied and the calling thread signaled. This also means that implementing arch-specific support can be dependent upon HAVE_ARCH_SECCOMP_FILTER. Suggested-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Will Drewry <wad@chromium.org> Acked-by: Serge Hallyn <serge.hallyn@canonical.com> Reviewed-by: H. Peter Anvin <hpa@zytor.com> Acked-by: Eric Paris <eparis@redhat.com> v18: - added acked by, rebase v17: - rebase and reviewed-by addition v14: - rebase/nochanges v13: - rebase on to 88ebdda6159ffc15699f204c33feb3e431bf9bdc v12: - reworded changelog (oleg@redhat.com) v11: - fix dropped words in the change description - added fallback copy_siginfo support. - added __ARCH_SIGSYS define to allow stepped arch support. v10: - first version based on suggestion 17 September 2014, 20:43:09 UTC
4aa8c42 Will Drewry 16 February 2012, 02:45:54 UTC seccomp: add SECCOMP_RET_ERRNO This change adds the SECCOMP_RET_ERRNO as a valid return value from a seccomp filter. Additionally, it makes the first use of the lower 16-bits for storing a filter-supplied errno. 16-bits is more than enough for the errno-base.h calls. Returning errors instead of immediately terminating processes that violate seccomp policy allow for broader use of this functionality for kernel attack surface reduction. For example, a linux container could maintain a whitelist of pre-existing system calls but drop all new ones with errnos. This would keep a logically static attack surface while providing errnos that may allow for graceful failure without the downside of do_exit() on a bad call. This change also changes the signature of __secure_computing. It appears the only direct caller is the arm entry code and it clobbers any possible return value (register) immediately. Signed-off-by: Will Drewry <wad@chromium.org> Acked-by: Serge Hallyn <serge.hallyn@canonical.com> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Eric Paris <eparis@redhat.com> v18: - fix up comments and rebase - fix bad var name which was fixed in later revs - remove _int() and just change the __secure_computing signature v16-v17: ... v15: - use audit_seccomp and add a skip label. (eparis@redhat.com) - clean up and pad out return codes (indan@nul.nu) v14: - no change/rebase v13: - rebase on to 88ebdda6159ffc15699f204c33feb3e431bf9bdc v12: - move to WARN_ON if filter is NULL (oleg@redhat.com, luto@mit.edu, keescook@chromium.org) - return immediately for filter==NULL (keescook@chromium.org) - change evaluation to only compare the ACTION so that layered errnos don't result in the lowest one being returned. (keeschook@chromium.org) v11: - check for NULL filter (keescook@chromium.org) v10: - change loaders to fn v9: - n/a v8: - update Kconfig to note new need for syscall_set_return_value. - reordered such that TRAP behavior follows on later. - made the for loop a little less indent-y v7: - introduced 17 September 2014, 20:43:09 UTC
6879398 Kees Cook 26 February 2012, 19:56:12 UTC seccomp: remove duplicated failure logging This consolidates the seccomp filter error logging path and adds more details to the audit log. Signed-off-by: Will Drewry <wad@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Eric Paris <eparis@redhat.com> v18: make compat= permanent in the record v15: added a return code to the audit_seccomp path by wad@chromium.org (suggested by eparis@redhat.com) v*: original by keescook@chromium.org 17 September 2014, 20:43:09 UTC
c67baf9 Will Drewry 09 February 2012, 17:50:58 UTC seccomp: add system call filtering using BPF [This patch depends on luto@mit.edu's no_new_privs patch: https://lkml.org/lkml/2012/1/30/264 The whole series including Andrew's patches can be found here: https://github.com/redpig/linux/tree/seccomp Complete diff here: https://github.com/redpig/linux/compare/1dc65fed...seccomp ] This patch adds support for seccomp mode 2. Mode 2 introduces the ability for unprivileged processes to install system call filtering policy expressed in terms of a Berkeley Packet Filter (BPF) program. This program will be evaluated in the kernel for each system call the task makes and computes a result based on data in the format of struct seccomp_data. A filter program may be installed by calling: struct sock_fprog fprog = { ... }; ... prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &fprog); The return value of the filter program determines if the system call is allowed to proceed or denied. If the first filter program installed allows prctl(2) calls, then the above call may be made repeatedly by a task to further reduce its access to the kernel. All attached programs must be evaluated before a system call will be allowed to proceed. Filter programs will be inherited across fork/clone and execve. However, if the task attaching the filter is unprivileged (!CAP_SYS_ADMIN) the no_new_privs bit will be set on the task. This ensures that unprivileged tasks cannot attach filters that affect privileged tasks (e.g., setuid binary). There are a number of benefits to this approach. A few of which are as follows: - BPF has been exposed to userland for a long time - BPF optimization (and JIT'ing) are well understood - Userland already knows its ABI: system call numbers and desired arguments - No time-of-check-time-of-use vulnerable data accesses are possible. - system call arguments are loaded on access only to minimize copying required for system call policy decisions. Mode 2 support is restricted to architectures that enable HAVE_ARCH_SECCOMP_FILTER. In this patch, the primary dependency is on syscall_get_arguments(). The full desired scope of this feature will add a few minor additional requirements expressed later in this series. Based on discussion, SECCOMP_RET_ERRNO and SECCOMP_RET_TRACE seem to be the desired additional functionality. No architectures are enabled in this patch. Signed-off-by: Will Drewry <wad@chromium.org> Acked-by: Serge Hallyn <serge.hallyn@canonical.com> Reviewed-by: Indan Zupancic <indan@nul.nu> Acked-by: Eric Paris <eparis@redhat.com> v18: - rebase to v3.4-rc2 - s/chk/check/ (akpm@linux-foundation.org,jmorris@namei.org) - allocate with GFP_KERNEL|__GFP_NOWARN (indan@nul.nu) - add a comment for get_u32 regarding endianness (akpm@) - fix other typos, style mistakes (akpm@) - added acked-by v17: - properly guard seccomp filter needed headers (leann@ubuntu.com) - tighten return mask to 0x7fff0000 v16: - no change v15: - add a 4 instr penalty when counting a path to account for seccomp_filter size (indan@nul.nu) - drop the max insns to 256KB (indan@nul.nu) - return ENOMEM if the max insns limit has been hit (indan@nul.nu) - move IP checks after args (indan@nul.nu) - drop !user_filter check (indan@nul.nu) - only allow explicit bpf codes (indan@nul.nu) - exit_code -> exit_sig v14: - put/get_seccomp_filter takes struct task_struct (indan@nul.nu,keescook@chromium.org) - adds seccomp_chk_filter and drops general bpf_run/chk_filter user - add seccomp_bpf_load for use by net/core/filter.c - lower max per-process/per-hierarchy: 1MB - moved nnp/capability check prior to allocation (all of the above: indan@nul.nu) v13: - rebase on to 88ebdda6159ffc15699f204c33feb3e431bf9bdc v12: - added a maximum instruction count per path (indan@nul.nu,oleg@redhat.com) - removed copy_seccomp (keescook@chromium.org,indan@nul.nu) - reworded the prctl_set_seccomp comment (indan@nul.nu) v11: - reorder struct seccomp_data to allow future args expansion (hpa@zytor.com) - style clean up, @compat dropped, compat_sock_fprog32 (indan@nul.nu) - do_exit(SIGSYS) (keescook@chromium.org, luto@mit.edu) - pare down Kconfig doc reference. - extra comment clean up v10: - seccomp_data has changed again to be more aesthetically pleasing (hpa@zytor.com) - calling convention is noted in a new u32 field using syscall_get_arch. This allows for cross-calling convention tasks to use seccomp filters. (hpa@zytor.com) - lots of clean up (thanks, Indan!) v9: - n/a v8: - use bpf_chk_filter, bpf_run_filter. update load_fns - Lots of fixes courtesy of indan@nul.nu: -- fix up load behavior, compat fixups, and merge alloc code, -- renamed pc and dropped __packed, use bool compat. -- Added a hidden CONFIG_SECCOMP_FILTER to synthesize non-arch dependencies v7: (massive overhaul thanks to Indan, others) - added CONFIG_HAVE_ARCH_SECCOMP_FILTER - merged into seccomp.c - minimal seccomp_filter.h - no config option (part of seccomp) - no new prctl - doesn't break seccomp on systems without asm/syscall.h (works but arg access always fails) - dropped seccomp_init_task, extra free functions, ... - dropped the no-asm/syscall.h code paths - merges with network sk_run_filter and sk_chk_filter v6: - fix memory leak on attach compat check failure - require no_new_privs || CAP_SYS_ADMIN prior to filter installation. (luto@mit.edu) - s/seccomp_struct_/seccomp_/ for macros/functions (amwang@redhat.com) - cleaned up Kconfig (amwang@redhat.com) - on block, note if the call was compat (so the # means something) v5: - uses syscall_get_arguments (indan@nul.nu,oleg@redhat.com, mcgrathr@chromium.org) - uses union-based arg storage with hi/lo struct to handle endianness. Compromises between the two alternate proposals to minimize extra arg shuffling and account for endianness assuming userspace uses offsetof(). (mcgrathr@chromium.org, indan@nul.nu) - update Kconfig description - add include/seccomp_filter.h and add its installation - (naive) on-demand syscall argument loading - drop seccomp_t (eparis@redhat.com) v4: - adjusted prctl to make room for PR_[SG]ET_NO_NEW_PRIVS - now uses current->no_new_privs (luto@mit.edu,torvalds@linux-foundation.com) - assign names to seccomp modes (rdunlap@xenotime.net) - fix style issues (rdunlap@xenotime.net) - reworded Kconfig entry (rdunlap@xenotime.net) v3: - macros to inline (oleg@redhat.com) - init_task behavior fixed (oleg@redhat.com) - drop creator entry and extra NULL check (oleg@redhat.com) - alloc returns -EINVAL on bad sizing (serge.hallyn@canonical.com) - adds tentative use of "always_unprivileged" as per torvalds@linux-foundation.org and luto@mit.edu v2: - (patch 2 only) 17 September 2014, 20:43:09 UTC
51db3fa Will Drewry 18 January 2012, 21:00:56 UTC arch/x86: add syscall_get_arch to syscall.h Add syscall_get_arch() to export the current AUDIT_ARCH_* based on system call entry path. Signed-off-by: Will Drewry <wad@chromium.org> Acked-by: Serge Hallyn <serge.hallyn@canonical.com> Reviewed-by: H. Peter Anvin <hpa@zytor.com> Acked-by: Eric Paris <eparis@redhat.com> v18: - update comment about x32 tasks - rebase to v3.4-rc2 v17: rebase and reviewed-by v14: rebase/nochanges v13: rebase on to 88ebdda6159ffc15699f204c33feb3e431bf9bdc 17 September 2014, 20:43:08 UTC
ee6b389 Will Drewry 17 February 2012, 21:03:37 UTC asm/syscall.h: add syscall_get_arch Adds a stub for a function that will return the AUDIT_ARCH_* value appropriate to the supplied task based on the system call convention. For audit's use, the value can generally be hard-coded at the audit-site. However, for other functionality not inlined into syscall entry/exit, this makes that information available. seccomp_filter is the first planned consumer and, as such, the comment indicates a tie to CONFIG_HAVE_ARCH_SECCOMP_FILTER. Suggested-by: Roland McGrath <mcgrathr@chromium.org> Signed-off-by: Will Drewry <wad@chromium.org> Acked-by: Serge Hallyn <serge.hallyn@canonical.com> Acked-by: Eric Paris <eparis@redhat.com> v18: comment and change reword and rebase. v14: rebase/nochanges v13: rebase on to 88ebdda6159ffc15699f204c33feb3e431bf9bdc v12: rebase on to linux-next v11: fixed improper return type v10: introduced 17 September 2014, 20:43:08 UTC
back to top