| Age | Commit message (Collapse) | Author |
|---|
|
|
|
patch a3474224e6a01924be40a8255636ea5522c1023a in mainline
The original meaning of the old test (p->state > TASK_STOPPED) was
"not dead", since it was before TASK_TRACED existed and before the
state/exit_state split. It was a wrong correction in commit
14bf01bb0599c89fc7f426d20353b76e12555308 to make this test for
TASK_TRACED instead. It should have been changed when TASK_TRACED
was introducted and again when exit_state was introduced.
Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
First reported at http://projects.info-pull.com/mokb/MOKB-17-11-2006.html
Essentially a corrupted minix dir inode reporting a very large
i_size will loop for a very long time in minix_readdir, minix_find_entry,
etc, because on EIO they just move on to try the next page. This is
under the BKL, printk-storming as well. This can lock up the machine
for a very long time. Simply ratelimiting the printks gets things back
under control. Make the message a bit more informative while we're here.
Adrian Bunk:
Backported to 2.6.16.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Believe it or not, but in fs/minix/*, the oldest filesystem in the kernel,
something still can be fixed:
printk("new_inode: bit already set");
"\n" is missing!
While at it, I also removed periods from the end of error messages and made
capitalization uniform. Also s/i-node/inode/, s/printk (/printk(/
Signed-off-by: Denis Vlasenko <vda@ilport.com.ua>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
(CVE-2008-0001)
patch 974a9f0b47da74e28f68b9c8645c3786aa5ace1a in mainline
Way back when (in commit 834f2a4a1554dc5b2598038b3fe8703defcbe467, aka
"VFS: Allow the filesystem to return a full file pointer on open intent"
to be exact), Trond changed the open logic to keep track of the original
flags to a file open, in order to pass down the the intent of a dentry
lookup to the low-level filesystem.
However, when doing that reorganization, it changed the meaning of
namei_flags, and thus inadvertently changed the test of access mode for
directories (and RO filesystem) to use the wrong flag. So fix those
test back to use access mode ("acc_mode") rather than the open flag
("flag").
Issue noticed by Bill Roman at Datalight.
Reported-and-tested-by: Bill Roman <bill.roman@datalight.com>
Acked-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
[ Upstream commit: f398035f2dec0a6150833b0bc105057953594edb ]
The aalgos/ealgos fields are only 32 bits wide. However, af_key tries
to test them with the expression 1 << id where id can be as large as
253. This produces different behaviour on different architectures.
The following patch explicitly checks whether ID is greater than 31
and fails the check if that's the case.
We cannot easily extend the mask to be longer than 32 bits due to
exposure to user-space. Besides, this whole interface is obsolete
anyway in favour of the xfrm_user interface which doesn't use this
bit mask in templates (well not within the kernel anyway).
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
[ Upstream commit: 9e8d6f8959c356d8294d45f11231331c3e1bcae6 ]
easy to trigger as user with sfuzz.
irda_create() is quiet on unknown sock->type,
match this behaviour for SOCK_DGRAM unknown protocol
Signed-off-by: Maximilian Attems <max@stro.at>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
[ Upstream commit: 44344b2a85f03326c7047a8c861b0c625c674839 ]
When re-naming an interface, the previous secondary address
labels get lost e.g.
$> brctl addbr foo
$> ip addr add 192.168.0.1 dev foo
$> ip addr add 192.168.0.2 dev foo label foo:00
$> ip addr show dev foo | grep inet
inet 192.168.0.1/32 scope global foo
inet 192.168.0.2/32 scope global foo:00
$> ip link set foo name bar
$> ip addr show dev bar | grep inet
inet 192.168.0.1/32 scope global bar
inet 192.168.0.2/32 scope global bar:2
Turns out to be a simple thinko in inetdev_changename() - clearly we
want to look at the address label, rather than the device name, for
a suffix to retain.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
[ Upstream commit: f844c74fe07321953e2dd227fe35280075f18f60 ]
We currently check that iph->ihl is bounded by the real length and that
the real length is greater than the minimum IP header length. However,
we did not check the caes where iph->ihl is less than the minimum IP
header length.
This breaks because some ip_fast_csum implementations assume that which
is quite reasonable.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
cn_queue_free_callback() will touch 'dev'(i.e. cbq->pdev),
so it should be called before atomic_dec(&dev->refcnt).
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Back in 2.6.12-pre, usb_start_wait_urb was switched over to take
milliseconds instead of jiffies. kaweth.c was never updated to match.
Signed-off-by: Russ Dill <Russ.Dill@asu.edu>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
[ Upsteam commit: 0de56d1ab83323d604d95ca193dcbd28388dbabb ]
We need to mask out the proper bits when testing the dispatch status
register else we can see unrelated NACK bits from previous cross call
sends.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
[ Upstream commit: d31c7b8fa303eb81311f27b80595b8d2cbeef950 ]
Avaid provided test application, so bug got fixed.
IPv6 addrconf removes ipv6 inner device from netdev each time cmu
changes and new value is less than IPV6_MIN_MTU (1280 bytes).
When mtu is changed and new value is greater than IPV6_MIN_MTU,
it does not add ipv6 addresses and inner device bac.
This patch fixes that.
Tested with Avaid's application, which works ok now.
Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
struct input_device_id mustn't be userspace visible since
it uses kernel_ulong_t.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
no-op as all dma_sync_... there.
Adrian Bunk:
Backported to 2.6.16.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
This patch cherry picks the following from
commit 9548b209a37397f3036aa5bd3d5b4d3b725aa1:
fix build failure with gcc-4.2.x: fix up casts in cia_io* routines to avoid
warnings ('discards qualifiers from pointer target type'), which are
failures, thanks to -Werror;
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
|
|
|
|
Actually there are several but one is trivially fixed
1. FSACTL_GET_NEXT_ADAPTER_FIB ioctl does not lock dev->fib_list
but needs to
2. Ditto for FSACTL_CLOSE_GET_ADAPTER_FIB
3. It is possible to construct an attack via the SRB ioctls where
the user obtains assorted elevated privileges. Various approaches are
possible, the trivial ones being things like writing to the raw media
via scsi commands and the swap image of other executing programs with
higher privileges.
So the ioctls should be CAP_SYS_RAWIO - at least all the FIB manipulating
ones. This is a bandaid fix for #3 but probably the ioctls should grow
their own capable checks. The other two bugs need someone competent in that
driver to fix them.
Signed-off-by: Alan Cox <alan@redhat.com>
Acked-by: Mark Salyzyn <mark_salyzyn@adaptec.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Missing parentheses in the definition of FAN_FROM_REG cause a
division by zero for a specific register value.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
A stupid bit shifting bug caused the VID value to be always exported
even when the hardware is configured for something different.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
[ Upstream commit: 435000bebd94aae3a7a50078d142d11683d3b193 ]
Kernel needs to respond to an SADB_GET with the same message type to
conform to the RFC 2367 Section 3.1.5
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
[ Upstream commit: 8a8037ac9dbe4eb20ce50aa20244faf77444f4a3 ]
if you are lucky (unlucky?) enough to have shared interrupts, the
interrupt handler can be called before the tasklet and lock are ready
for use.
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
tmpfs was misconverted to __GFP_ZERO in 2.6.11. There's an unusual case in
which shmem_getpage receives the page from its caller instead of allocating.
We must cover this case by clear_highpage before SetPageUptodate, as before.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
The #ifdef's in arp_process() were not only a mess, they were also wrong
in the CONFIG_NET_ETHERNET=n and (CONFIG_NETDEV_1000=y or
CONFIG_NETDEV_10000=y) cases.
Since they are not required this patch removes them.
Also removed are some #ifdef's around #include's that caused compile
errors after this change.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
[ Upstream commit: c3d8d1e30cace31fed6186a4b8c6b1401836d89c ]
Commit ed6dcf4a in the history.git tree broke netlink_unicast timeouts
by moving the schedule_timeout() call to a new function that doesn't
propagate the remaining timeout back to the caller. This means on each
retry we start with the full timeout again.
ipc/mqueue.c seems to actually want to wait indefinitely so this
behaviour is retained.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
This patch fixes a memory leak when a PPPoE socket is release()d after
it has been connect()ed, but before the PPPIOCGCHAN ioctl ever has been
called on it.
This is somewhat of a security problem, too, since PPPoE sockets can be
created by any user, so any user can easily allocate all the machine's
RAM to non-swappable address space and thus DoS the system.
Is there any specific reason for PPPoE sockets being available to any
unprivileged process, BTW? After all, you need a packet socket for the
discovery stage anyway, so it's unlikely that any unprivileged process
will ever need to create a PPPoE socket, no? Allocating all session IDs
for a known AC is a kind of DoS, too, after all - with Juniper ERXes,
this is really easy, actually, since they don't ever assign session ids
above 8000 ...
Signed-off-by: Florian Zumbiehl <florz@florz.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
While trying to implement u32 hashes in my shaping machine I ran into
a possible bug in the u32 hash/bucket computing algorithm
(net/sched/cls_u32.c).
The problem occurs only with hash masks that extend over the octet
boundary, on little endian machines (where htonl() actually does
something).
Let's say that I would like to use 0x3fc0 as the hash mask. This means
8 contiguous "1" bits starting at b6. With such a mask, the expected
(and logical) behavior is to hash any address in, for instance,
192.168.0.0/26 in bucket 0, then any address in 192.168.0.64/26 in
bucket 1, then 192.168.0.128/26 in bucket 2 and so on.
This is exactly what would happen on a big endian machine, but on
little endian machines, what would actually happen with current
implementation is 0x3fc0 being reversed (into 0xc03f0000) by htonl()
in the userspace tool and then applied to 192.168.x.x in the u32
classifier. When shifting right by 16 bits (rank of first "1" bit in
the reversed mask) and applying the divisor mask (0xff for divisor
256), what would actually remain is 0x3f applied on the "168" octet of
the address.
One could say is this can be easily worked around by taking endianness
into account in userspace and supplying an appropriate mask (0xfc03)
that would be turned into contiguous "1" bits when reversed
(0x03fc0000). But the actual problem is the network address (inside
the packet) not being converted to host order, but used as a
host-order value when computing the bucket.
Let's say the network address is written as n31 n30 ... n0, with n0
being the least significant bit. When used directly (without any
conversion) on a little endian machine, it becomes n7 ... n0 n8 ..n15
etc in the machine's registers. Thus bits n7 and n8 would no longer be
adjacent and 192.168.64.0/26 and 192.168.128.0/26 would no longer be
consecutive.
The fix is to apply ntohl() on the hmask before computing fshift,
and in u32_hash_fold() convert the packet data to host order before
shifting down by fshift.
With helpful feedback from Jamal Hadi Salim and Jarek Poplawski.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
[ Upstream commit: 4f9f8311a08c0d95c70261264a2b47f2ae99683a ]
tecl_reset() is called from deactivate and qdisc is set to noop already,
but subsequent teql_xmit does not know about it and dereference private
data as teql qdisc and thus oopses.
not catch it first :)
Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
The TRACE_IRQS_ON function in iret_exc: calls a C function without
ensuring that the segments are set properly. Move the trace function and
the enabling of interrupt into the C stub.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
The code for LDT segment selectors was not robust in the face of a bogus
selector set in %cs via ptrace before the single-step was done.
Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
O= builds produced errors in the shell command because of unfound headers.
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
ppp_mppe puts a crypto key on the kernel stack, then passes the
address of that into the crypto layer. That doesn't work because the
crypto layer needs to be able to do virt_to_*() on the address which
does not universally work for the kernel stack on all platforms.
Adrian Bunk:
Backported to 2.6.16.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
netlink_run_queue() doesn't handle multiple processes processing the
queue concurrently. Serialize queue processing in inet_diag to fix
a oops in netlink_rcv_skb caused by netlink_run_queue passing a
NULL for the skb.
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000054
[349587.500454] printing eip:
[349587.500457] c03318ae
[349587.500459] *pde = 00000000
[349587.500464] Oops: 0000 [#1]
[349587.500466] PREEMPT SMP
[349587.500474] Modules linked in: w83627hf hwmon_vid i2c_isa
[349587.500483] CPU: 0
[349587.500485] EIP: 0060:[<c03318ae>] Not tainted VLI
[349587.500487] EFLAGS: 00010246 (2.6.22.3 #1)
[349587.500499] EIP is at netlink_rcv_skb+0xa/0x7e
[349587.500506] eax: 00000000 ebx: 00000000 ecx: c148d2a0 edx: c0398819
[349587.500510] esi: 00000000 edi: c0398819 ebp: c7a21c8c esp: c7a21c80
[349587.500517] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
[349587.500521] Process oidentd (pid: 17943, ti=c7a20000 task=cee231c0 task.ti=c7a20000)
[349587.500527] Stack: 00000000 c7a21cac f7c8ba78 c7a21ca4 c0331962 c0398819 f7c8ba00 0000004c
[349587.500542] f736f000 c7a21cb4 c03988e3 00000001 f7c8ba00 c7a21cc4 c03312a5 0000004c
[349587.500558] f7c8ba00 c7a21cd4 c0330681 f7c8ba00 e4695280 c7a21d00 c03307c6 7fffffff
[349587.500578] Call Trace:
[349587.500581] [<c010361a>] show_trace_log_lvl+0x1c/0x33
[349587.500591] [<c01036d4>] show_stack_log_lvl+0x8d/0xaa
[349587.500595] [<c010390e>] show_registers+0x1cb/0x321
[349587.500604] [<c0103bff>] die+0x112/0x1e1
[349587.500607] [<c01132d2>] do_page_fault+0x229/0x565
[349587.500618] [<c03c8d3a>] error_code+0x72/0x78
[349587.500625] [<c0331962>] netlink_run_queue+0x40/0x76
[349587.500632] [<c03988e3>] inet_diag_rcv+0x1f/0x2c
[349587.500639] [<c03312a5>] netlink_data_ready+0x57/0x59
[349587.500643] [<c0330681>] netlink_sendskb+0x24/0x45
[349587.500651] [<c03307c6>] netlink_unicast+0x100/0x116
[349587.500656] [<c0330f83>] netlink_sendmsg+0x1c2/0x280
[349587.500664] [<c02fcce9>] sock_sendmsg+0xba/0xd5
[349587.500671] [<c02fe4d1>] sys_sendmsg+0x17b/0x1e8
[349587.500676] [<c02fe92d>] sys_socketcall+0x230/0x24d
[349587.500684] [<c01028d2>] syscall_call+0x7/0xb
[349587.500691] =======================
[349587.500693] Code: f0 ff 4e 18 0f 94 c0 84 c0 0f 84 66 ff ff ff 89 f0 e8 86 e2 fc ff e9 5a ff ff ff f0 ff 40 10 eb be 55 89 e5 57 89 d7 56 89 c6 53 <8b> 50 54 83 fa 10 72 55 8b 9e 9c 00 00 00 31 c9 8b 03 83 f8 0f
Reported by Athanasius <link@miggy.org>
Adrian Bunk:
Backported to 2.6.16 based on a suggestion by David S. Miller.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
|
|
|
|
->readdir passes lofft_t offsets (used as nfs cookies) to
nfs3svc_encode_entry{,_plus}, but when they pass it on to encode_entry it
becomes an 'off_t', which isn't good.
So filesystems that returned 64bit offsets would lose.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
unlock_buffer(), like unlock_page(), must not clear the lock without
ensuring that the critical section is closed.
Mingming later sent the same patch, saying:
We are running SDET benchmark and saw double free issue for ext3 extended
attributes block, which complains the same xattr block already being freed (in
ext3_xattr_release_block()). The problem could also been triggered by
multiple threads loop untar/rm a kernel tree.
The race is caused by missing a memory barrier at unlock_buffer() before the
lock bit being cleared, resulting in possible concurrent h_refcounter update.
That causes a reference counter leak, then later leads to the double free that
we have seen.
Inside unlock_buffer(), there is a memory barrier is placed *after* the lock
bit is being cleared, however, there is no memory barrier *before* the bit is
cleared. On some arch the h_refcount update instruction and the clear bit
instruction could be reordered, thus leave the critical section re-entered.
The race is like this: For example, if the h_refcount is initialized as 1,
cpu 0: cpu1
-------------------------------------- -----------------------------------
lock_buffer() /* test_and_set_bit */
clear_buffer_locked(bh);
lock_buffer() /* test_and_set_bit */
h_refcount = h_refcount+1; /* = 2*/ h_refcount = h_refcount + 1; /*= 2 */
clear_buffer_locked(bh);
.... ......
We lost a h_refcount here. We need a memory barrier before the buffer head
lock bit being cleared to force the order of the two writes. Please apply.
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
It didn't handle that case at all, and now dump_stack()
can be implemented directly as show_stack(current, NULL)
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
The snap_rcv code reads 5 bytes so we should make sure that
we have 5 bytes in the head before proceeding.
Based on diagnosis and fix by Evgeniy Polyakov, reported by
Alan J. Wylie.
Patch also kills the skb->sk assignment before kfree_skb
since it's redundant.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
-Fixes ABBA deadlock noted by Patrick McHardy <kaber@trash.net>:
> There is at least one ABBA deadlock, est_timer() does:
> read_lock(&est_lock)
> spin_lock(e->stats_lock) (which is dev->queue_lock)
>
> and qdisc_destroy calls htb_destroy under dev->queue_lock, which
> calls htb_destroy_class, then gen_kill_estimator and this
> write_locks est_lock.
To fix the ABBA deadlock the rate estimators are now kept on an rcu list.
-The est_lock changes the use from protecting the list to protecting
the update to the 'bstat' pointer in order to avoid NULL dereferencing.
-The 'interval' member of the gen_estimator structure removed as it is
not needed.
Signed-off-by: Ranko Zivojnovic <ranko@spidernet.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Currently when icmp_errors_use_inbound_ifaddr is set and an ICMP error is
sent after the packet passed through ip_output(), an address from the
outgoing interface is chosen as ICMP source address since skb->dev doesn't
point to the incoming interface anymore.
Fix this by doing an interface lookup on rt->dst.iif and using that device.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Normally a serial Bluetooth device is opened, TIOSETD'ed to N_HCI line
discipline, HCIUARTSETPROTO'ed and finally closed. In case the device
fails to HCIUARTSETPROTO, closing it produces a NULL pointer dereference.
Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
A trivial fix to (what looks like) an unintentional fall-through in the
HCI line discipline.
Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Add "optical" to sysfs "media" attribute as already in /proc
Signed-off-by: Danny Kukawka <dkukawka@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Sergey Vlasov reported that his "FUJITSU MCC3064AP, ATAPI OPTICAL drive"
pops up as UNKNOWN in /proc/ide/*/media .
Closes kernel Bugzilla #4145.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
On the SCSI layer ioctl path there is no implicit permissions check for
ioctls (and indeed other drivers implement unprivileged ioctls). aacraid
however allows all sorts of very admin only things to be done so should
check.
Signed-off-by: Alan Cox <alan@redhat.com>
Acked-by: Mark Salyzyn <mark_salyzyn@adaptec.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
This patch makes CIFS honour a process' umask like other filesystems.
Of course the server is still free to munge the permissions if it wants
to; but the client will send the "right" permissions to begin with.
A few caveats:
1) It only applies to filesystems that have CAP_UNIX (aka support unix
extensions)
2) It applies the correct mode to the follow up CIFSSMBUnixSetPerms()
after remote creation
When mode to CIFS/NTFS ACL mapping is complete we can do the
same thing for that case for servers which do not
support the Unix Extensions.
Signed-off-by: Matt Keenen <matt@opcode-solutions.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
