| Age | Commit message (Collapse) | Author |
|---|
|
Fix possible memory overrun issue in the isdn ioctl code.
Found by ADLAB <adlab@venustech.com.cn>
Signed-off-by: Karsten Keil <kkeil@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9416
Signed-off-by: Karsten Keil <kkeil@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
[ Upstream commit: d011a231675b240157a3c335dd53e9b849d7d30d ]
skb->truesize was not being incremented at all to
reflect the page based data added to RX SKBs.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
[ Upstream commit: e5e025401f6e926c1d9dc3f3f2813cf98a2d8708 ]
Here's proposed fix for RX checksum handling in cassini; it affects
little-endian working with half-duplex gigabit, but obviously needs
testing on big-endian too.
The problem is, we need to convert checksum to fixed-endian *before*
correcting for (unstripped) FCS. On big-endian it won't matter
(conversion is no-op), on little-endian it will, but only if FCS is
not stripped by hardware; i.e. in half-duplex gigabit mode when
->crc_size is set.
cassini.c part is that fix, cassini.h one consists of trivial
endianness annotations. With that applied the sucker is endian-clean,
according to sparse.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
[ Upstream commit: 52961955aa180959158faeb9fd6b4f8a591450f5 ]
Adrian Bunk:
Backported to 2.6.16.
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Minor number 0 (under the raw major) is reserved for the rawctl device
file, which is used to query, set, and unset raw device bindings. However,
the ioctl interface does not protect the user from specifying a raw device
with minor number 0:
$ sudo ./raw /dev/raw/raw0 /dev/VolGroup00/swap
/dev/raw/raw0: bound to major 253, minor 2
$ ls -l /dev/rawctl
ls: /dev/rawctl: No such file or directory
$ ls -l /dev/raw/raw0
crw------- 1 root root 162, 0 Jan 12 10:51 /dev/raw/raw0
$ sudo ./raw -qa
Cannot open master raw device '/dev/rawctl' (No such file or directory)
As you can see, this prevents any further raw operations from
succeeding. The fix (from Steve Fernandez) is quite simple - do not
allow the allocation of minor number 0.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
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>
|
|
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: 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>
|
|
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>
|
|
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>
|
|
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>
|
|
The pwc driver is defficient in locking, which can trigger an oops
when disconnecting.
Adrian Bunk:
Backported to 2.6.16.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
The pwc driver has a disconnect method that waits for user space to
close the device. This opens up an opportunity for a DoS attack,
blocking the USB subsystem and making khubd's task busy wait in
kernel space. This patch shifts freeing resources to close if an opened
device is disconnected.
Adrian Bunk:
Backported to 2.6.16.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
If it's EXPORT_SYMBOL'ed it can't be __devinit.
Reported by Mikael Pettersson.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
If root raised the default wakeup threshold over the size of the
output pool, the pool transfer function could overflow the stack with
RNG bytes, causing a DoS or potential privilege escalation.
(Bug reported by the PaX Team <pageexec@freemail.hu>)
Signed-off-by: Matt Mackall <mpm@selenic.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Add data from zero-entropy random_writes directly to output pools to
avoid accounting difficulties on machines without entropy sources.
Tested on lguest with all entropy sources disabled.
Signed-off-by: Matt Mackall <mpm@selenic.com>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Fix cast error in entropy extraction.
Add comments explaining the magic 16.
Remove extra confusing loop variable.
Signed-off-by: Matt Mackall <mpm@selenic.com>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Signed-off-by: Dann Frazier <dannf@hp.com>
Signed-off-by: Andres Salomon <dilinger@debian.org>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
A static function mustn't be exported.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
A static function mustn't be exported.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
This patch addresses the issue with "osize too small" errors in mppe
encryption. The patch fixes the issue with wrong output buffer size
being passed to ppp decompression routine.
--------------------
As pointed out by Suresh Mahalingam, the issue addressed by
ppp-fix-osize-too-small-errors-when-decoding patch is not fully resolved yet.
The size of allocated output buffer is correct, however it size passed to
ppp->rcomp->decompress in ppp_generic.c if wrong. The patch fixes that.
--------------------
Signed-off-by: Konstantin Sharlaimov <konstantin.sharlaimov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
The mppe_decompress() function required a buffer that is 1 byte too
small when receiving a message of mru size. This fixes buffer
allocation to prevent this from occurring.
Signed-off-by: Konstantin Sharlaimov <konstantin.sharlaimov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
md/bitmap tracks how many active write requests are pending on blocks
associated with each bit in the bitmap, so that it knows when it can clear
the bit (when count hits zero).
The counter has 14 bits of space, so if there are ever more than 16383, we
cannot cope.
Currently the code just calles BUG_ON as "all" drivers have request queue
limits much smaller than this.
However is seems that some don't. Apparently some multipath configurations
can allow more than 16383 concurrent write requests.
So, in this unlikely situation, instead of calling BUG_ON we now wait
for the count to drop down a bit. This requires a new wait_queue_head,
some waiting code, and a wakeup call.
Tested by limiting the counter to 20 instead of 16383 (writes go a lot slower
in that case...).
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
While developing more functionality in mdadm I found some bugs in md...
- When we remove a device from an inactive array (write 'remove' to
the 'state' sysfs file - see 'state_store') would should not
update the superblock information - as we may not have
read and processed it all properly yet.
- initialise all raid_disk entries to '-1' else the 'slot sysfs file
will claim '0' for all devices in an array before the array is
started.
- all '\n' not to be present at the end of words written to
sysfs files
- when we use SET_ARRAY_INFO to set the md metadata version,
set the flag to say that there is persistant metadata.
- allow GET_BITMAP_FILE to be called on an array that hasn't
been started yet.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Fix few bugs that meant that:
- superblocks weren't alway written at exactly the right time (this
could show up if the array was not written to - writting to the array
causes lots of superblock updates and so hides these errors).
- restarting device recovery after a clean shutdown (version-1 metadata
only) didn't work as intended (or at all).
1/ Ensure superblock is updated when a new device is added.
2/ Remove an inappropriate test on MD_RECOVERY_SYNC in md_do_sync.
The body of this if takes one of two branches depending on whether
MD_RECOVERY_SYNC is set, so testing it in the clause of the if
is wrong.
3/ Flag superblock for updating after a resync/recovery finishes.
4/ If we find the neeed to restart a recovery in the middle (version-1
metadata only) make sure a full recovery (not just as guided by
bitmaps) does get done.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
The comment gives more details, but I didn't quite have the sequencing write,
so there was room for races to leave bits unset in the on-disk bitmap for
short periods of time.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
When a device is unplugged, requests are moved from one or two (depending on
whether a bitmap is in use) queues to the main request queue.
So whenever requests are put on either of those queues, we should make sure
the raid5 array is 'plugged'. However we don't. We currently plug the raid5
queue just before putting requests on queues, so there is room for a race. If
something unplugs the queue at just the wrong time, requests will be left on
the queue and nothing will want to unplug them. Normally something else will
plug and unplug the queue fairly soon, but there is a risk that nothing will.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
We introduced 'io_sectors' recently so we could count the sectors that causes
io during resync separate from sectors which didn't cause IO - there can be a
difference if a bitmap is being used to accelerate resync.
However when a speed is reported, we find the number of sectors processed
recently by subtracting an oldish io_sectors count from a current
'curr_resync' count. This is wrong because curr_resync counts all sectors,
not just io sectors.
So, add a field to mddev to store the curren io_sectors separately from
curr_resync, and use that in the calculations.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
When an array has a bitmap, a device can be removed and re-added and only
blocks changes since the removal (as recorded in the bitmap) will be resynced.
It should be possible to do a similar thing to arrays without bitmaps. i.e.
if a device is removed and re-added and *no* changes have been made in the
interim, then the add should not require a resync.
This patch allows that option. This means that when assembling an array one
device at a time (e.g. during device discovery) the array can be enabled
read-only as soon as enough devices are available, but extra devices can still
be added without causing a resync.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
md/bitmap modifies i_writecount of a bitmap file to make sure that no-one else
writes to it. The reverting of the change is sometimes done twice, and there
is one error path where it is omitted.
This patch tidies that up.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
bitmap_active is never called, and the BITMAP_ACTIVE flag is never users or
tested, so discard them both.
Also remove some out-of-date 'todo' comments.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
md/bitmap gets a collection of pages representing the bitmap when it
initialises the bitmap, and puts all the references when discarding the
bitmap.
It also occasionally takes extra references without any good reason, and
sometimes drops them ... though it doesn't always drop them, which can result
in a memory leak.
This patch removes the unnecessary 'get_page' calls, and the corresponding
'put_page' calls.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
In particular, this means that we use 4 bits per page instead of a whole
unsigned long.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
md/bitmap has some attributes per-page. Handling of these attributes in
largely abstracted in set_page_attr and clear_page_attr. However
get_page_attr exposes the format used to store them. So prior to changing
that format, introduce test_page_attr instead of get_page_attr, and make
appropriate usage changes.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
When "mdadm --grow /dev/mdX --bitmap=none" is used to remove a filebacked
bitmap, the bitmap was disconnected from the array, but the file wasn't closed
(until the array was stopped).
The file also wasn't closed if adding the bitmap file failed.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
Currently a device failure during recovery leaves bits set in the bitmap.
This normally isn't a problem as the offending device will be rejected because
of errors. However if device re-adding is being used with non-persistent
bitmaps, this can be a problem.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
I really should make this a function of the personality....
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
There's a bug in the MCA bus matching algorithm in that it promotes from
signed short to int before comparing with the actual id and does sign
extension on anything > 0x7fff (which means that pos ids > 0x7fff never
get correctly matched).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
|
|
patch 1/2 (revised):
- Fix drive->waiting_for_dma to work with CDB-intr devices.
- Do the dma status clearing in ide_intr() and add a new
hwif->ide_dma_clear_irq for Intel ICHx controllers.
Revised per Alan, Sergei and Bart's advice.
Patch against 2.6.20-rc6. Tested ok on my ICH4 and pdc20275 adapters.
Please review/apply, thanks.
Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
|
