) #2
Open
) #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Paul Reioux <[email protected]>
This is first official GPL release based on my private implementation. This release has been tested for xperia Z officially. It may work with other devices using the same WCD9320 Audio Codec as well, but not tested Signed-off-by: Paul Reioux <[email protected]>
Signed-off-by: Paul Reioux <[email protected]>
(Use this only for devices with audio reset issues) Also bump version to 3.1 Signed-off-by: Paul Reioux <[email protected]> wcd9xxx-core: add register write without mutex protection This is assuming the calling function will take care of the mutex. Signed-off-by: Paul Reioux <[email protected]>
Signed-off-by: Paul Reioux <[email protected]>
bump to version 3.2 Signed-off-by: Paul Reioux <[email protected]> Conflicts: sound/soc/codecs/wcd9320.c
Signed-off-by: Paul Reioux <[email protected]>
bump driver version to 3.3 Signed-off-by: Paul Reioux <[email protected]>
Bump driver version to 3.4 Change-Id: Idaf374634368e61ba1fc9e24d0c5e1a994271400 Signed-off-by: Paul Reioux <[email protected]>
Signed-off-by: Paul Reioux <[email protected]>
with newer hardware revisions coming from Qualcomm, single register lock control isn't sufficient to cover both playback and recording usage scenarios bump to version 3.5 Signed-off-by: Paul Reioux <[email protected]>
bump version to 3.6 Signed-off-by: Paul Reioux <[email protected]>
Conflicts: drivers/video/msm/mdss/Kconfig drivers/video/msm/mdss/Makefile drivers/video/msm/mdss/mdss_mdp_pp.c Conflicts: drivers/video/msm/mdss/Makefile drivers/video/msm/mdss/mdss_mdp_pp.c Conflicts: drivers/video/msm/mdss/mdss_mdp_pp.c Change-Id: I26a50aa6bfac69a6f5c8556f38ad9b6ba001374f
Conflicts: drivers/video/msm/mdss/mdss_mdp_pp.c Change-Id: Iaaf6b6392d42de3faf9e1e6c897047de07ff9ff6 Conflicts: drivers/video/msm/mdss/mdss_mdp_pp.c
Change-Id: I58189840163ca38f890954c57b247cf41ec22c13
Change-Id: I702935e2d379099eef3ff8afd4be5072b7412519 Signed-off-by: Saatvik Shukla <[email protected]>
Intellithermal 2.0 is based on the latest Qualcomm thermal driver adapted for in-kernel use and control. Newer MSM8974+ chipsets should use this driver going forward Signed-off-by: Paul Reioux <[email protected]> Conflicts: drivers/thermal/Kconfig drivers/thermal/Makefile include/linux/msm_thermal.h Conflicts: include/linux/msm_thermal.h
Signed-off-by: Paul Reioux <[email protected]>
Signed-off-by: Paul Reioux <[email protected]>
Signed-off-by: Paul Reioux <[email protected]>
Signed-off-by: Paul Reioux <[email protected]>
After half a year of repeating research, a 5min google search and the help of @oshmoun fixed it. Dear Makefile: Fuck You. Regards
Change-Id: I8c0fcb1e00d0789b47251434a13f8f7013636e0e
Signed-off-by: klozz <[email protected]>
Thanks to him for his work Conflicts: arch/arm/mach-msm/msm-sleeper.c arch/arm/mach-msm/msm_mpdecision.c Conflicts: arch/arm/configs/cm_shinano_sirius_defconfig Change-Id: Ia916bbca960fcfc52409e813431502325b3b3994
Change-Id: Id4d39bb3e8b9da418890725dd0833a562473ffff Conflicts: arch/arm/configs/cm_rhine_togari_row_defconfig
Conflicts: arch/arm/configs/z1_defconfig arch/arm/configs/z1c_defconfig Change-Id: Idec891a3406d96e1eb9b5502f102586deffab3ce
If a user key gets negatively instantiated, an error code is cached in the
payload area. A negatively instantiated key may be then be positively
instantiated by updating it with valid data. However, the ->update key
type method must be aware that the error code may be there.
The following may be used to trigger the bug in the user key type:
keyctl request2 user user "" @U
keyctl add user user "a" @U
which manifests itself as:
BUG: unable to handle kernel paging request at 00000000ffffff8a
IP: [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046
PGD 7cc30067 PUD 0
Oops: 0002 [AOSPA-L#1] SMP
Modules linked in:
CPU: 3 PID: 2644 Comm: a.out Not tainted 4.3.0+ #49
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88003ddea700 ti: ffff88003dd88000 task.ti: ffff88003dd88000
RIP: 0010:[<ffffffff810a376f>] [<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280
[<ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046
RSP: 0018:ffff88003dd8bdb0 EFLAGS: 00010246
RAX: 00000000ffffff82 RBX: 0000000000000000 RCX: 0000000000000001
RDX: ffffffff81e3fe40 RSI: 0000000000000000 RDI: 00000000ffffff82
RBP: ffff88003dd8bde0 R08: ffff88007d2d2da0 R09: 0000000000000000
R10: 0000000000000000 R11: ffff88003e8073c0 R12: 00000000ffffff82
R13: ffff88003dd8be68 R14: ffff88007d027600 R15: ffff88003ddea700
FS: 0000000000b92880(0063) GS:ffff88007fd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000ffffff8a CR3: 000000007cc5f000 CR4: 00000000000006e0
Stack:
ffff88003dd8bdf0 ffffffff81160a8a 0000000000000000 00000000ffffff82
ffff88003dd8be68 ffff88007d027600 ffff88003dd8bdf0 ffffffff810a39e5
ffff88003dd8be20 ffffffff812a31ab ffff88007d027600 ffff88007d027620
Call Trace:
[<ffffffff810a39e5>] kfree_call_rcu+0x15/0x20 kernel/rcu/tree.c:3136
[<ffffffff812a31ab>] user_update+0x8b/0xb0 security/keys/user_defined.c:129
[< inline >] __key_update security/keys/key.c:730
[<ffffffff8129e5c1>] key_create_or_update+0x291/0x440 security/keys/key.c:908
[< inline >] SYSC_add_key security/keys/keyctl.c:125
[<ffffffff8129fc21>] SyS_add_key+0x101/0x1e0 security/keys/keyctl.c:60
[<ffffffff8185f617>] entry_SYSCALL_64_fastpath+0x12/0x6a arch/x86/entry/entry_64.S:185
Note the error code (-ENOKEY) in EDX.
A similar bug can be tripped by:
keyctl request2 trusted user "" @U
keyctl add trusted user "a" @U
This should also affect encrypted keys - but that has to be correctly
parameterised or it will fail with EINVAL before getting to the bit that
will crashes.
Change-Id: I171d566f431c56208e1fe279f466d2d399a9ac7c
Reported-by: Dmitry Vyukov <[email protected]>
Signed-off-by: David Howells <[email protected]>
Acked-by: Mimi Zohar <[email protected]>
Signed-off-by: James Morris <[email protected]>
Currently we don't check if the new MTU is valid or not and this allows one to configure a smaller than minimum allowed by RFCs or even bigger than interface own MTU, which is a problem as it may lead to packet drops. If you have a daemon like NetworkManager running, this may be exploited by remote attackers by forging RA packets with an invalid MTU, possibly leading to a DoS. (NetworkManager currently only validates for values too small, but not for too big ones.) The fix is just to make sure the new value is valid. That is, between IPV6_MIN_MTU and interface's MTU. Note that similar check is already performed at ndisc_router_discovery(), for when kernel itself parses the RA. Change-Id: I6b70d0c12a77c7932066982f8797d8024f130d7c Signed-off-by: Marcelo Ricardo Leitner <[email protected]> Signed-off-by: Sabrina Dubroca <[email protected]> Signed-off-by: David S. Miller <[email protected]>
A userspace call to mmap(MAP_LOCKED) may result in the successful locking of memory while also producing a confusing audit log denial. can_do_mlock checks capable and rlimit. If either of these return positive can_do_mlock returns true. The capable check leads to an LSM hook used by apparmour and selinux which produce the audit denial. Reordering so rlimit is checked first eliminates the denial on success, only recording a denial when the lock is unsuccessful as a result of the denial. Change-Id: I8d300365c8f85b002d6c5375a22abfb1b7579d20 Signed-off-by: Jeff Vander Stoep <[email protected]> Acked-by: Nick Kralevich <[email protected]> Cc: Jeff Vander Stoep <[email protected]> Cc: Sasha Levin <[email protected]> Cc: "Paul E. McKenney" <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Paul Cassella <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
commit 910ffdb upstream. Cleanup and preparation for the next change. signal_wake_up(resume => true) is overused. None of ptrace/jctl callers actually want to wakeup a TASK_WAKEKILL task, but they can't specify the necessary mask. Turn signal_wake_up() into signal_wake_up_state(state), reintroduce signal_wake_up() as a trivial helper, and add ptrace_signal_wake_up() which adds __TASK_TRACED. This way ptrace_signal_wake_up() can work "inside" ptrace_request() even if the tracee doesn't have the TASK_WAKEKILL bit set. Signed-off-by: Oleg Nesterov <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 9899d11 upstream. putreg() assumes that the tracee is not running and pt_regs_access() can safely play with its stack. However a killed tracee can return from ptrace_stop() to the low-level asm code and do RESTORE_REST, this means that debugger can actually read/modify the kernel stack until the tracee does SAVE_REST again. set_task_blockstep() can race with SIGKILL too and in some sense this race is even worse, the very fact the tracee can be woken up breaks the logic. As Linus suggested we can clear TASK_WAKEKILL around the arch_ptrace() call, this ensures that nobody can ever wakeup the tracee while the debugger looks at it. Not only this fixes the mentioned problems, we can do some cleanups/simplifications in arch_ptrace() paths. Probably ptrace_unfreeze_traced() needs more callers, for example it makes sense to make the tracee killable for oom-killer before access_process_vm(). While at it, add the comment into may_ptrace_stop() to explain why ptrace_stop() still can't rely on SIGKILL and signal_pending_state(). Reported-by: Salman Qazi <[email protected]> Reported-by: Suleiman Souhlal <[email protected]> Suggested-by: Linus Torvalds <[email protected]> Signed-off-by: Oleg Nesterov <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 73af963 upstream. __ptrace_may_access() checks get_dumpable/ptrace_has_cap/etc if task != current, this can can lead to surprising results. For example, a sub-thread can't readlink("/proc/self/exe") if the executable is not readable. setup_new_exec()->would_dump() notices that inode_permission(MAY_READ) fails and then it does set_dumpable(suid_dumpable). After that get_dumpable() fails. (It is not clear why proc_pid_readlink() checks get_dumpable(), perhaps we could add PTRACE_MODE_NODUMPABLE) Change __ptrace_may_access() to use same_thread_group() instead of "task == current". Any security check is pointless when the tasks share the same ->mm. Change-Id: Ib6ca927a1eb0637df8030aabcb3129d5be343512 Signed-off-by: Mark Grondona <[email protected]> Signed-off-by: Ben Woodard <[email protected]> Signed-off-by: Oleg Nesterov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit ab676b7d6fbf4b294bf198fb27ade5b0e865c7ce upstream. As pointed by recent post[1] on exploiting DRAM physical imperfection, /proc/PID/pagemap exposes sensitive information which can be used to do attacks. This disallows anybody without CAP_SYS_ADMIN to read the pagemap. [1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html [ Eventually we might want to do anything more finegrained, but for now this is the simple model. - Linus ] Change-Id: Ib62bf4429dcdafd9fc1cd9b1a0c5665c64cc5d18 Signed-off-by: Kirill A. Shutemov <[email protected]> Acked-by: Konstantin Khlebnikov <[email protected]> Acked-by: Andy Lutomirski <[email protected]> Cc: Pavel Emelyanov <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Mark Seaborn <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Zefan Li <[email protected]> [mancha: Backported to 3.10] Signed-off-by: mancha security <[email protected]>
On multi core system, in below path, synchronization issue can happen. tcp_set_state() should be used only on locked socket, tcp_close access with proper lock, where as tcp_done is accessing without any lock on socket. bh_lock_sock just grabs the lock and not compete/spins for the lock. This is recommended to be used from BH. tcp_nuke_addr will be always called either from init function or via icotl call and never called from bottom half, hence lock_sock is the better approach. tcp_done need to be called with bh_disable to avoid sync issue within core Panic Signature: PC is at inet_put_port+0x7c/0xac LR is at arch_timer_read_current_timer+0x14/0x18 Synchrnoization Issue explaind in CR Core-0 Core-1 ------ ------- release_sock tcp_close inet_put_port inet_release tcp_set_state sock_release tcp_done sock_close tcp_nuke_addr fput devinet_ioctl filp_close sock_ioctl Change-Id: I6ededf1245e8ca46ad06b7135af96959a88fef62 Signed-off-by: Vijayakumar Gn <[email protected]> Reviewed-on: http://gerrit.mot.com/719443 SLTApproved: Slta Waiver <[email protected]> Tested-by: Jira Key <[email protected]> Reviewed-by: Jeffrey Carlyle <[email protected]> Submit-Approved: Jira Key <[email protected]> Reviewed-by: Sudharsan Yettapu <[email protected]>
The actual size of the tcp hashinfo table is tcp_hashinfo.ehash_mask + 1 so we need to adjust the loop accordingly to get the sockets hashed into the last bucket. Change-Id: I796b3c7b4a1a7fa35fba9e5192a4a403eb6e17de Signed-off-by: Dmitry Torokhov <[email protected]>
Make the keys garbage collector invoke synchronize_rcu() prior to destroying keys with a zero usage count. This means that a key can be examined under the RCU read lock in the safe knowledge that it won't get deallocated until after the lock is released - even if its usage count becomes zero whilst we're looking at it. This is useful in keyring search vs key link. Consider a keyring containing a link to a key. That link can be replaced in-place in the keyring without requiring an RCU copy-and-replace on the keyring contents without breaking a search underway on that keyring when the displaced key is released, provided the key is actually destroyed only after the RCU read lock held by the search algorithm is released. This permits __key_link() to replace a key without having to reallocate the key payload. A key gets replaced if a new key being linked into a keyring has the same type and description. Signed-off-by: David Howells <[email protected]> Acked-by: Jeff Layton <[email protected]> Conflicts: security/keys/gc.c Change-Id: Ifd8549b5b906c638d63c358ce1f34acd81139207
Make use of the previous patch that makes the garbage collector perform RCU synchronisation before destroying defunct keys. Key pointers can now be replaced in-place without creating a new keyring payload and replacing the whole thing as the discarded keys will not be destroyed until all currently held RCU read locks are released. If the keyring payload space needs to be expanded or contracted, then a replacement will still need allocating, and the original will still have to be freed by RCU. Change-Id: I6c4f784f120951fb51ac9c23856ea37f51770bb9 Signed-off-by: David Howells <[email protected]>
Add support for invalidating a key - which renders it immediately invisible to further searches and causes the garbage collector to immediately wake up, remove it from keyrings and then destroy it when it's no longer referenced. It's better not to do this with keyctl_revoke() as that marks the key to start returning -EKEYREVOKED to searches when what is actually desired is to have the key refetched. To invalidate a key the caller must be granted SEARCH permission by the key. This may be too strict. It may be better to also permit invalidation if the caller has any of READ, WRITE or SETATTR permission. The primary use for this is to evict keys that are cached in special keyrings, such as the DNS resolver or an ID mapper. Change-Id: I923ea0f0b8f9d6b3ff8ec8beca77b1774984f1c3 Signed-off-by: David Howells <[email protected]>
There appears to be a race between:
(1) key_gc_unused_keys() which frees key->security and then calls
keyring_destroy() to unlink the name from the name list
(2) find_keyring_by_name() which calls key_permission(), thus accessing
key->security, on a key before checking to see whether the key usage is 0
(ie. the key is dead and might be cleaned up).
Fix this by calling ->destroy() before cleaning up the core key data -
including key->security.
Change-Id: I4b9b89af020e6348af095e9014bf23b5eb1a9ef9
Reported-by: Petr Matousek <[email protected]>
Signed-off-by: David Howells <[email protected]>
…ring
The following sequence of commands:
i=`keyctl add user a a @s`
keyctl request2 keyring foo bar @t
keyctl unlink $i @s
tries to invoke an upcall to instantiate a keyring if one doesn't already
exist by that name within the user's keyring set. However, if the upcall
fails, the code sets keyring->type_data.reject_error to -ENOKEY or some
other error code. When the key is garbage collected, the key destroy
function is called unconditionally and keyring_destroy() uses list_empty()
on keyring->type_data.link - which is in a union with reject_error.
Subsequently, the kernel tries to unlink the keyring from the keyring names
list - which oopses like this:
BUG: unable to handle kernel paging request at 00000000ffffff8a
IP: [<ffffffff8126e051>] keyring_destroy+0x3d/0x88
...
Workqueue: events key_garbage_collector
...
RIP: 0010:[<ffffffff8126e051>] keyring_destroy+0x3d/0x88
RSP: 0018:ffff88003e2f3d30 EFLAGS: 00010203
RAX: 00000000ffffff82 RBX: ffff88003bf1a900 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 000000003bfc6901 RDI: ffffffff81a73a40
RBP: ffff88003e2f3d38 R08: 0000000000000152 R09: 0000000000000000
R10: ffff88003e2f3c18 R11: 000000000000865b R12: ffff88003bf1a900
R13: 0000000000000000 R14: ffff88003bf1a908 R15: ffff88003e2f4000
...
CR2: 00000000ffffff8a CR3: 000000003e3ec000 CR4: 00000000000006f0
...
Call Trace:
[<ffffffff8126c756>] key_gc_unused_keys.constprop.1+0x5d/0x10f
[<ffffffff8126ca71>] key_garbage_collector+0x1fa/0x351
[<ffffffff8105ec9b>] process_one_work+0x28e/0x547
[<ffffffff8105fd17>] worker_thread+0x26e/0x361
[<ffffffff8105faa9>] ? rescuer_thread+0x2a8/0x2a8
[<ffffffff810648ad>] kthread+0xf3/0xfb
[<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2
[<ffffffff815f2ccf>] ret_from_fork+0x3f/0x70
[<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2
Note the value in RAX. This is a 32-bit representation of -ENOKEY.
The solution is to only call ->destroy() if the key was successfully
instantiated.
Change-Id: Ia52370813b7e8231fdd99d2a208340af1c7b4007
Reported-by: Dmitry Vyukov <[email protected]>
Signed-off-by: David Howells <[email protected]>
Tested-by: Dmitry Vyukov <[email protected]>
[ Upstream commit 1485348 ] Cache the device gso_max_segs in sock::sk_gso_max_segs and use it to limit the size of TSO skbs. This avoids the need to fall back to software GSO for local TCP senders. Signed-off-by: Ben Hutchings <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
[ Upstream commit dec34fb ] When SOCK_REFCNT_DEBUG is enabled, below build error is met: kernel/sysctl_binary.o: In function `sk_refcnt_debug_release': include/net/sock.h:1025: multiple definition of `sk_refcnt_debug_release' kernel/sysctl.o:include/net/sock.h:1025: first defined here kernel/audit.o: In function `sk_refcnt_debug_release': include/net/sock.h:1025: multiple definition of `sk_refcnt_debug_release' kernel/sysctl.o:include/net/sock.h:1025: first defined here make[1]: *** [kernel/built-in.o] Error 1 make: *** [kernel] Error 2 So we decide to make sk_refcnt_debug_release static to eliminate the error. Signed-off-by: Ying Xue <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
郭永刚 reported that one could simply crash the kernel as root by using a simple program: int socket_fd; struct sockaddr_in addr; addr.sin_port = 0; addr.sin_addr.s_addr = INADDR_ANY; addr.sin_family = 10; socket_fd = socket(10,3,0x40000000); connect(socket_fd , &addr,16); AF_INET, AF_INET6 sockets actually only support 8-bit protocol identifiers. inet_sock's skc_protocol field thus is sized accordingly, thus larger protocol identifiers simply cut off the higher bits and store a zero in the protocol fields. This could lead to e.g. NULL function pointer because as a result of the cut off inet_num is zero and we call down to inet_autobind, which is NULL for raw sockets. kernel: Call Trace: kernel: [<ffffffff816db90e>] ? inet_autobind+0x2e/0x70 kernel: [<ffffffff816db9a4>] inet_dgram_connect+0x54/0x80 kernel: [<ffffffff81645069>] SYSC_connect+0xd9/0x110 kernel: [<ffffffff810ac51b>] ? ptrace_notify+0x5b/0x80 kernel: [<ffffffff810236d8>] ? syscall_trace_enter_phase2+0x108/0x200 kernel: [<ffffffff81645e0e>] SyS_connect+0xe/0x10 kernel: [<ffffffff81779515>] tracesys_phase2+0x84/0x89 I found no particular commit which introduced this problem. Change-Id: I653fad90da54908144cc8916c2dccb1fa6f14eed CVE: CVE-2015-8543 Cc: Cong Wang <[email protected]> Reported-by: 郭永刚 <[email protected]> Signed-off-by: Hannes Frederic Sowa <[email protected]> Signed-off-by: David S. Miller <[email protected]> (cherry picked from commit 716b539a12e21c1059ac43dee361fcd89e1d6c13)
Change-Id: I890640975f1af64f71947b6a1820249e08f6375b Signed-off-by: David S. Miller <[email protected]> (cherry picked from commit d0975b7d81105e1b07e4ae0334835792af3fff47)
commit 7e936b7 upstream. A hard-linked directory to its parent can cause the VFS to deadlock, and is a sign of a corrupted file system. So detect this case in ext4_lookup(), before the rmdir() lockup scenario can take place. Signed-off-by: Andreas Dilger <[email protected]> Signed-off-by: "Theodore Ts'o" <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 6a08f44 upstream. ext4_special_inode_operations have their own ifdef CONFIG_EXT4_FS_XATTR to mask those methods. And ext4_iget also always sets it, so there is an inconsistency. Signed-off-by: Bernd Schubert <[email protected]> Signed-off-by: "Theodore Ts'o" <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Add case-insensitive name lookup support. Change-Id: I526d5e12a860d77878de4bc2d1d9c24d67ca9ce4 Signed-off-by: Russ Knize <[email protected]> Reviewed-on: http://gerrit.mot.com/638188 Tested-by: Jira Key <[email protected]> Reviewed-by: Igor Kovalenko <[email protected]> Submit-Approved: Jira Key <[email protected]> SLTApproved: Christopher Fries <[email protected]>
Instead of checking whether the handle is valid, we check if journal is enabled. This avoids taking the s_orphan_lock mutex in all cases when there is no journal in use, including the error paths where ext4_orphan_del() is called with a handle set to NULL. Signed-off-by: Anatol Pomozov <[email protected]> Signed-off-by: "Theodore Ts'o" <[email protected]> Conflicts: fs/ext4/namei.c Change-Id: I734ccb8069fceb12b864e7b9dceb37e27ab94c61 (cherry picked from commit d161fc0019a42fadedf851b4899872199c998cc2)
When trying to mount a file system which does not contain a journal, but which does have a orphan list containing an inode which needs to be truncated, the mount call with hang forever in ext4_orphan_cleanup() because ext4_orphan_del() will return immediately without removing the inode from the orphan list, leading to an uninterruptible loop in kernel code which will busy out one of the CPU's on the system. This can be trivially reproduced by trying to mount the file system found in tests/f_orphan_extents_inode/image.gz from the e2fsprogs source tree. If a malicious user were to put this on a USB stick, and mount it on a Linux desktop which has automatic mounts enabled, this could be considered a potential denial of service attack. (Not a big deal in practice, but professional paranoids worry about such things, and have even been known to allocate CVE numbers for such problems.) Change-Id: I743b57475420aec2b724c0ebc0288bbab3443e97 Signed-off-by: "Theodore Ts'o" <[email protected]> Reviewed-by: Zheng Liu <[email protected]> Cc: [email protected] (cherry picked from commit c37aed1feca886bd61ca864756e57d08466ab0e5)
commit e2bfb08 upstream. The boot loader inode (inode #5) should never be visible in the directory hierarchy, but it's possible if the file system is corrupted that there will be a directory entry that points at inode #5. In order to avoid accidentally trashing it, when such a directory inode is opened, the inode will be marked as a bad inode, so that it's not possible to modify (or read) the inode from userspace. Unfortunately, when we unlink this (invalid/illegal) directory entry, we will put the bad inode on the ophan list, and then when try to unlink the directory, we don't actually remove the bad inode from the orphan list before freeing in-memory inode structure. This means the in-memory orphan list is corrupted, leading to a kernel oops. In addition, avoid truncating a bad inode in ext4_destroy_inode(), since truncating the boot loader inode is not a smart thing to do. Reported-by: Sami Liedes <[email protected]> Reviewed-by: Jan Kara <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li <[email protected]> Conflicts: fs/ext4/namei.c Change-Id: Id47f65995ae98a76555d2fd6f8fcfaa43dbd31f5 (cherry picked from commit 5c84767f87c5994b5c470ce17f919bdbf116fdcf)
Add a new intent flag to let the driver know to perform a case- insensitive name lookup. Change-Id: I2c62e23c6ea0415372cd58295baad08c50099e74 Signed-off-by: Russ Knize <[email protected]> Reviewed-on: http://gerrit.mot.com/637406 Tested-by: Jira Key <[email protected]> Reviewed-by: Christopher Fries <[email protected]> SLTApproved: Christopher Fries <[email protected]> Submit-Approved: Jira Key <[email protected]>
[ Upstream commit 30b678d ] A peer (or local user) may cause TCP to use a nominal MSS of as little as 88 (actual MSS of 76 with timestamps). Given that we have a sufficiently prodigious local sender and the peer ACKs quickly enough, it is nevertheless possible to grow the window for such a connection to the point that we will try to send just under 64K at once. This results in a single skb that expands to 861 segments. In some drivers with TSO support, such an skb will require hundreds of DMA descriptors; a substantial fraction of a TX ring or even more than a full ring. The TX queue selected for the skb may stall and trigger the TX watchdog repeatedly (since the problem skb will be retried after the TX reset). This particularly affects sfc, for which the issue is designated as CVE-2012-3412. Therefore: 1. Add the field net_device::gso_max_segs holding the device-specific limit. 2. In netif_skb_features(), if the number of segments is too high then mask out GSO features to force fall back to software GSO. Signed-off-by: Ben Hutchings <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
[ Upstream commit c0de08d ] If a packet is emitted on one socket in one group of fanout sockets, it is transmitted again. It is thus read again on one of the sockets of the fanout group. This result in a loop for software which generate packets when receiving one. This retransmission is not the intended behavior: a fanout group must behave like a single socket. The packet should not be transmitted on a socket if it originates from a socket belonging to the same fanout group. This patch fixes the issue by changing the transmission check to take fanout group info account. Reported-by: Aleksandr Kotov <[email protected]> Signed-off-by: Eric Leblond <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
During rapid suspend/resume usecases assertive display is being turned on with backlight level zero. When on command is received with backlight level zero driver bails out with out turning on AD and doesn't signal the client that worker queue has stopped processing which results in a timeout for on command. Change will ensure that client is signalled if driver is skipping the processing of AD due to backlight being zero. Change-Id: Iaa6229f10ce54f44ec64c175f67ef7584ad4c8b2 Signed-off-by: Gopikrishnaiah Anandan <[email protected]> Signed-off-by: Raghavendra Ambadas <[email protected]>
Change-Id: I4029fba1ff4659219338a91871fedea7e664f8d2
cmd-detected panels were suffering of lcd-backlight registration issues: it was registering the backlight trigger on the first panel read for detection kickstart, then failing to re-register it on the real, detected panel (because of obvious reasons). Fix the issue by adding detection awareness for backlight LED trigger registration. Change-Id: Ib3e948c2a2154093342f13cb91a06229e618be45
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.