An issue was discovered in drivers/mtd/ubi/cdev.c in the Linux kernel 6.2. There is a divide-by-zero error in do_div(sz,mtd->erasesize), used indirectly by ctrl_cdev_ioctl, when mtd->erasesize is 0.

From: Richard Weinberger <richard@nod.at>
To: Yu Hao <yhao016@ucr.edu>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: BUG: divide error in ubi\_attach\_mtd\_dev
Date: Tue, 18 Apr 2023 08:30:47 +0200 (CEST)	\[thread overview\]
Message-ID: <687864524.118195.1681799447034.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <CA+UBctDsHRpkLG5ppdiuV8Msn4Dx-ZJ2xDrxfa48VMb7ZE+xBA@mail.gmail.com\>

Yu Hao,

----- Ursprüngliche Mail -----
\> Von: "Yu Hao" <yhao016@ucr.edu>
>> ubi: mtd0 is already attached to ubi0
>> ubi7: attaching mtd147
>> divide error: 0000 \[#1\] PREEMPT SMP KASAN
>> CPU: 0 PID: 20023 Comm: syz-executor.0 Not tainted 6.2.0 #6
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>> 1.13.0-1ubuntu1.1 04/01/2014
>> RIP: 0010:mtd\_div\_by\_eb include/linux/mtd/mtd.h:580 \[inline\]
>> RIP: 0010:io\_init drivers/mtd/ubi/build.c:620 \[inline\]
>> RIP: 0010:ubi\_attach\_mtd\_dev+0x77f/0x2fe0 drivers/mtd/ubi/build.c:955
>> Code: fc ff df 48 c1 ea 03 0f b6 14 02 4c 89 f0 83 e0 07 83 c0 03 38
>> d0 7c 08 84 d2 0f 85 1f 25 00 00 41 8b 4c 24 10 48 89 d8 31 d2 <48> f7
>> f1 48 89 c3 e8 b6 f3 1b fc 48 8d 85 40 17 00 00 48 89 c2 48
>> RSP: 0018:ffffc9000be0fd30 EFLAGS: 00010246
>> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
>> RDX: 0000000000000000 RSI: ffff888047a49d40 RDI: 0000000000000002
>> RBP: ffff888024e1c000 R08: 0000000000000016 R09: fffff520017c1f47
>> R10: ffffc9000be0fa37 R11: fffff520017c1f46 R12: ffff88806545a000
>> R13: 0000000000000000 R14: ffff88806545a010 R15: 0000000000000007
>> FS:  00007fd45e85c700(0000) GS:ffff88802ca00000(0000) knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 00007f64aeef53a4 CR3: 000000004f39a000 CR4: 0000000000350ef0
>> Call Trace:
>>  <TASK>
>>  ctrl\_cdev\_ioctl+0x303/0x3a0 drivers/mtd/ubi/cdev.c:1043
What kind of MTD you attaching?
Has it erasesize 0?

Thanks,
//richard

WARNING: multiple messages have this Message-ID

From: Richard Weinberger <richard@nod.at>
To: Yu Hao <yhao016@ucr.edu>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	 linux-mtd <linux-mtd@lists.infradead.org>,
	 linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: BUG: divide error in ubi\_attach\_mtd\_dev
Date: Tue, 18 Apr 2023 08:30:47 +0200 (CEST)	\[thread overview\]
Message-ID: <687864524.118195.1681799447034.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <CA+UBctDsHRpkLG5ppdiuV8Msn4Dx-ZJ2xDrxfa48VMb7ZE+xBA@mail.gmail.com\>

Yu Hao,

----- Ursprüngliche Mail -----
\> Von: "Yu Hao" <yhao016@ucr.edu>
>> ubi: mtd0 is already attached to ubi0
>> ubi7: attaching mtd147
>> divide error: 0000 \[#1\] PREEMPT SMP KASAN
>> CPU: 0 PID: 20023 Comm: syz-executor.0 Not tainted 6.2.0 #6
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>> 1.13.0-1ubuntu1.1 04/01/2014
>> RIP: 0010:mtd\_div\_by\_eb include/linux/mtd/mtd.h:580 \[inline\]
>> RIP: 0010:io\_init drivers/mtd/ubi/build.c:620 \[inline\]
>> RIP: 0010:ubi\_attach\_mtd\_dev+0x77f/0x2fe0 drivers/mtd/ubi/build.c:955
>> Code: fc ff df 48 c1 ea 03 0f b6 14 02 4c 89 f0 83 e0 07 83 c0 03 38
>> d0 7c 08 84 d2 0f 85 1f 25 00 00 41 8b 4c 24 10 48 89 d8 31 d2 <48> f7
>> f1 48 89 c3 e8 b6 f3 1b fc 48 8d 85 40 17 00 00 48 89 c2 48
>> RSP: 0018:ffffc9000be0fd30 EFLAGS: 00010246
>> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
>> RDX: 0000000000000000 RSI: ffff888047a49d40 RDI: 0000000000000002
>> RBP: ffff888024e1c000 R08: 0000000000000016 R09: fffff520017c1f47
>> R10: ffffc9000be0fa37 R11: fffff520017c1f46 R12: ffff88806545a000
>> R13: 0000000000000000 R14: ffff88806545a010 R15: 0000000000000007
>> FS:  00007fd45e85c700(0000) GS:ffff88802ca00000(0000) knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 00007f64aeef53a4 CR3: 000000004f39a000 CR4: 0000000000350ef0
>> Call Trace:
>>  <TASK>
>>  ctrl\_cdev\_ioctl+0x303/0x3a0 drivers/mtd/ubi/cdev.c:1043
What kind of MTD you attaching?
Has it erasesize 0?

Thanks,
//richard

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

next prev parent reply	other threads:\[~2023-04-18  6:30 UTC|newest\]

**Thread overview:** 21+ messages / expand\[flat|nested\]  mbox.gz  Atom feed  top
2023-04-18  5:10 BUG: divide error in ubi\_attach\_mtd\_dev Yu Hao
2023-04-18  5:16 \` Yu Hao
2023-04-18  5:16   \` Yu Hao
**2023-04-18  6:30   \` Richard Weinberger \[this message\]**
2023-04-18  6:30     \` Richard Weinberger
2023-04-20  4:49     \` Zhihao Cheng
2023-04-20  4:49       \` Zhihao Cheng
2023-04-20 17:27       \` Yu Hao
2023-04-20 17:27         \` Yu Hao
2023-04-20 17:33         \` Richard Weinberger
2023-04-20 17:33           \` Richard Weinberger
2023-04-20 18:14           \` Yu Hao
2023-04-20 18:14             \` Yu Hao
2023-04-20 20:36             \` Richard Weinberger
2023-04-20 20:36               \` Richard Weinberger
2023-04-23  3:20               \` Zhihao Cheng
2023-04-23  3:20                 \` Zhihao Cheng
2023-04-23  8:02                 \` Richard Weinberger
2023-04-23  8:02                   \` Richard Weinberger
2023-04-23  9:13                   \` Zhihao Cheng
2023-04-23  9:13                     \` Zhihao Cheng

**Reply instructions:**

You may reply publicly to this message via plain-text email
using any one of the following methods:

\* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting\_style#Interleaved\_style

\* Reply using the **\--to**, **\--cc**, and **\--in-reply-to**
  switches of git-send-email(1):

  git send-email \\
    --in-reply-to=687864524.118195.1681799447034.JavaMail.zimbra@nod.at \\
    --to=richard@nod.at \\
    --cc=linux-kernel@vger.kernel.org \\
    --cc=linux-mtd@lists.infradead.org \\
    --cc=miquel.raynal@bootlin.com \\
    --cc=vigneshr@ti.com \\
    --cc=yhao016@ucr.edu \\
    /path/to/YOUR\_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

\* If your mail client supports setting the **In-Reply-To** header
  via mailto: links, try the mailto: link

Be sure your reply has a **Subject:** header at the top and a blank line before the message body.

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.

CVE-2023-31085: Re: BUG: divide error in ubi_attach_mtd_dev

An issue was discovered in drivers/bluetooth/hci_ldisc.c in the Linux kernel 6.2. In hci_uart_tty_ioctl, there is a race condition between HCIUARTSETPROTO and HCIUARTGETPROTO. HCI_UART_PROTO_SET is set before hu->proto is set. A NULL pointer dereference may occur.

From: Yu Hao <yhao016@ucr.edu>
To: marcel@holtmann.org, johan.hedberg@gmail.com,
	luiz.dentz@gmail.com, linux-bluetooth@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: BUG: general protection fault in hci\_uart\_tty\_ioctl
Date: Mon, 17 Apr 2023 21:59:12 -0700	\[thread overview\]
Message-ID: <CA+UBctC3p49aTgzbVgkSZ2+TQcqq4fPDO7yZitFT5uBPDeCO2g@mail.gmail.com> (raw)

Hello,

We found the following issue using syzkaller on Linux v6.2.0.

In function \`hci\_uart\_tty\_ioctl\`, there is a race condition
between HCIUARTSETPROTO and HCIUARTGETPROTO.
HCI\_UART\_PROTO\_SET is set before \`hu->proto\` is set.
Thus it may dereference a null pointer.

The full report including the Syzkaller reproducer & C reproducer:
https://gist.github.com/ZHYfeng/a3e3ff2bdfea5ed5de5475f0b54d55cb

The brief report is below:

Syzkaller hit 'general protection fault in hci\_uart\_tty\_ioctl' bug.

general protection fault, probably for non-canonical address
0xdffffc0000000000: 0000 \[#1\] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range \[0x0000000000000000-0x0000000000000007\]
CPU: 0 PID: 8770 Comm: syz-executor.0 Not tainted 6.2.0 #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:hci\_uart\_tty\_ioctl+0x244/0xc20 drivers/bluetooth/hci\_ldisc.c:774
Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 cf 08 00 00 48 8b 9b
b8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <0f> b6
04 02 84 c0 74 08 3c 03 0f 8e 5f 08 00 00 44 8b 23 e9 14 ff
RSP: 0018:ffffc900022a7d10 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff8710057c
RDX: 0000000000000000 RSI: ffff888046df8000 RDI: ffff88801cf510b8
RBP: 0000000000000001 R08: 0000000000000001 R09: ffffed10039ea204
R10: ffff88801cf5101f R11: ffffed10039ea203 R12: ffff8880204eb000
R13: 0000000000000000 R14: ffffffffffffffe7 R15: 00000000800401c0
FS:  00007f203e7dd700(0000) GS:ffff88802ca00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005587ec7f32d8 CR3: 000000004629e000 CR4: 0000000000350ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 tty\_ioctl+0xac0/0x1420 drivers/tty/tty\_io.c:2784
 vfs\_ioctl fs/ioctl.c:51 \[inline\]
 \_\_do\_sys\_ioctl fs/ioctl.c:870 \[inline\]
 \_\_se\_sys\_ioctl fs/ioctl.c:856 \[inline\]
 \_\_x64\_sys\_ioctl+0x198/0x210 fs/ioctl.c:856
 do\_syscall\_x64 arch/x86/entry/common.c:50 \[inline\]
 do\_syscall\_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd
RIP: 0033:0x7f203f0902fd
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f203e7dcc58 EFLAGS: 00000246 ORIG\_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f203f1bc020 RCX: 00007f203f0902fd
RDX: 0000000000000000 RSI: 00000000800455c9 RDI: 0000000000000003
RBP: 00007f203f0fec89 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffee4615aef R14: 00007ffee4615ca0 R15: 00007f203e7dcdc0
 </TASK>

                 reply	other threads:\[~2023-04-18  5:00 UTC|newest\]

**Thread overview:** \[no followups\] expand\[flat|nested\]  mbox.gz  Atom feed

**Reply instructions:**

You may reply publicly to this message via plain-text email
using any one of the following methods:

\* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting\_style#Interleaved\_style

\* Reply using the **\--to**, **\--cc**, and **\--in-reply-to**
  switches of git-send-email(1):

  git send-email \\
    --in-reply-to=CA+UBctC3p49aTgzbVgkSZ2+TQcqq4fPDO7yZitFT5uBPDeCO2g@mail.gmail.com \\
    --to=yhao016@ucr.edu \\
    --cc=johan.hedberg@gmail.com \\
    --cc=linux-bluetooth@vger.kernel.org \\
    --cc=linux-kernel@vger.kernel.org \\
    --cc=luiz.dentz@gmail.com \\
    --cc=marcel@holtmann.org \\
    /path/to/YOUR\_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

\* If your mail client supports setting the **In-Reply-To** header
  via mailto: links, try the mailto: link

Be sure your reply has a **Subject:** header at the top and a blank line before the message body.

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.

CVE-2023-31083: BUG: general protection fault in hci_uart_tty_ioctl

An issue was discovered in drivers/tty/n_gsm.c in the Linux kernel 6.2. There is a sleeping function called from an invalid context in gsmld_write, which will block the kernel.

From: Yu Hao <yhao016@ucr.edu>
To: gregkh@linuxfoundation.org, jirislaby@kernel.org,
	linux-kernel@vger.kernel.org
Subject: BUG: sleeping function called from invalid context in \_\_might\_resched
Date: Mon, 17 Apr 2023 20:44:30 -0700	\[thread overview\]
Message-ID: <CA+UBctCZok5FSQ=LPRA+A-jocW=L8FuMVZ\_7MNqhh483P5yN8A@mail.gmail.com> (raw)

Hello,

We found the following issue using syzkaller on Linux v6.2.0.
A similar bug was found in function \`n\_hdlc\_tty\_wakeup\` before.
(https://groups.google.com/g/syzkaller-bugs/c/XAyZCUO-eAY/m/Lpj5SzDNAwAJ)
Now it is found in a different caller \`gsmld\_write\`.
It needs to fix the bug in \`gsmld\_write\` again.

The full report including the C reproducer:
https://gist.github.com/ZHYfeng/eb410de5d7aec253d8c83cf34e628d6a

The brief report is below:

Syzkaller hit 'BUG: sleeping function called from invalid context in
\_\_might\_resched' bug.

BUG: sleeping function called from invalid context at
kernel/printk/printk.c:2656
in\_atomic(): 1, irqs\_disabled(): 1, non\_block: 0, pid: 9817, name: (agetty)
preempt\_count: 1, expected: 0
RCU nest depth: 0, expected: 0
3 locks held by (agetty)/9817:
 #0: ffff888017797098 (&tty->ldisc\_sem){++++}-{0:0}, at:
tty\_ldisc\_ref\_wait+0x27/0x80 drivers/tty/tty\_ldisc.c:244
 #1: ffff888017797130 (&tty->atomic\_write\_lock){+.+.}-{3:3}, at:
tty\_write\_lock+0x23/0x90 drivers/tty/tty\_io.c:944
 #2: ffff888046ee93e0 (&gsm->tx\_lock){....}-{2:2}, at:
gsmld\_write+0x63/0x150 drivers/tty/n\_gsm.c:3410
irq event stamp: 3146
hardirqs last  enabled at (3145): \[<ffffffff8a0f3a32>\]
syscall\_enter\_from\_user\_mode+0x22/0xb0 kernel/entry/common.c:111
hardirqs last disabled at (3146): \[<ffffffff8a12e6b3>\]
\_\_raw\_spin\_lock\_irqsave include/linux/spinlock\_api\_smp.h:108 \[inline\]
hardirqs last disabled at (3146): \[<ffffffff8a12e6b3>\]
\_raw\_spin\_lock\_irqsave+0x53/0x60 kernel/locking/spinlock.c:162
softirqs last  enabled at (0): \[<ffffffff814b301d>\]
copy\_process+0x1a8d/0x7490 kernel/fork.c:2211
softirqs last disabled at (0): \[<0000000000000000>\] 0x0
Preemption disabled at:
\[<0000000000000000>\] 0x0
CPU: 0 PID: 9817 Comm: (agetty) Not tainted 6.2.0 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
 <TASK>
 \_\_dump\_stack lib/dump\_stack.c:88 \[inline\]
 dump\_stack\_lvl+0xcd/0x134 lib/dump\_stack.c:106
 \_\_might\_resched.cold+0x222/0x26b kernel/sched/core.c:10045
 console\_lock+0x1c/0x80 kernel/printk/printk.c:2656
 do\_con\_write+0x114/0x1e40 drivers/tty/vt/vt.c:2908
 con\_write+0x26/0x40 drivers/tty/vt/vt.c:3295
 gsmld\_write+0xd0/0x150 drivers/tty/n\_gsm.c:3413
 do\_tty\_write drivers/tty/tty\_io.c:1018 \[inline\]
 file\_tty\_write.isra.0+0x48f/0x820 drivers/tty/tty\_io.c:1089
 call\_write\_iter include/linux/fs.h:2189 \[inline\]
 new\_sync\_write fs/read\_write.c:491 \[inline\]
 vfs\_write+0x9cf/0xd90 fs/read\_write.c:584
 ksys\_write+0x12c/0x250 fs/read\_write.c:637
 do\_syscall\_x64 arch/x86/entry/common.c:50 \[inline\]
 do\_syscall\_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd
RIP: 0033:0x7f5538c101b0
Code: 2e 0f 1f 84 00 00 00 00 00 90 48 8b 05 19 7e 20 00 c3 0f 1f 84
00 00 00 00 00 83 3d 19 c2 20 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d
01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ae fc ff ff 48 89 04 24
RSP: 002b:00007ffdb4aadbe8 EFLAGS: 00000246 ORIG\_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000000000a RCX: 00007f5538c101b0
RDX: 000000000000000a RSI: 00007f553b13ccbe RDI: 0000000000000003
RBP: 00007f553b13ccbe R08: 00007ffdb4aadba0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003
R13: 0000000000000000 R14: ffffffffffffffff R15: 00007ffdb4aadea0
 </TASK>

next             reply	other threads:\[~2023-04-18  3:45 UTC|newest\]

**Thread overview:** 4+ messages / expand\[flat|nested\]  mbox.gz  Atom feed  top
**2023-04-18  3:44 Yu Hao \[this message\]**
2023-04-18  6:09 \` BUG: sleeping function called from invalid context in \_\_might\_resched Greg KH
2023-04-18  6:51 \` Jiri Slaby
2023-04-20  8:21   \` D. Starke

**Reply instructions:**

You may reply publicly to this message via plain-text email
using any one of the following methods:

\* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting\_style#Interleaved\_style

\* Reply using the **\--to**, **\--cc**, and **\--in-reply-to**
  switches of git-send-email(1):

  git send-email \\
    --in-reply-to='CA+UBctCZok5FSQ=LPRA+A-jocW=L8FuMVZ\_7MNqhh483P5yN8A@mail.gmail.com' \\
    --to=yhao016@ucr.edu \\
    --cc=gregkh@linuxfoundation.org \\
    --cc=jirislaby@kernel.org \\
    --cc=linux-kernel@vger.kernel.org \\
    /path/to/YOUR\_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

\* If your mail client supports setting the **In-Reply-To** header
  via mailto: links, try the mailto: link

Be sure your reply has a **Subject:** header at the top and a blank line before the message body.

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.

CVE-2023-31082: BUG: sleeping function called from invalid context in __might_resched

An issue was discovered in drivers/media/test-drivers/vidtv/vidtv_bridge.c in the Linux kernel 6.2. There is a NULL pointer dereference in vidtv_mux_stop_thread. In vidtv_stop_streaming, after dvb->mux=NULL occurs, it executes vidtv_mux_stop_thread(dvb->mux).

From: Yu Hao <yhao016@ucr.edu>
To: dwlsalmeida@gmail.com, mchehab@kernel.org,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: BUG: general protection fault in vidtv\_mux\_stop\_thread
Date: Mon, 17 Apr 2023 21:20:46 -0700	\[thread overview\]
Message-ID: <CA+UBctDXyiosaiR7YNKCs8k0aWu4gU+YutRcnC+TDJkXpHjQag@mail.gmail.com> (raw)

Hello,

We found the following issue using syzkaller on Linux v6.2.0.

It seems to be a currency bug.
In the function \`vidtv\_stop\_streaming\`, after \`dvb->mux = NULL;\` was executed,
it executes \`vidtv\_mux\_stop\_thread(dvb->mux);\` again.
Need to check the \`dvb->mux==NULL\` before \`vidtv\_mux\_stop\_thread(dvb->mux);\`
in function \`vidtv\_stop\_streaming\`

The full report including the Syzkaller reproducer:
https://gist.github.com/ZHYfeng/c61f87ed42d4c44344d4addefd81cc1f

The brief report is below:

Syzkaller hit 'general protection fault in vidtv\_mux\_stop\_thread' bug.

general protection fault, probably for non-canonical address
0xdffffc0000000025: 0000 \[#1\] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range \[0x0000000000000128-0x000000000000012f\]
CPU: 0 PID: 9614 Comm: syz-executor.0 Not tainted 6.2.0 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:vidtv\_mux\_stop\_thread+0x27/0x80
drivers/media/test-drivers/vidtv/vidtv\_mux.c:471
Code: 00 00 00 0f 1f 44 00 00 55 53 48 89 fb e8 51 23 b2 fa 48 8d bb
28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6
04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8
RSP: 0018:ffffc900068ffca0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff86cec666
RDX: 0000000000000025 RSI: ffff888020378000 RDI: 0000000000000128
RBP: ffff888019d652f8 R08: 0000000000000000 R09: fffffbfff1ce4fab
R10: ffffc900068ffcb8 R11: fffffbfff1ce4faa R12: ffff888019d65260
R13: ffffffff8dc6f3c0 R14: ffffc9000713a6c0 R15: ffff888019d64a70
FS:  0000555555b72940(0000) GS:ffff88802ca00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000555555c00d88 CR3: 000000001e832000 CR4: 0000000000350ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 vidtv\_stop\_streaming
drivers/media/test-drivers/vidtv/vidtv\_bridge.c:209 \[inline\]
 vidtv\_stop\_feed+0x14e/0x250 drivers/media/test-drivers/vidtv/vidtv\_bridge.c:252
 dmx\_section\_feed\_stop\_filtering+0x91/0x150
drivers/media/dvb-core/dvb\_demux.c:1000
 dvb\_dmxdev\_feed\_stop+0x203/0x280 drivers/media/dvb-core/dmxdev.c:486
 dvb\_dmxdev\_filter\_stop.part.0+0x1e7/0x340 drivers/media/dvb-core/dmxdev.c:559
 dvb\_dmxdev\_filter\_stop drivers/media/dvb-core/dmxdev.c:552 \[inline\]
 dvb\_dmxdev\_filter\_free drivers/media/dvb-core/dmxdev.c:840 \[inline\]
 dvb\_demux\_release+0xd6/0x5c0 drivers/media/dvb-core/dmxdev.c:1246
 \_\_fput+0x281/0xa90 fs/file\_table.c:320
 task\_work\_run+0x170/0x270 kernel/task\_work.c:179
 resume\_user\_mode\_work include/linux/resume\_user\_mode.h:49 \[inline\]
 exit\_to\_user\_mode\_loop kernel/entry/common.c:171 \[inline\]
 exit\_to\_user\_mode\_prepare+0x262/0x270 kernel/entry/common.c:203
 \_\_syscall\_exit\_to\_user\_mode\_work kernel/entry/common.c:285 \[inline\]
 syscall\_exit\_to\_user\_mode+0x19/0x50 kernel/entry/common.c:296
 do\_syscall\_64+0x42/0xb0 arch/x86/entry/common.c:86
 entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd
RIP: 0033:0x7fe950c40dcb
Code: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c
24 0c e8 63 fc ff ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d
00 f0 ff ff 77 2f 44 89 c7 89 44 24 0c e8 a1 fc ff ff 8b 44
RSP: 002b:00007ffd3d403e80 EFLAGS: 00000293 ORIG\_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 0000000000000004 RCX: 00007fe950c40dcb
RDX: 0000001b31220000 RSI: 0000000000000001 RDI: 0000000000000003
RBP: 0000000000000001 R08: 0000000000000000 R09: 00007fe950dd0450
R10: 00007ffd3d403fc0 R11: 0000000000000293 R12: 00007fe950dd0448
R13: 00007fe950dd0450 R14: 00007fe950dcbf60 R15: 000000000001c14f
 </TASK>

                 reply	other threads:\[~2023-04-18  4:22 UTC|newest\]

**Thread overview:** \[no followups\] expand\[flat|nested\]  mbox.gz  Atom feed

**Reply instructions:**

You may reply publicly to this message via plain-text email
using any one of the following methods:

\* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting\_style#Interleaved\_style

\* Reply using the **\--to**, **\--cc**, and **\--in-reply-to**
  switches of git-send-email(1):

  git send-email \\
    --in-reply-to=CA+UBctDXyiosaiR7YNKCs8k0aWu4gU+YutRcnC+TDJkXpHjQag@mail.gmail.com \\
    --to=yhao016@ucr.edu \\
    --cc=dwlsalmeida@gmail.com \\
    --cc=linux-kernel@vger.kernel.org \\
    --cc=linux-media@vger.kernel.org \\
    --cc=mchehab@kernel.org \\
    /path/to/YOUR\_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

\* If your mail client supports setting the **In-Reply-To** header
  via mailto: links, try the mailto: link

Be sure your reply has a **Subject:** header at the top and a blank line before the message body.

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.

CVE-2023-31081: BUG: general protection fault in vidtv_mux_stop_thread

NVIDIA DGX-1 SBIOS contains a vulnerability in Bds, which may lead to code execution, denial of service, and escalation of privileges.

**Details**

This section provides a summary of potential vulnerabilities that this security update addresses and their impact. Descriptions use CWE™, and base scores and vectors use CVSS v3.1 standards.

**CVE ID**

**Description**

**Base Score**

**Vector**

CVE‑2023‑0209

NVIDIA DGX-1 SBIOS contains a vulnerability in the Uncore PEI module, where authentication of the code executed by SSA is missing, which may lead to arbitrary code execution, denial of service, escalation of privileges, information disclosure, data tampering, and SecureBoot bypass.

8.2

AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

CVE‑2023‑25505

NVIDIA DGX-1 BMC contains a vulnerability in the IPMI handler of the AMI MegaRAC BMC, where an attacker with the appropriate level of authorization can cause a buffer overflow, which may lead to denial of service, information disclosure, or arbitrary code execution.

7.8

AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

CVE‑2023‑25506

NVIDIA DGX-1 contains a vulnerability in Ofbd in AMI SBIOS, where a preconditioned heap can allow a user with elevated privileges to cause an access beyond the end of a buffer, which may lead to code execution, escalation of privileges, denial of service and information disclosure. The scope of the impact of this vulnerability can extend to other components.

7.5

AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

CVE‑2023‑25507

NVIDIA DGX-1 BMC contains a vulnerability in the SPX REST API, where an attacker with the appropriate level of authorization can inject arbitrary shell commands, which may lead to code execution, denial of service, information disclosure, and data tampering.

7.2

AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

CVE‑2023‑25508

NVIDIA DGX-1 BMC contains a vulnerability in the IPMI handler, where an attacker with the appropriate level of authorization can upload and download arbitrary files under certain circumstances, which may lead to denial of service, escalation of privileges, information disclosure, and data tampering.

6.7

AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

CVE‑2023‑25509

NVIDIA DGX-1 SBIOS contains a vulnerability in Bds, which may lead to code execution, denial of service, and escalation of privileges.

6.0

AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H

The NVIDIA risk assessment is based on an average of risk across a diverse set of installed systems and may not represent the true risk to your local installation. NVIDIA recommends consulting a security or IT professional to evaluate the risk to your specific configuration.

**Security Updates**

The following table lists the NVIDIA server products affected, firmware versions affected, and the updated version that includes this security update.

To protect your system, download and install this firmware update through the NVIDIA Enterprise Support Portal.

**CVE IDs Addressed**

**Hardware Platform**

**System**

**Affected Versions**

**Updated Version**

CVE‑2023‑25505  
CVE‑2023‑25508  
CVE‑2023‑25507

NVIDIA DGX-1 Servers

DGX-1

All BMC versions prior to 3.39.3

3.39.30

CVE‑2023‑0209  
CVE‑2023‑25506  
CVE‑2023‑25509

NVIDIA DGX-1 Servers

DGX-1

All SBIOS prior to S2W\_3A13

S2W\_3A13

**Notes**

*   Upgrade the NVIDIA DGX-1 firmware container to version 23.04.01 to get the updated firmware and SBIOS version listed in the table above. Firmware updates are available through the NVIDIA Enterprise Support Portal.

**Additional Information: Security Vulnerabilities Reported by Intel**

The following table lists potential security vulnerabilities in some Intel processors that have been reported by Intel. These vulnerabilities may allow escalation of privileges or denial of service. They are addressed in DGX-1 SBIOSS2W\_3A13.

**CVE ID**

**Severity**

**Summary**

CVE-2020-12357

High

Intel(R) Processors Privilege Escalation Vulnerability

CVE-2020-8670

High

Intel(R) Processors Privilege Escalation Vulnerability

CVE-2020-8700

High

Intel(R) Processors Privilege Escalation Vulnerability

CVE-2020-12359

High

Intel(R) Processors Privilege Escalation Vulnerability

CVE-2020-12358

Medium

Intel(R) Processors Denial of Service Vulnerability

CVE-2021-0095

Medium

Intel(R) Processors Denial of Service Vulnerability

CVE-2020-12360

Medium

Intel(R) Processors Privilege Escalation Vulnerability

CVE-2020-24486

Medium

Intel(R) Processors Denial of Service Vulnerability

**Get the Most Up to Date Product Security Information**

Visit the NVIDIA Product Security page to

*   Subscribe to security bulletin notifications
*   See the current list of NVIDIA security bulletins
*   Report a potential security issue in any NVIDIA supported product
*   Learn more about the vulnerability management process followed by the NVIDIA Product Security Incident Response Team (PSIRT)

**Revision History**

  

**Revision**

**Date**

**Description**

1.1

April 19, 2023

Modified CVE-2023-0209 description.

1.0

April 19, 2023

Initial release

**Support**

If you have any questions about this security bulletin, contact NVIDIA Support.

**Disclaimer**

ALL NVIDIA INFORMATION, DESIGN SPECIFICATIONS, REFERENCE BOARDS, FILES, DRAWINGS, DIAGNOSTICS, LISTS, AND OTHER DOCUMENTS (TOGETHER AND SEPARATELY, “MATERIALS”) ARE BEING PROVIDED “AS IS.” NVIDIA MAKES NO WARRANTIES, EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE WITH RESPECT TO THE MATERIALS, AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OR CONDITION OF TITLE, MERCHANTABILITY, SATISFACTORY QUALITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT, ARE HEREBY EXCLUDED TO THE MAXIMUM EXTENT PERMITTED BY LAW.

Information is believed to be accurate and reliable at the time it is furnished. However, NVIDIA Corporation assumes no responsibility for the consequences of use of such information or for any infringement of patents or other rights of third parties that may result from its use. No license is granted by implication or otherwise under any patent or patent rights of NVIDIA Corporation. Specifications mentioned in this publication are subject to change without notice. This publication supersedes and replaces all information previously supplied. NVIDIA Corporation products are not authorized for use as critical components in life support devices or systems without express written approval of NVIDIA Corporation.

CVE-2023-25509: NVIDIA Support

NVIDIA DGX-2 SBIOS contains a vulnerability where an attacker may modify the ServerSetup NVRAM variable at runtime by executing privileged code. A successful exploit of this vulnerability may lead to denial of service.

**Details**

This section provides a summary of potential vulnerabilities that this security update addresses and their impact. Descriptions use CWE™, and base scores and vectors use CVSS v3.1 standards.

**CVE ID**

**Description**

**Base Score**

**Vector**

CVE‑2022‑42274

NVIDIA BMC contains a vulnerability in the IPMI handler, where an attacker with the required privileges can cause a buffer overflow, which may lead to denial of service or code execution.

7.8

AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

CVE‑2022‑42280

NVIDIA BMC contains a vulnerability in the SPX REST authorization handler, where an unauthorized user can exploit a path traversal, which may lead to escalation of privileges.

7.1

AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

CVE‑2022‑42282

NVIDIA BMC contains a vulnerability in the SPX REST API, where an attacker with the required privileges can access arbitrary files, which may lead to information disclosure.

6.5

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

CVE‑2022‑42283

NVIDIA BMC contains a vulnerability in the IPMI handler, where an attacker with the required privileges can cause a buffer overflow, which may lead to denial of service or code execution.

6.4

AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H

CVE‑2022‑42286

NVIDIA DGX-2 SBIOS contains a vulnerability in Bds, which may lead to code execution, denial of service, or escalation of privileges.

6.0

AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H

CVE‑2022‑42287

NVIDIA BMC contains a vulnerability in the IPMI handler, where an attacker can upload and download arbitrary files under certain circumstances, which may lead to denial of service, escalation of privileges, information disclosure, or data tampering.

6.0

AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N

CVE‑2022‑42289

NVIDIA BMC contains a vulnerability in the SPX REST API, where an attacker with the required privileges can inject arbitrary shell commands, which may lead to code execution, denial of service, information disclosure, or data tampering.

7.2

AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

CVE‑2022‑42290

NVIDIA BMC contains a vulnerability in the SPX REST API, where an attacker with the required privileges can inject arbitrary shell commands, which may lead to code execution, denial of service, information disclosure, or data tampering.

7.2

AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

CVE‑2023‑0200

NVIDIA DGX-2 contains a vulnerability in OFBD where a user with high privileges and a pre-conditioned heap can cause an access beyond a buffers end, which may lead to code execution, escalation of privileges, denial of service, and information disclosure.

7.5

AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

CVE‑2023‑0201

NVIDIA DGX-2 SBIOS contains a vulnerability in Bds, where a user with high privileges can cause a write beyond the bounds of an indexable resource, which may lead to code execution, denial of service, compromised integrity, and information disclosure.

6.7

AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

CVE‑2023‑0202

NVIDIA DGX A100 SBIOS contains a vulnerability where an attacker may modify arbitrary memory of SMRAM by exploiting the GenericSio and LegacySmmSredir SMM APIs. A successful exploit of this vulnerability may lead to denial of service, escalation of privileges, and information disclosure.

7.5

AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

CVE‑2023‑0206

NVIDIA DGX A100 SBIOS contains a vulnerability where an attacker may modify arbitrary memory of SMRAM by exploiting the NVME SMM API. A successful exploit of this vulnerability may lead to denial of service, escalation of privileges, and information disclosure.

7.5

AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

CVE‑2023‑0207

NVIDIA DGX-2 SBIOS contains a vulnerability where an attacker may modify the ServerSetup NVRAM variable at runtime by executing privileged code. A successful exploit of this vulnerability may lead to denial of service.

7.5

AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

The NVIDIA risk assessment is based on an average of risk across a diverse set of installed systems and may not represent the true risk to your local installation. NVIDIA recommends consulting a security or IT professional to evaluate the risk to your specific configuration.

**Security Updates**

The following table lists the NVIDIA software products affected, versions affected, and the updated version that includes this security update.

To protect your system, download and install this firmware update through the NVIDIA Enterprise Support Portal.

**CVE IDs Addressed**

**Hardware Platform**

**System**

**Affected Versions**

**Updated Version**

**Firmware Container**

CVE‑2022‑42274  
CVE‑2022‑42280  
CVE‑2022‑42282  
CVE‑2022‑42283  
CVE‑2022‑42287  
CVE‑2023‑0200  
CVE‑2023‑0201

DGX-2

DGX-2

All BMC versions prior to 1.08.00

01.08.00

23.3.1

CVE‑2022‑42286  
CVE‑2022‑42289  
CVE‑2022‑42290  
CVE‑2023‑0207

DGX-2

DGX-2

All SBIOS versions prior to 0.33

0.33

23.3.1

CVE‑2023‑0202  
CVE‑2023‑0206

DGX A100

DGX A100

All SBIOS versions prior to 1.18

1.18

22.12.1

**AMI Security Advisory CVEs Addressed**

CVE‑2022‑40259  
CVE‑2022‑40242  
CVE‑2022‑2827

DGX Station A100

DGX Station A100

All BMC versions prior to 2.01.00

2.01.00

23.3.1

**Additional Information****Security Vulnerabilities Reported by AMI**

The following table lists potential security vulnerabilities in some AMI MegaRAC SP-X Baseboard Management Controllers that have been reported by AMI. These vulnerabilities may allow user enumeration, unauthorized access, or arbitrary code execution.

**CVE ID**

**Severity**

**Summary**

CVE‑2022‑40259

Critical

AMI MegaRAC Redfish Arbitrary Code Execution

CVE‑2022‑40242

High

MegaRAC Default Credentials Vulnerability

CVE‑2022‑2827

High

AMI MegaRAC User Enumeration Vulnerability

The following table lists the status of the NVIDIA response to these vulnerabilities for each NVIDIA DGX system.

**System**

**Status**

DGX-1

Not vulnerable - no response required

DGX-2

Not vulnerable - no response required

DGX A100

To be addressed in May 2023 as stated in NVIDIA DGX A100 Server and DGX Station A100 - December 2022

DGX Station

Not vulnerable - no response required

DGX Station A100

Addressed in this update

**Security Vulnerabilities Reported by Intel**

The following table lists potential security vulnerabilities in some Intel Processors that have been reported by Intel. These vulnerabilities may allow escalation of privileges or denial of service. They are addressed in DGX-2 SBIOS release version 0.33.

**CVE ID**

**Severity**

**Summary**

CVE‑2020‑12357

High

Intel(R) Processors Privilege Escalation Vulnerability

CVE‑2020‑8670

High

Intel(R) Processors Privilege Escalation Vulnerability

CVE‑2020‑8700

High

Intel(R) Processors Privilege Escalation Vulnerability

CVE‑2020‑12359

High

Intel(R) Processors Privilege Escalation Vulnerability

CVE‑2020‑12358

Medium

Intel(R) Processors Denial of Service Vulnerability

CVE‑2021‑0095

Medium

Intel(R) Processors Denial of Service Vulnerability

CVE‑2020‑12360

Medium

Intel(R) Processors Privilege Escalation Vulnerability

CVE‑2020‑24486

Medium

Intel(R) Processors Denial of Service Vulnerability

**Acknowledgements**

CVE‑2022‑42274, CVE‑2022‑42280, CVE‑2022‑42282, CVE‑2022‑42283, CVE‑2022‑42286, CVE‑2022‑42287, CVE‑2022‑42289, CVE‑2022‑42290: The NVIDIA Offensive Security Research (OSR) team reported these issues.

**Get the Most Up to Date Product Security Information**

Visit the NVIDIA Product Security page to

*   Subscribe to security bulletin notifications
*   See the current list of NVIDIA security bulletins
*   Report a potential security issue in any NVIDIA supported product
*   Learn more about the vulnerability management process followed by the NVIDIA Product Security Incident Response Team (PSIRT)

**Revision History**

  

**Revision**

**Date**

**Description**

1.0

March 23, 2023

Initial release

**Support**

If you have any questions about this security bulletin, contact NVIDIA Support.

**Disclaimer**

ALL NVIDIA INFORMATION, DESIGN SPECIFICATIONS, REFERENCE BOARDS, FILES, DRAWINGS, DIAGNOSTICS, LISTS, AND OTHER DOCUMENTS (TOGETHER AND SEPARATELY, “MATERIALS”) ARE BEING PROVIDED “AS IS.” NVIDIA MAKES NO WARRANTIES, EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE WITH RESPECT TO THE MATERIALS, AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OR CONDITION OF TITLE, MERCHANTABILITY, SATISFACTORY QUALITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT, ARE HEREBY EXCLUDED TO THE MAXIMUM EXTENT PERMITTED BY LAW.

Information is believed to be accurate and reliable at the time it is furnished. However, NVIDIA Corporation assumes no responsibility for the consequences of use of such information or for any infringement of patents or other rights of third parties that may result from its use. No license is granted by implication or otherwise under any patent or patent rights of NVIDIA Corporation. Specifications mentioned in this publication are subject to change without notice. This publication supersedes and replaces all information previously supplied. NVIDIA Corporation products are not authorized for use as critical components in life support devices or systems without express written approval of NVIDIA Corporation.

CVE-2023-0207: NVIDIA Support

While Intel is building more hardware protections directly into the chips, enterprises still need a strategy for applying security updates on these components.

Intel is taking a new tack with its latest commercial PC chips announced last month: Instead of touting speed and performance, the company is emphasizing the chip's security features.

The chip giant has been working with security vendors in recent years to implement hardware-level protections on the chips to protect laptops from ransomware and malware attacks. The new 13th Gen Intel Core vPro processors include under-the-hood improvements at the firmware and operating system levels that boost system protection and management, the company says.

Attackers will find it harder to compromise the firmware through hardware exploits because many of the new upgrades are in the chip's firmware and BIOS, and the chip's security layer contains prevention and detection capabilities. For example, there is a better handshake between the firmware and Microsoft's virtualization technology in Windows 11 to prevent intrusions, says Mike Nordquist, vice president and general manager of Intel Business Client Product Planning and Architecture. He notes that Hyper-V on Windows 11 works with vPro to store secrets and credentials in a virtual container.

"If you only have detection, you keep letting everyone in your front door. You are never really going to address the problem. You have to figure out how to close that front door," Nordquist says.

**Secure Enclaves on Chip**

Intel's vPro now provides the hooks for critical applications running on Windows 11 to be encrypted in memory through a feature called Total Memory Encryption-Multi-Key.

Microsoft provides the ability to encrypt storage drives, but it recently added the ability to encrypt data in memory. Intel's newer Core chips, code-named Raptor Lake, come ready for that feature; they have 16 memory slots in which applications can be encrypted, with separate keys needed to unlock the data.

The feature helps prevent side-channel attacks, which typically involve breaking into a chip and stealing unencrypted data from sources that include memory. Hackers would need a key to unlock the data, and isolating applications in 16 different slots makes it an even bigger challenge to steal data.

Applications are encrypted in virtual machines created in the memory slots, and system administrators can enable or disable the feature.

"We're not encrypting the entirety of the memory, because if you don't need to do it, it is basically going to impact performance," says Venky Venkateswaran, director of client product security and virtualization architecture and definition for Intel's Client Computing Group.

A new vPro technology to prevent security threats, TDT (threat detection technology), uses libraries baked into the chips to identify abnormal activity and security threats on a PC. The library assesses telemetry coming from CPUs that may be related to abnormal processing activity as a result of a security breach.

For example, the libraries can tell if a cryptocurrency mining application is calling on an abnormally high number of crypto instructions. That information is sent to security applications, which use that data in their engine to triage and stop threats.

The libraries have models tuned to weed out ransomware and other types of attack.

"We have low-level telemetry and an AI engine of sorts that can weed out the noise ... you don't want to have false positives," Venkateswaran says.

Intel is partnering with several antivirus vendors, including Microsoft, CrowdStrike, Eset, and Check Point Technologies, to integrate TDT features into security software. This way, the vendors get access to hardware telemetry to detect threats in virtual machines. For example, Eset Endpoint Security will be able to detect ransomware through Intel's performance monitoring unit (PMU), which sits underneath applications in the operating system.

**Patching Components**

Intel is working with PC makers to bring a standard methodology to patch PCs, and it is not putting all the eggs in one basket when it comes to securing systems. The focus is on establishing islands of security for different hardware components.

"There's no reason the BIOS needs to be able to have access to the OS memory. There is no value-add in it," Nordquist says. "So we actually deprivileged that at a base level ... and we did an enhanced level where we could really lock it down good. On vPro, that is a little bit better."

Attack vectors for PCs are different from servers and require a different security profile, he says.

"Before, PCs were designed to make sure the OS was protected. What if I want to protect something from the OS? What if I do not trust the hypervisor? I need the next level of security to deal with that," Nordquist says.

**Squashing Chip Bugs**

As a sign that Intel is serious about making hardware security a priority, the company last year awarded $935,751 in bug bounties to security researchers disclosing security flaws in its chips and firmware. The company has paid a total of $4 million since the inception of the program in 2017, according to its most recent annual security research report.

"These firmware updates are usually released on Intel's website, and the device vendor is responsible for distributing them. Some of them can be delivered automatically by Microsoft Windows Update, but only limited vendors can update their devices through it," says Alex Matrosov, founder of Binarly, whose firmware security platform helps people discover and patch hardware vulnerabilities. "CISOs should start paying more attention to threats and device ... security below the operating system. Every mature enterprise organization should invest in firmware security and specifically vulnerability management for their device security pasture."

Intel Prioritizes Security in Latest vPro Chips

A vulnerability was found in compare_netdev_and_ip in drivers/infiniband/core/cma.c in RDMA in the Linux Kernel. The improper cleanup results in out-of-boundary read, where a local user can utilize this problem to crash the system or escalation of privilege.

From: Patrisious Haddad <phaddad@xxxxxxxxxx>

resolve\_prepare\_src() changes the destination address of the id,
regardless of success, and on failure zeroes it out.

Instead on function failure keep the original destination address
of the id.

Since the id could have been already added to the cm id tree and
zeroing its destination address, could result in a key mismatch or
multiple ids having the same key(zero) in the tree which could lead to:

BUG: KASAN: slab-out-of-bounds in compare\_netdev\_and\_ip.isra.0+0x25/0x120 drivers/infiniband/core/cma.c:473
Read of size 4 at addr ffff88800920d9e4 by task syz-executor.4/14865

CPU: 2 PID: 14865 Comm: syz-executor.4 Not tainted 5.19.0-rc2 #21
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
 <TASK>
 \_\_dump\_stack lib/dump\_stack.c:88 \[inline\]
 dump\_stack\_lvl+0x6e/0x91 lib/dump\_stack.c:106
 print\_address\_description mm/kasan/report.c:313 \[inline\]
 print\_report.cold+0xff/0x68e mm/kasan/report.c:429
 kasan\_report+0xa8/0x130 mm/kasan/report.c:491
 compare\_netdev\_and\_ip.isra.0+0x25/0x120 drivers/infiniband/core/cma.c:473
 cma\_add\_id\_to\_tree drivers/infiniband/core/cma.c:506 \[inline\]
 rdma\_resolve\_route+0xbc4/0x1560 drivers/infiniband/core/cma.c:3303
 ucma\_resolve\_route+0xe4/0x150 drivers/infiniband/core/ucma.c:746
 ucma\_write+0x19f/0x280 drivers/infiniband/core/ucma.c:1744
 vfs\_write fs/read\_write.c:589 \[inline\]
 vfs\_write+0x181/0x580 fs/read\_write.c:571
 ksys\_write+0x1a1/0x1e0 fs/read\_write.c:644
 do\_syscall\_x64 arch/x86/entry/common.c:50 \[inline\]
 do\_syscall\_64+0x3d/0x90 arch/x86/entry/common.c:80
 entry\_SYSCALL\_64\_after\_hwframe+0x46/0xb0
RIP: 0033:0x7f2afbe8c89d
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f2afcf1ec28 EFLAGS: 00000246 ORIG\_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f2afbfabf60 RCX: 00007f2afbe8c89d
RDX: 0000000000000010 RSI: 0000000020000100 RDI: 0000000000000003
RBP: 00007f2afbef910d R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffcdc77c66f R14: 00007f2afbfabf60 R15: 00007f2afcf1edc0
 </TASK>

Fixes: 19b752a19dce ("IB/cma: Allow port reuse for rdma\_id")
Signed-off-by: Patrisious Haddad <phaddad@xxxxxxxxxx>
Reviewed-by: Maor Gottlieb <maorg@xxxxxxxxxx>
Reported-by: Wei Chen <harperchen1110@xxxxxxxxx>
Signed-off-by: Leon Romanovsky <leonro@xxxxxxxxxx>
---
 drivers/infiniband/core/cma.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 1fca0a24f30f..2d4c391e36a9 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -3584,8 +3584,11 @@ static int resolve\_prepare\_src(struct rdma\_id\_private \*id\_priv,
 			       struct sockaddr \*src\_addr,
 			       const struct sockaddr \*dst\_addr)
 {
+	struct sockaddr org\_addr = {};
 	int ret;
 
+	memcpy(&org\_addr, cma\_dst\_addr(id\_priv),
+	       rdma\_addr\_size(cma\_dst\_addr(id\_priv)));
 	memcpy(cma\_dst\_addr(id\_priv), dst\_addr, rdma\_addr\_size(dst\_addr));
 	if (!cma\_comp\_exch(id\_priv, RDMA\_CM\_ADDR\_BOUND, RDMA\_CM\_ADDR\_QUERY)) {
 		/\* For a well behaved ULP state will be RDMA\_CM\_IDLE \*/
@@ -3608,7 +3611,7 @@ static int resolve\_prepare\_src(struct rdma\_id\_private \*id\_priv,
 err\_state:
 	cma\_comp\_exch(id\_priv, RDMA\_CM\_ADDR\_QUERY, RDMA\_CM\_ADDR\_BOUND);
 err\_dst:
-	memset(cma\_dst\_addr(id\_priv), 0, rdma\_addr\_size(dst\_addr));
+	memcpy(cma\_dst\_addr(id\_priv), &org\_addr, rdma\_addr\_size(&org\_addr));
 	return ret;
 }
 
-- 
2.38.1

CVE-2023-2176: Fix resolve_prepare_src error cleanup — Linux RDMA and InfiniBand development

A null pointer dereference issue was found in can protocol in net/can/af_can.c in the Linux before Linux. ml_priv may not be initialized in the receive path of CAN frames. A local user could use this flaw to crash the system or potentially cause a denial of service.

From: Wei Chen <harperchen1110@gmail.com>
To: socketcan@hartkopp.net, mkl@pengutronix.de,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, linux-can@vger.kernel.org,
	linux-kernel@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
	syzkaller-bugs@googlegroups.com,
	syzbot <syzkaller@googlegroups.com>
Subject: BUG: unable to handle kernel paging request in can\_rcv\_filter
Date: Tue, 6 Dec 2022 23:25:36 +0800	\[thread overview\]
Message-ID: <CAO4mrfcV\_07hbj8NUuZrA8FH-kaRsrFy-2metecpTuE5kKHn5w@mail.gmail.com> (raw)

Dear Linux Developers,

Recently, when using our tool to fuzz kernel, the following crash was triggered.

HEAD commit: 147307c69ba
git tree: linux-next
compiler: clang 12.0.0
console output:
https://drive.google.com/file/d/1\_c7TZ6WzCT-VLBimUP3xnkMpJPhjOAPY/view?usp=share\_link
kernel config: https://drive.google.com/file/d/1NAf4S43d9VOKD52xbrqw-PUP1Mbj8z-S/view?usp=share\_link

Unfortunately, I didn't have a reproducer for this crash.

I'm wondering if there is a data race between can\_receive and
sock\_close, which leads to the invalid null value of dev and
dev\_rcv\_lists. I hope the following report is helpful.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: Wei Chen <harperchen1110@gmail.com>

BUG: unable to handle page fault for address: 0000000000006020
#PF: supervisor read access in kernel mode
#PF: error\_code(0x0000) - not-present page
PGD 132110067 P4D 132110067 PUD 1320b6067 PMD 0
Oops: 0000 \[#1\] PREEMPT SMP
CPU: 0 PID: 13844 Comm: syz-executor.0 Not tainted 6.1.0-rc5-next-20221118 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014
RIP: 0010:can\_rcv\_filter+0x44/0x4e0 net/can/af\_can.c:584
Code: 00 00 00 e8 3e 86 0f fd 49 8b 9e d8 00 00 00 48 89 df e8 af 81
0f fd 44 8b 23 48 8d bd 20 60 00 00 e8 a0 81 0f fd 48 89 2c 24 <8b> 9d
20 60 00 00 45 31 ed 31 ff 89 de e8 9a 1c fc fc 85 db 0f 84
RSP: 0018:ffffc90000003d50 EFLAGS: 00010246
RAX: ffff88813bc274d8 RBX: ffff8881310c5a10 RCX: ffffffff842b9940
RDX: 0000000000000522 RSI: 0000000000000000 RDI: 0000000000006020
RBP: 0000000000000000 R08: 0000000000006023 R09: 0000000000000000
R10: 0001ffffffffffff R11: 00018881310c5a04 R12: 0000000000000000
R13: ffff888106fb8880 R14: ffff8881308cba00 R15: 0000000000000000
FS:  00007fc9368b0700(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000006020 CR3: 0000000132249000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000020000180 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
Call Trace:
 <IRQ>
 can\_receive+0x182/0x1f0 net/can/af\_can.c:664
 canfd\_rcv+0x9a/0x120 net/can/af\_can.c:703
 \_\_netif\_receive\_skb\_one\_core net/core/dev.c:5482 \[inline\]
 \_\_netif\_receive\_skb+0x8b/0x1b0 net/core/dev.c:5596
 process\_backlog+0x23f/0x3b0 net/core/dev.c:5924
 \_\_napi\_poll+0x65/0x420 net/core/dev.c:6485
 napi\_poll net/core/dev.c:6552 \[inline\]
 net\_rx\_action+0x37e/0x730 net/core/dev.c:6663
 \_\_do\_softirq+0xf2/0x2c9 kernel/softirq.c:571
 do\_softirq+0xb1/0xf0 kernel/softirq.c:472
 </IRQ>
 <TASK>
 \_\_local\_bh\_enable\_ip+0x6f/0x80 kernel/softirq.c:396
 local\_bh\_enable+0x1b/0x20 include/linux/bottom\_half.h:33
 netif\_rx+0x63/0x1c0 net/core/dev.c:5003
 can\_send+0x521/0x5b0 net/can/af\_can.c:286
 bcm\_can\_tx+0x2f0/0x3f0 net/can/bcm.c:302
 bcm\_tx\_setup net/can/bcm.c:1020 \[inline\]
 bcm\_sendmsg+0x1f78/0x2c50 net/can/bcm.c:1351
 sock\_sendmsg\_nosec net/socket.c:714 \[inline\]
 sock\_sendmsg net/socket.c:734 \[inline\]
 \_\_\_\_sys\_sendmsg+0x38f/0x500 net/socket.c:2476
 \_\_\_sys\_sendmsg net/socket.c:2530 \[inline\]
 \_\_sys\_sendmsg+0x197/0x230 net/socket.c:2559
 \_\_do\_sys\_sendmsg net/socket.c:2568 \[inline\]
 \_\_se\_sys\_sendmsg net/socket.c:2566 \[inline\]
 \_\_x64\_sys\_sendmsg+0x42/0x50 net/socket.c:2566
 do\_syscall\_x64 arch/x86/entry/common.c:50 \[inline\]
 do\_syscall\_64+0x2b/0x70 arch/x86/entry/common.c:80
 entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd
RIP: 0033:0x4697f9
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fc9368afc48 EFLAGS: 00000246 ORIG\_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 000000000077bf80 RCX: 00000000004697f9
RDX: 0000000000000000 RSI: 0000000020000380 RDI: 0000000000000006
RBP: 00000000004d29e9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000077bf80
R13: 0000000000000000 R14: 000000000077bf80 R15: 00007ffe26483e60
 </TASK>
Modules linked in:
CR2: 0000000000006020
---\[ end trace 0000000000000000 \]---
RIP: 0010:can\_rcv\_filter+0x44/0x4e0 net/can/af\_can.c:584
Code: 00 00 00 e8 3e 86 0f fd 49 8b 9e d8 00 00 00 48 89 df e8 af 81
0f fd 44 8b 23 48 8d bd 20 60 00 00 e8 a0 81 0f fd 48 89 2c 24 <8b> 9d
20 60 00 00 45 31 ed 31 ff 89 de e8 9a 1c fc fc 85 db 0f 84
RSP: 0018:ffffc90000003d50 EFLAGS: 00010246
RAX: ffff88813bc274d8 RBX: ffff8881310c5a10 RCX: ffffffff842b9940
RDX: 0000000000000522 RSI: 0000000000000000 RDI: 0000000000006020
RBP: 0000000000000000 R08: 0000000000006023 R09: 0000000000000000
R10: 0001ffffffffffff R11: 00018881310c5a04 R12: 0000000000000000
R13: ffff888106fb8880 R14: ffff8881308cba00 R15: 0000000000000000
FS:  00007fc9368b0700(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000006020 CR3: 0000000132249000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000020000180 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
----------------
Code disassembly (best guess):
   0: 00 00                add    %al,(%rax)
   2: 00 e8                add    %ch,%al
   4: 3e 86 0f              xchg   %cl,%ds:(%rdi)
   7: fd                    std
   8: 49 8b 9e d8 00 00 00 mov    0xd8(%r14),%rbx
   f: 48 89 df              mov    %rbx,%rdi
  12: e8 af 81 0f fd        callq  0xfd0f81c6
  17: 44 8b 23              mov    (%rbx),%r12d
  1a: 48 8d bd 20 60 00 00 lea    0x6020(%rbp),%rdi
  21: e8 a0 81 0f fd        callq  0xfd0f81c6
  26: 48 89 2c 24          mov    %rbp,(%rsp)
\* 2a: 8b 9d 20 60 00 00    mov    0x6020(%rbp),%ebx <-- trapping instruction
  30: 45 31 ed              xor    %r13d,%r13d
  33: 31 ff                xor    %edi,%edi
  35: 89 de                mov    %ebx,%esi
  37: e8 9a 1c fc fc        callq  0xfcfc1cd6
  3c: 85 db                test   %ebx,%ebx
  3e: 0f                    .byte 0xf
  3f: 84                    .byte 0x84

Best,
Wei

next             reply	other threads:\[~2022-12-06 15:26 UTC|newest\]

**Thread overview:** 2+ messages / expand\[flat|nested\]  mbox.gz  Atom feed  top
**2022-12-06 15:25 Wei Chen \[this message\]**
2022-12-06 16:35 \` BUG: unable to handle kernel paging request in can\_rcv\_filter Eric Dumazet

**Reply instructions:**

You may reply publicly to this message via plain-text email
using any one of the following methods:

\* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting\_style#Interleaved\_style

\* Reply using the **\--to**, **\--cc**, and **\--in-reply-to**
  switches of git-send-email(1):

  git send-email \\
    --in-reply-to=CAO4mrfcV\_07hbj8NUuZrA8FH-kaRsrFy-2metecpTuE5kKHn5w@mail.gmail.com \\
    --to=harperchen1110@gmail.com \\
    --cc=davem@davemloft.net \\
    --cc=edumazet@google.com \\
    --cc=kuba@kernel.org \\
    --cc=linux-can@vger.kernel.org \\
    --cc=linux-kernel@vger.kernel.org \\
    --cc=mkl@pengutronix.de \\
    --cc=netdev@vger.kernel.org \\
    --cc=pabeni@redhat.com \\
    --cc=socketcan@hartkopp.net \\
    --cc=syzkaller-bugs@googlegroups.com \\
    --cc=syzkaller@googlegroups.com \\
    /path/to/YOUR\_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

\* If your mail client supports setting the **In-Reply-To** header
  via mailto: links, try the mailto: link

Be sure your reply has a **Subject:** header at the top and a blank line before the message body.

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).

CVE-2023-2166: BUG: unable to handle kernel paging request in can_rcv_filter

The TaxoPress plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the Related Posts functionality in versions up to, and including, 3.6.4 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers with Editor+ permissions to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

Tag

#bios