UBSAN: Undefined behaviour in drivers/scsi/megaraid/megaraid_sas_fp.c:117:32
index 255 is out of range for type 'MR_LD_SPAN_MAP [1]'
This commit 51087a8617fe (megaraid_sas : Extended VD support) defined those,
struct MR_FW_RAID_MAP {
u8 ldTgtIdToLd[MAX_RAIDMAP_LOGICAL_DRIVES
x/v4l2-controls.h:1105: found __[us]{8,16,32,64} type
without #include
drivers/scsi/aha1542.o: In function `aha1542_interrupt':
>> drivers/scsi/aha1542.c:328: undefined reference to `__udivdi3'
make[1]: *** [vmlinux] Error 1
make[1]: Target '_all' not remade because of errors.
vim
ree
> > GCC_VERSION=7.2.0 make.cross ARCH=arm
> >
> > All errors (new ones prefixed by >>):
> >
> > > > ERROR: "__aeabi_uldivmod" [drivers/scsi/myrs.ko] undefined!
>
> I think this is the fix, can someone with an arm build check?
This
make.cross
> git checkout 77266186397c6c782a3f670d32808a9671806ec5
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=arm
>
> All errors (new ones prefixed by >>):
>
> > > ERROR: "__aeabi_uldivmod&q
to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> ERROR: "__aeabi_uldivmod" [drivers/scsi/myrs.ko] undefined!
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.or
: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 77266186397c6c782a3f670d32808a9671806ec5
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> ERROR: "__udivdi3" [drivers/scsi/myrs.ko] undefined!
https://bugzilla.kernel.org/show_bug.cgi?id=200317
--- Comment #2 from Yuexing Wang (wangyxla...@gmail.com) ---
(In reply to Matt Wang from comment #1)
> I think this is by-design. If a target can not find its parents, it
> indicates there is problem during enumeration. Panic is proper in this
>
https://bugzilla.kernel.org/show_bug.cgi?id=200317
Matt Wang (witallw...@gmail.com) changed:
What|Removed |Added
CC||witallw...@gmail.com
https://bugzilla.kernel.org/show_bug.cgi?id=200317
Bug ID: 200317
Summary: Null pointer dereference error in
linux/drivers/scsi/scsi_transport_fc.c
Product: SCSI Drivers
Version: 2.5
Kernel Version: 4.17.3
Hardware
ta_xmit function need to modify to reduce I/O delay
and unnecessary time-out.
problem solutions :
We should add a timeout mechanism to the while loop :
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index c051694..77108fe 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/
Tomohiro,
> drivers/scsi/mpt2sas/ no longer exists after
> c84b06a48c ("mpt3sas: Single driver module which supports both
> SAS 2.0 & SAS 3.0 HBAs") merged/removed it.
Applied patches 1 + 2 to 4.18/scsi-queue. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
drivers/scsi/mpt2sas/ no longer exists after
c84b06a48c ("mpt3sas: Single driver module which supports both
SAS 2.0 & SAS 3.0 HBAs") merged/removed it.
Signed-off-by: Tomohiro Kusumi <kusumi.tomoh...@osnexus.com>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff -
(attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 2439bec3bf084ab6cbc69a66797a4612042be6ca
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers//scsi/storvsc
Max,
> On Jan 15, 2018, at 12:37 PM, Max Kellermann wrote:
>
> On 2018/01/15 20:58, "Madhani, Himanshu" wrote:
>> We have patch to prevent this double free in 4.16/scsi-queue
>> already.
>
> No, let me repeat: this is a different bug!
>
> Your
Hi Max,
> On Jan 15, 2018, at 12:37 PM, Max Kellermann wrote:
>
> On 2018/01/15 20:58, "Madhani, Himanshu" wrote:
>> We have patch to prevent this double free in 4.16/scsi-queue
>> already.
>
> No, let me repeat: this is a different bug!
>
>
On 2018/01/15 20:58, "Madhani, Himanshu" wrote:
> We have patch to prevent this double free in 4.16/scsi-queue
> already.
No, let me repeat: this is a different bug!
Your bug is about the free call after waiting for completion
synchronously in
t; which belongs to the cache qla2xxx_srbs of size 344
> The buggy address is located 336 bytes inside of
> 344-byte region [88278147a440, 88278147a598)
>
> Signed-off-by: Max Kellermann <m...@cm4all.com>
> ---
> drivers/scsi/qla2xxx/qla_init.c |3 ++-
> 1
s belongs to the object at 88278147a440
which belongs to the cache qla2xxx_srbs of size 344
The buggy address is located 336 bytes inside of
344-byte region [88278147a440, 88278147a598)
Signed-off-by: Max Kellermann <m...@cm4all.com>
---
drivers/scsi/qla2xxx/qla_init.c |3 ++-
99cfdc04c12ea1bc5719bff15f24dae8b5b90da9
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/scsi/libsas/sas_discover.c:364:6: sparse: symbol
>> 'sas_destruct_ports' was not declared. Should it
The driver may sleep in the interrupt handler.
The function call path is:
esas2r_adapter_tasklet (interrupt handler)
esas2r_do_tasklet_tasks
esas2r_handle_chip_rst_during_tasklet
esas2r_init_adapter_hw
esas2r_nvram_read_direct
down_interruptible --> may sleep
I do
According to drivers/scsi/wd719x.c, the kernel module may sleep under a
spinlock.
The function call path is:
wd719x_host_reset (acquire the spinlock)
wd719x_chip_init
request_firmware --> may sleep
I do not find a good way to fix it, so I only report.
This possible bug is found by
According to drivers/scsi/ipr.c, the kernel module may sleep under a
spinlock.
The function call paths are:
ipr_shutdown (acquire the spinlock)
irq_poll_disable
msleep --> may sleep
ipr_ata_post_internal (acquire the spinlock)
ipr_device_reset
ipr_send_blocking_
Pravin,
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
Applied to 4.16/scsi-queue. Thank you!
--
Martin K. Petersen Oracle Linux Engineering
According to drivers/scsi/dpt_i2o.c, the kernel module may sleep under a
spinlock.
The function call paths are:
adpt_reset (acquire the spinlock)
__adpt_reset
adpt_hba_reset
adpt_i2o_activate_hba
adpt_i2o_status_get
dma_alloc_coherent(GFP_KERNEL) --> may sl
According to drivers/scsi/dpt_i2o.c, the kernel module may sleep under a
spinlock.
The function call paths are:
adpt_abort (acquire the spinlock)
adpt_i2o_post_wait
adpt_i2o_post_this
schedule_timeout_uninterruptible--> may sleep
adpt_device_reset (acquire the spinl
According to drivers/scsi/dpt_i2o.c, the kernel module may sleep in the
interrupt handler.
The function call path is:
adpt_isr (interrupt handler)
adpt_send_nop
schedule_timeout_uninterruptible --> may sleep
A possible fixing is to replace "schedule_timeout_uninterruptible"
According to drivers/scsi/advansys.c, the kernel module may sleep in the
interrupt handler.
The function call paths are:
advansys_interrupt (interrupt handler)
AdvISR
adv_async_callback
AdvResetChipAndSB
AdvInitAsc38C1600Driver
request_firmware --> may sl
On 2017/12/07 21:38, "Madhani, Himanshu" wrote:
> NACK
>
> These calls are asynchronous calls and free should be called by
> completion.
I don't understand the NACK, and your text doesn't explain it. It
only describes a second bug that is orthogonal to mine.
t; which belongs to the cache qla2xxx_srbs of size 344
> The buggy address is located 336 bytes inside of
> 344-byte region [88278147a440, 88278147a598)
>
> Signed-off-by: Max Kellermann <m...@cm4all.com>
> ---
> drivers/scsi/qla2xxx/qla_init.c |3 ++-
> 1
s belongs to the object at 88278147a440
which belongs to the cache qla2xxx_srbs of size 344
The buggy address is located 336 bytes inside of
344-byte region [88278147a440, 88278147a598)
Signed-off-by: Max Kellermann <m...@cm4all.com>
---
drivers/scsi/qla2xxx/qla_init.c |3 ++-
These duplicate includes have been found with scripts/checkincludes.pl but
they have been removed manually to avoid removing false positives.
Signed-off-by: Pravin Shedge <pravin.shedge4li...@gmail.com>
---
drivers/scsi/qla2xxx/qla_nx2.c | 2 --
1 file changed, 2 deletions(-)
diff
as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 016d5c35e27824f31c394009dd0f72f2c6b0dc85
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/scsi//mpt3sas/mpt3sas_
You are right. I've tested on 4.14-rc6, and it cannot be reproducible.
On Wed, Oct 25, 2017 at 4:01 PM, Johannes Thumshirn wrote:
> idaifish writes:
>
>> Hi,
>>
>> I've got the following report while fuzzing the kernel with syzkaller.
>> (on 4.9.58)
>
>
idaifish writes:
> Hi,
>
> I've got the following report while fuzzing the kernel with syzkaller.
> (on 4.9.58)
Can you test if this is already fixed on 4.14-rcX? There have been a
number of syzkaller related fixes between 4.9 and now. Probably we just
missed to back-port it
Helge,
> On parisc I see this UBSAN warning with a sym53c896:
>
> UBSAN: Undefined behaviour in ./drivers/scsi/sym53c8xx_2/sym_hipd.c:762:24
> index -1903078336 is out of range for type 'u32 [7]'
>
> Avoid this warning by switching to dev64_ul().
Applied to 4.14/scsi-queue
On Thu, Aug 10, 2017 at 09:08:49PM +0200, Helge Deller wrote:
> On parisc I see this UBSAN warning with a sym53c896:
>
> UBSAN: Undefined behaviour in ./drivers/scsi/sym53c8xx_2/sym_hipd.c:762:24
> index -1903078336 is out of range for type 'u32 [7]'
>
> Avoid this wa
On parisc I see this UBSAN warning with a sym53c896:
UBSAN: Undefined behaviour in ./drivers/scsi/sym53c8xx_2/sym_hipd.c:762:24
index -1903078336 is out of range for type 'u32 [7]'
Avoid this warning by switching to dev64_ul().
Signed-off-by: Helge Deller <del...@gmx.de>
diff --git a/d
ndefined behaviour in
> ./drivers/scsi/sym53c8xx_2/sym_hipd.c:762:24
> [ 18.864911] index -1903078336 is out of range for type 'u32 [7]'
> [ 18.936779] CPU: 0 PID: 1 Comm: swapper Not tainted 4.13.0-rc3-32bit+ #427
> [ 19.019138] Backtrace:
> [ 19.047353] [<10191eb4>
rq 68
> [ 18.625415]
>
> [ 18.726489] UBSAN: Undefined behaviour in
> ./drivers/scsi/sym53c8xx_2/sym_hipd.c:762:24
> [ 18.864911] index -1903078336 is out of range for type 'u32 [7]'
What about np->clock_divn?
Dave
--
John David Anglin dave.ang...@bell.net
UBSAN: Undefined behaviour in
./drivers/scsi/sym53c8xx_2/sym_hipd.c:762:24
[ 18.864911] index -1903078336 is out of range for type 'u32 [7]'
[ 18.936779] CPU: 0 PID: 1 Comm: swapper Not tainted 4.13.0-rc3-32bit+ #427
[ 19.019138] Backtrace:
[ 19.047353] [<10191eb4>] show_stack+0x3c/0x50
[
Hello scsi maintainer,
I would like to report a signed integer overflow in
drivers/scsi/scsicam.c:173:29
reported on the Gentoo bug reporting system.
https://bugs.gentoo.org/show_bug.cgi?id=617820
The problem looks present ,at least , in the Linux kernel 4.9.25
regards,
Alice Ferrazzi
ed in 12fb8c1574d7d in 2010, see the
commit message there.
Beste Grüße / Best regards,
- Benjamin Block
>
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 81d
When debugging a race condition in scsi_remove_target of 3.12, I ran into this
possible bug within scsi_alloc_target.
When an existing "struct scsi_target" is found and used, the starget just got
through kzmalloc should be freed, rather than dong a "put_device(dev)".
diff
the 2 should be synchronized)
Best regards,
CJ
diff -u -p ./drivers/scsi/qla2xxx/qla_os.c
/tmp/nothing/drivers/scsi/qla2xxx/qla_os.c
--- ./drivers/scsi/qla2xxx/qla_os.c
+++ /tmp/nothing/drivers/scsi/qla2xxx/qla_os.c
@@ -3244,8 +3244,6 @@ probe_hw_failed:
iospace_config_failed
drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/scsi/.
Suggested-by: Alan Cox <gno...@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowe...@redhat.com>
cc: "Juergen E. Fischer"
Finn Thain wrote:
> I can see how base addresses and IO ports are relevant, but the irq
> parameter changes below don't protect the kernel image AFAICT. What's the
> rationale for those changes? I think it should be stated here.
Easier grepping for one. But I'm
Elena Reshetova writes:
> refcount_t type and corresponding API should be used instead of
> atomic_t when the variable is used as a reference counter. This allows
> to avoid accidental refcounter overflows that might lead to
> use-after-free situations.
Applied to
Elena Reshetova writes:
> refcount_t type and corresponding API should be used instead of
> atomic_t when the variable is used as a reference counter. This allows
> to avoid accidental refcounter overflows that might lead to
> use-after-free situations.
Applied to
https://bugzilla.kernel.org/show_bug.cgi?id=108621
Martin Ziegler (zieg...@uni-freiburg.de) changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugzilla.kernel.org/show_bug.cgi?id=108621
--- Comment #4 from Martin Ziegler (zieg...@uni-freiburg.de) ---
The bug did not appear in later kernels. I should have
report this earlier. Sorry
(Martin Ziegler)
--
You are receiving this mail because:
You are watching the assignee of the
https://bugzilla.kernel.org/show_bug.cgi?id=108621
--- Comment #5 from Szőgyényi Gábor (szg0...@freemail.hu) ---
Can you close this bug, please?
--
You are receiving this mail because:
You are watching the assignee of the bug.
ed-off-by: Hans Liljestrand <ishkam...@gmail.com>
Signed-off-by: Kees Cook <keesc...@chromium.org>
Signed-off-by: David Windsor <dwind...@gmail.com>
Acked-by: Chris Leech <cle...@redhat.com>
---
drivers/scsi/libiscsi.c| 8
drivers/scsi/qedi/qedi_iscsi.c |
On 03/09/2017 10:26 AM, Reshetova, Elena wrote:
>
>> On 03/09/2017 08:18 AM, Reshetova, Elena wrote:
On Mon, Mar 06, 2017 at 04:21:09PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a
> On 03/09/2017 08:18 AM, Reshetova, Elena wrote:
> >> On Mon, Mar 06, 2017 at 04:21:09PM +0200, Elena Reshetova wrote:
> >>> refcount_t type and corresponding API should be
> >>> used instead of atomic_t when the variable is used as
> >>> a reference counter. This allows to avoid accidental
>
On 03/09/2017 08:18 AM, Reshetova, Elena wrote:
>> On Mon, Mar 06, 2017 at 04:21:09PM +0200, Elena Reshetova wrote:
>>> refcount_t type and corresponding API should be
>>> used instead of atomic_t when the variable is used as
>>> a reference counter. This allows to avoid accidental
>>> refcounter
ed-off-by: Hans Liljestrand <ishkam...@gmail.com>
Signed-off-by: Kees Cook <keesc...@chromium.org>
Signed-off-by: David Windsor <dwind...@gmail.com>
Acked-by: Johannes Thumshirn <j...@kernel.org>
---
drivers/scsi/libfc/fc_fcp.c | 6 +++---
include/scsi/libfc.h| 3 ++-
or <dwind...@gmail.com>
>
> This looks OK to me.
>
> Acked-by: Chris Leech <cle...@redhat.com>
Thank you for review! Do you have a tree that can take this change?
Best Regards,
Elena.
>
> > ---
> > drivers/scsi/libiscsi.c| 8
> &g
ks OK to me.
Acked-by: Chris Leech <cle...@redhat.com>
> ---
> drivers/scsi/libiscsi.c| 8
> drivers/scsi/qedi/qedi_iscsi.c | 2 +-
> include/scsi/libiscsi.h| 3 ++-
> 3 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/scsi/libiscsi
https://bugzilla.kernel.org/show_bug.cgi?id=108621
Szőgyényi Gábor (szg0...@freemail.hu) changed:
What|Removed |Added
CC|
ed-off-by: Hans Liljestrand <ishkam...@gmail.com>
Signed-off-by: Kees Cook <keesc...@chromium.org>
Signed-off-by: David Windsor <dwind...@gmail.com>
---
drivers/scsi/libiscsi.c | 8
drivers/scsi/qedi/qedi_iscsi.c | 2 +-
include/scsi/libiscsi.h| 3 ++-
3 fil
https://bugzilla.kernel.org/show_bug.cgi?id=120371
Wilfried Klaebe (linux-ker...@lebenslange-mailadresse.de) changed:
What|Removed |Added
Status|RESOLVED
https://bugzilla.kernel.org/show_bug.cgi?id=120371
Wilfried Klaebe (linux-ker...@lebenslange-mailadresse.de) changed:
What|Removed |Added
Status|NEW
To enable eventual removal of pr_warning
This makes pr_warn use consistent for drivers/scsi
Prior to this patch, there was 1 use of pr_warning and
96 uses of pr_warn in drivers/scsi
Signed-off-by: Joe Perches <j...@perches.com>
---
drivers/scsi/a3000.c | 2 +-
1 file changed, 1 insertion
https://bugzilla.kernel.org/show_bug.cgi?id=194341
Bug ID: 194341
Summary: drivers/scsi/mpt3sas/mpt3sas_scsih.c
_scsih_ir_fastpath ambiguous path structures
Product: SCSI Drivers
Version: 2.5
Kernel Version: 4.10
https://bugzilla.kernel.org/show_bug.cgi?id=194321
Bug ID: 194321
Summary: drivers/scsi/mpt3sas/mpt3sas_base.c
mpt3sas_base_put_smid_fast_path structure
descriptor.Default.DescriptorTypeDependent is not used
Use setup_timer instead of structure field assignments
to initialize a timer.
mod_timer is a more efficient way to update the expire field of
an active timer (if the timer is inactive it will be activated)
Signed-off-by: Shyam Saini <mayhs11sa...@gmail.com>
---
drivers/scsi/esas2r/esas2r_
On Tue, Dec 13, 2016 at 08:47:33AM -0800, Greg Kroah-Hartman wrote:
> On Tue, Dec 13, 2016 at 08:43:41AM -0800, James Bottomley wrote:
> > On Tue, 2016-12-13 at 08:33 -0800, Randy Dunlap wrote:
> > > On 12/13/16 08:30, Greg Kroah-Hartman wrote:
> > > > I don't maintain 3.18-stable :)
> > > >
> >
On Tue, Dec 13, 2016 at 08:43:41AM -0800, James Bottomley wrote:
> On Tue, 2016-12-13 at 08:33 -0800, Randy Dunlap wrote:
> > On 12/13/16 08:30, Greg Kroah-Hartman wrote:
> > > I don't maintain 3.18-stable :)
> > >
> > > thanks,
> > >
> > > greg k-h
> > >
> >
> > Thanks. My bad.
> >
> >
On Tue, 2016-12-13 at 08:33 -0800, Randy Dunlap wrote:
> On 12/13/16 08:30, Greg Kroah-Hartman wrote:
> > I don't maintain 3.18-stable :)
> >
> > thanks,
> >
> > greg k-h
> >
>
> Thanks. My bad.
>
> adding Sasha.
This was all covered here:
https://www.spinics.net/lists/stable/msg150608.html
On 12/13/16 08:30, Greg Kroah-Hartman wrote:
> On Tue, Dec 13, 2016 at 08:08:27AM -0800, Randy Dunlap wrote:
>> [adding other lists + gregkh]
>>
>>
>> On 12/13/16 02:56, Dashi DS1 Cao wrote:
>>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>>> ++
On Tue, Dec 13, 2016 at 08:08:27AM -0800, Randy Dunlap wrote:
> [adding other lists + gregkh]
>
>
> On 12/13/16 02:56, Dashi DS1 Cao wrote:
> > --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> > +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> > @@ -1614,16 +16
[adding other lists + gregkh]
On 12/13/16 02:56, Dashi DS1 Cao wrote:
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -1614,16 +1614,13 @@ megasas_queue_command(struct Scsi_Host *shost, struct
> scsi_cmnd *scmd)
>
case parameters aren't specified and
> some drivers support automatic configuration (e.g. PNP or PCI) in
> addition to manually coded parameters.
>
> This patch annotates drivers in drivers/scsi/.
>
> Suggested-by: One Thousand Gnomes <gno...@lxorguk.ukuu.org.uk>
> Sign
drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/scsi/.
Suggested-by: One Thousand Gnomes <gno...@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowe...@redhat.com>
cc: "Juergen
Hi,
Using a static bug finder (EBA - https://github.com/models-team/eba) I
may have found a double spin_lock_irqsave bug in Linux 4.8's
drivers/scsi/megaraid/megaraid_mbox.c.
The forward trace is as follows:
1. Starting in function `megaraid_reset_handler' at 2571;
(see
https://github.com
Hi!
There is a potential data race in drivers/scsi/mvumi.ko.
Regard such case:
Thread 1Thread 2
...
-> mvumi_reset_host_9500 -
is called without any locking
-> mvumi_wait_for_outstanding
->mvumi_start
->mvumi_che
Hi!
There is a potential data race in drivers/scsi/megaraid.ko
Regards such case:
Thread 1Thread 2
... ...
-> megaraid_probe_one
-> request_irq- now an interrupt may
er...@vger.kernel.org>, dcb...@hotmail.com
> Sent: Monday, August 8, 2016 9:46:53 AM
> Subject: linux-4.8-rc1/drivers/scsi/sd.c:317: pointless test ?
>
> Hello there,
>
> linux-4.8-rc1/drivers/scsi/sd.c:317]: (style) Unsigned variable 'val'
> can't be negative
Hello there,
linux-4.8-rc1/drivers/scsi/sd.c:317]: (style) Unsigned variable 'val'
can't be negative so it is unnecessary to test it.
Source code is
if (val >= 0 && val <= SD_DIF_TYPE3_PROTECTION)
but
unsigned int val;
Suggest new code
if (val <= SD_DIF_TYPE3_PRO
AM
>> To: linux-scsi@vger.kernel.org
>> Subject: Re: Double-Fetch bug in Linux-4.5/drivers/scsi/aacraid/commctrl.c
>> Hi,
>>
>> Will anyone bother to confirm and fix this problem I reported last time? From
>> the point of view of security, I think it should be fixed.
>
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Pengfei Wang
> Sent: Thursday, July 07, 2016 7:00 AM
> To: linux-scsi@vger.kernel.org
> Subject: Re: Double-Fetch bug in Linux-4.5/drivers/scsi/aacra
ein...@gmail.com> 写道:
Hi,
在 2016年4月26日,下午3:46,James Bottomley <james.bottom...@hansenpartnership.com> 写道:
On Tue, 2016-04-26 at 13:35 +0100, Pengfei Wang wrote:
Hello,
I found this Double-Fetch bug in
Linux-4.5/drivers/scsi/aacraid/commctrl.c when I was examining the
source code.
https://bugzilla.kernel.org/show_bug.cgi?id=120371
Bug ID: 120371
Summary: UBSAN splat in drivers/scsi/scsi_devinfo.c:458:21
Product: IO/Storage
Version: 2.5
Kernel Version: 4.7.0-rc3
Hardware: All
OS: Linux
On Fri, Jun 10, 2016 at 02:43:52PM -0700, James Bottomley wrote:
> OK, I checked: snic and fnic use SCSI_NO_TAG but they don't save
> anything in current_cmnd, so they can't rely on the original behaviour.
> I think we'll be safe with a local change in 53c700.c
Please move the current_cmnd field
:0:6: Domain Validation skipping write tests
[ 13.473831] scsi target0:0:6: Ending Domain Validation
[ 13.557116] scsi 0:0:6:1: tag#0 Disabling Tag Command Queuing
[ 13.637379] st: Version 20160209, fixed bufsize 32768, s/g segs 256
[ 13.746803] sd 0:0:6:0: Attached scsi generic sg0 ty
On Fri, 2016-06-10 at 14:33 -0700, James Bottomley wrote:
> On Fri, 2016-06-10 at 14:01 -0700, James Bottomley wrote:
> > On Fri, 2016-06-10 at 16:58 -0400, Ewan D. Milne wrote:
> > > I'm not sure if this is the problem, but the tagging changes to
> > > scsi_tcq.h may have altered the 53c700
: Thu Oct 8 09:28:04 2015 +0100
scsi: use host wide tags by default
Again. This time because it's transformation of the handling of
SCSI_NO_TAG is wrong. You can't replace the return sdev->current_cmnd
original in scsi_find_tag with the NULL return in scsi_find_host_tag.
I think this change
On Fri, 2016-06-10 at 16:58 -0400, Ewan D. Milne wrote:
> I'm not sure if this is the problem, but the tagging changes to
> scsi_tcq.h may have altered the 53c700 driver's assumptions.
> In one case it sets sdev->current_cmnd and then some of the
> tagging calls would return it if the tag was
t; [0.00] model 9000/715
> >> [0.00] Total Memory: 160 MB
> >> ...
> >> [ 43.18] SCSI subsystem initialized
> >> [ 45.076000] 53c700: Version 2.8 By james.bottom...@hansenpartnership.com
> >> [ 45.156000] scsi0: 53c710 rev 2
>
al Memory: 160 MB
>> ...
>> [ 43.18] SCSI subsystem initialized
>> [ 45.076000] 53c700: Version 2.8 By james.bottom...@hansenpartnership.com
>> [ 45.156000] scsi0: 53c710 rev 2
>> [ 46.204000] scsi host0: LASI SCSI 53c700
>> [ 58.268000] scsi 0:0:6:0: no saved request fo
rship.com
> [ 45.156000] scsi0: 53c710 rev 2
> [ 46.204000] scsi host0: LASI SCSI 53c700
> [ 58.268000] scsi 0:0:6:0: no saved request for untagged cmd
> [ 58.336000] [ cut here ]----
> [ 58.392000] kernel BUG at
> /build/linux-XAODSw/linux-4.6.1/drive
Found another UBSAN warning on 32-bit powerpc, during pata_macio driver
initialization. I hope it is not a false positive :)
[2.540935]
[2.547807] UBSAN: Undefined behaviour in drivers/scsi/scsi_devinfo.c
rd
> > > Adaptec
> > > SCSI
> > > controller, once during bootup.
> > >
> > > [4.896307]
> > > =
> > > ====
> > > ===
> > > [4.896471] UBSAN: Und
bootup.
>>
>> [4.896307]
>> =
>> ===
>> [ 4.896471] UBSAN: Undefined behaviour in
>> drivers/scsi/aic7xxx/aic7xxx_core.c:2831:31
>> [4.896629] shift exponent -1 is negative
>
> Is this
gt; [4.896471] UBSAN: Undefined behaviour in
> drivers/scsi/aic7xxx/aic7xxx_core.c:2831:31
> [4.896629] shift exponent -1 is negative
Is this some sort of false positive? The shift in question is
devinfo->target_mask = (0x01 << devinfo
This is from a dual-AthlonMP 32-bit x86 system with onboard Adaptec SCSI
controller, once during bootup.
[4.896307]
[4.896471] UBSAN: Undefined behaviour in
drivers/scsi/aic7xxx/aic7xxx_core.c:2831:31
-- Forwarded message --
From: James Bottomley <james.bottom...@hansenpartnership.com>
Date: 2016-04-26 15:46 GMT+01:00
Subject: Re: Double-Fetch bug in Linux-4.5/drivers/scsi/aacraid/commctrl.c
To: Pengfei Wang <wpengfein...@gmail.com>, linux-scsi@vger.kernel.org
On Tue, 2016-04-26 at
On Tue, 2016-04-26 at 13:35 +0100, Pengfei Wang wrote:
> Hello,
>
> I found this Double-Fetch bug in
> Linux-4.5/drivers/scsi/aacraid/commctrl.c when I was examining the
> source code.
>
> In function ioctl_send_fib(), the driver fetches user space data by
> pointe
Hello,
I found this Double-Fetch bug in
Linux-4.5/drivers/scsi/aacraid/commctrl.c when I was examining the
source code.
In function ioctl_send_fib(), the driver fetches user space data by
pointer arg via copy_from_user(), and this happens twice at line 81
and line 116 respectively. The first
https://bugzilla.kernel.org/show_bug.cgi?id=116751
--- Comment #1 from Pengfei Wang ---
Created attachment 214111
--> https://bugzilla.kernel.org/attachment.cgi?id=214111=edit
source file
--
You are receiving this mail because:
You are watching the assignee of the
1 - 100 of 1098 matches
Mail list logo