OESA-2025-1513

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Fix use after free in hcisendacl

This fixes the following trace caused by receiving HCIEVDISCONNPHYLINKCOMPLETE which does call hciconndel without first checking if conn->type is in fact AMPLINK and in case it is do properly cleanup upper layers with hcidisconncfm:

================================================================== BUG: KASAN: use-after-free in hcisendacl+0xaba/0xc50 Read of size 8 at addr ffff88800e404818 by task bluetoothd/142

CPU: 0 PID: 142 Comm: bluetoothd Not tainted
5.17.0-rc5-00006-gda4022eeac1a #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x45/0x59
 print_address_description.constprop.0+0x1f/0x150
 kasan_report.cold+0x7f/0x11b
 hci_send_acl+0xaba/0xc50
 l2cap_do_send+0x23f/0x3d0
 l2cap_chan_send+0xc06/0x2cc0
 l2cap_sock_sendmsg+0x201/0x2b0
 sock_sendmsg+0xdc/0x110
 sock_write_iter+0x20f/0x370
 do_iter_readv_writev+0x343/0x690
 do_iter_write+0x132/0x640
 vfs_writev+0x198/0x570
 do_writev+0x202/0x280
 do_syscall_64+0x38/0x90
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3
0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05
<48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015
RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77
R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580
RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001
</TASK>
R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0

Allocated by task 45:
    kasan_save_stack+0x1e/0x40
    __kasan_kmalloc+0x81/0xa0
    hci_chan_create+0x9a/0x2f0
    l2cap_conn_add.part.0+0x1a/0xdc0
    l2cap_connect_cfm+0x236/0x1000
    le_conn_complete_evt+0x15a7/0x1db0
    hci_le_conn_complete_evt+0x226/0x2c0
    hci_le_meta_evt+0x247/0x450
    hci_event_packet+0x61b/0xe90
    hci_rx_work+0x4d5/0xc50
    process_one_work+0x8fb/0x15a0
    worker_thread+0x576/0x1240
    kthread+0x29d/0x340
    ret_from_fork+0x1f/0x30

Freed by task 45:
    kasan_save_stack+0x1e/0x40
    kasan_set_track+0x21/0x30
    kasan_set_free_info+0x20/0x30
    __kasan_slab_free+0xfb/0x130
    kfree+0xac/0x350
    hci_conn_cleanup+0x101/0x6a0
    hci_conn_del+0x27e/0x6c0
    hci_disconn_phylink_complete_evt+0xe0/0x120
    hci_event_packet+0x812/0xe90
    hci_rx_work+0x4d5/0xc50
    process_one_work+0x8fb/0x15a0
    worker_thread+0x576/0x1240
    kthread+0x29d/0x340
    ret_from_fork+0x1f/0x30

The buggy address belongs to the object at ffff88800c0f0500
The buggy address is located 24 bytes inside of
which belongs to the cache kmalloc-128 of size 128
The buggy address belongs to the page:
128-byte region [ffff88800c0f0500, ffff88800c0f0580)
flags: 0x100000000000200(slab|node=0|zone=1)
page:00000000fe45cd86 refcount:1 mapcount:0
mapping:0000000000000000 index:0x0 pfn:0xc0f0
raw: 0000000000000000 0000000080100010 00000001ffffffff
0000000000000000
raw: 0100000000000200 ffffea00003a2c80 dead000000000004
ffff8880078418c0
page dumped because: kasan: bad access detected
ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
Memory state around the buggy address:
>ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

---truncated---(CVE-2022-49111)

In the Linux kernel, the following vulnerability has been resolved:

NFC: NULL out the dev->rfkill to prevent UAF

Commit 3e3b5dfcd16a ("NFC: reorder the logic in nfc{un,}registerdevice") assumes the deviceisregistered() in function nfcdevup() will help to check when the rfkill is unregistered. However, this check only take effect when devicedel(&dev->dev) is done in nfcunregister_device(). Hence, the rfkill object is still possible be dereferenced.

The crash trace in latest kernel (5.18-rc2):

[ 68.760105] ================================================================== [ 68.760330] BUG: KASAN: use-after-free in _lockacquire+0x3ec1/0x6750 [ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313 [ 68.760756] [ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4 [ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 68.760756] Call Trace: [ 68.760756] <TASK> [ 68.760756] dumpstacklvl+0x57/0x7d [ 68.760756] printreport.cold+0x5e/0x5db [ 68.760756] ? _lockacquire+0x3ec1/0x6750 [ 68.760756] kasanreport+0xbe/0x1c0 [ 68.760756] ? _lockacquire+0x3ec1/0x6750 [ 68.760756] _lockacquire+0x3ec1/0x6750 [ 68.760756] ? lockdephardirqsonprepare+0x410/0x410 [ 68.760756] ? registerlockclass+0x18d0/0x18d0 [ 68.760756] lockacquire+0x1ac/0x4f0 [ 68.760756] ? rfkillblocked+0xe/0x60 [ 68.760756] ? lockdephardirqsonprepare+0x410/0x410 [ 68.760756] ? mutexlockionested+0x12c0/0x12c0 [ 68.760756] ? nlagetrangesigned+0x540/0x540 [ 68.760756] ? rawspinlockirqsave+0x4e/0x50 [ 68.760756] rawspinlockirqsave+0x39/0x50 [ 68.760756] ? rfkillblocked+0xe/0x60 [ 68.760756] rfkillblocked+0xe/0x60 [ 68.760756] nfcdevup+0x84/0x260 [ 68.760756] nfcgenldevup+0x90/0xe0 [ 68.760756] genlfamilyrcvmsgdoit+0x1f4/0x2f0 [ 68.760756] ? genlfamilyrcvmsgattrsparse.constprop.0+0x230/0x230 [ 68.760756] ? securitycapable+0x51/0x90 [ 68.760756] genlrcvmsg+0x280/0x500 [ 68.760756] ? genlgetcmd+0x3c0/0x3c0 [ 68.760756] ? lockacquire+0x1ac/0x4f0 [ 68.760756] ? nfcgenldevdown+0xe0/0xe0 [ 68.760756] ? lockdephardirqsonprepare+0x410/0x410 [ 68.760756] netlinkrcvskb+0x11b/0x340 [ 68.760756] ? genlgetcmd+0x3c0/0x3c0 [ 68.760756] ? netlinkack+0x9c0/0x9c0 [ 68.760756] ? netlinkdelivertap+0x136/0xb00 [ 68.760756] genlrcv+0x1f/0x30 [ 68.760756] netlinkunicast+0x430/0x710 [ 68.760756] ? memset+0x20/0x40 [ 68.760756] ? netlinkattachskb+0x740/0x740 [ 68.760756] ? _buildskbaround+0x1f4/0x2a0 [ 68.760756] netlinksendmsg+0x75d/0xc00 [ 68.760756] ? netlinkunicast+0x710/0x710 [ 68.760756] ? netlinkunicast+0x710/0x710 [ 68.760756] socksendmsg+0xdf/0x110 [ 68.760756] _syssendto+0x19e/0x270 [ 68.760756] ? _ia32sysgetpeername+0xa0/0xa0 [ 68.760756] ? fdinstall+0x178/0x4c0 [ 68.760756] ? fdinstall+0x195/0x4c0 [ 68.760756] ? kernelfpubeginmask+0x1c0/0x1c0 [ 68.760756] _x64syssendto+0xd8/0x1b0 [ 68.760756] ? lockdephardirqson+0xbf/0x130 [ 68.760756] ? syscallenterfromusermode+0x1d/0x50 [ 68.760756] dosyscall64+0x3b/0x90 [ 68.760756] entrySYSCALL64afterhwframe+0x44/0xae [ 68.760756] RIP: 0033:0x7f67fb50e6b3 ... [ 68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c [ 68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3 [ 68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003 [ 68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c [ 68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e [ 68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003

[ 68.760756] </TASK> [ 68.760756] [ 68.760756] Allocated by task 279: [ 68.760756] kasansavestack+0x1e/0x40 [ ---truncated---(CVE-2022-49505)

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: ffs: Prevent race during ffsep0queuewait

While performing fast composition switch, there is a possibility that the process of ffsep0write/ffsep0read get into a race condition due to ep0req being freed up from functionfs_unbind.

Consider the scenario that the ffsep0write calls the ffsep0queuewait by taking a lock &ffs->ev.waitq.lock. However, the functionfsunbind isn't bounded so it can go ahead and mark the ep0req to NULL, and since there is no NULL check in ffsep0queue_wait we will end up in use-after-free.

Fix this by making a serialized execution between the two functions using a mutex_lock(ffs->mutex).(CVE-2022-49755)

In the Linux kernel, the following vulnerability has been resolved:

dm ioctl: fix misbehavior if list_versions races with module loading

_listversions will first estimate the required space using the "dmtargetiterate(listversiongetneeded, &needed)" call and then will fill the space using the "dmtargetiterate(listversiongetinfo, &iterinfo)" call. Each of these calls locks the targets using the "downread(&lock)" and "upread(&lock)" calls, however between the first and second "dmtargetiterate" there is no lock held and the target modules can be loaded at this point, so the second "dmtargetiterate" call may need more space than what was the first "dmtarget_iterate" returned.

The code tries to handle this overflow (see the beginning of listversionget_info), however this handling is incorrect.

The code sets "param->datasize = param->datastart + needed" and "iterinfo.end = (char *)vers+len" - "needed" is the size returned by the first dmtarget_iterate call; "len" is the size of the buffer allocated by userspace.

"len" may be greater than "needed"; in this case, the code will write up to "len" bytes into the buffer, however param->datasize is set to "needed", so it may write data past the param->datasize value. The ioctl interface copies only up to param->data_size into userspace, thus part of the result will be truncated.

Fix this bug by setting "iterinfo.end = (char *)vers + needed;" - this guarantees that the second "dmtargetiterate" call will write only up to the "needed" buffer and it will exit with "DMBUFFERFULLFLAG" if it overflows the "needed" space - in this case, userspace will allocate a larger buffer and retry.

Note that there is also a bug in listversionget_needed - we need to add "strlen(tt->name) + 1" to the needed size, not "strlen(tt->name)".(CVE-2022-49771)

In the Linux kernel, the following vulnerability has been resolved:

ata: libata-transport: fix double atahostput() in atatportadd()

In the error path in atatportadd(), when calling putdevice(), atatport_release() is called, it will put the refcount of 'ap->host'.

And then atahostput() is called again, the refcount is decreased to 0, atahostrelease() is called, all ports are freed and set to null.

When unbinding the device after failure, atahoststop() is called to release the resources, it leads a null-ptr-deref(), because all the ports all freed and null.

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 CPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G E 6.1.0-rc3+ #8 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : atahoststop+0x3c/0x84 [libata] lr : releasenodes+0x64/0xd0 Call trace: atahoststop+0x3c/0x84 [libata] releasenodes+0x64/0xd0 devresreleaseall+0xbc/0x1b0 deviceunbindcleanup+0x20/0x70 reallyprobe+0x158/0x320 _driverprobedevice+0x84/0x120 driverprobedevice+0x44/0x120 _driverattach+0xb4/0x220 busforeachdev+0x78/0xdc driverattach+0x2c/0x40 busadddriver+0x184/0x240 driverregister+0x80/0x13c _pciregisterdriver+0x4c/0x60 ahcipcidriver_init+0x30/0x1000 [ahci]

Fix this by removing redundant atahostput() in the error path.(CVE-2022-49826)

In the Linux kernel, the following vulnerability has been resolved:

ASoC: core: Fix use-after-free in sndsocexit()

KASAN reports a use-after-free:

BUG: KASAN: use-after-free in devicedel+0xb5b/0xc60 Read of size 8 at addr ffff888008655050 by task rmmod/387 CPU: 2 PID: 387 Comm: rmmod Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dumpstacklvl+0x79/0x9a printreport+0x17f/0x47b kasanreport+0xbb/0xf0 devicedel+0xb5b/0xc60 platformdevicedel.part.0+0x24/0x200 platformdeviceunregister+0x2e/0x40 sndsocexit+0xa/0x22 [sndsoccore] _dosysdeletemodule.constprop.0+0x34f/0x5b0 dosyscall64+0x3a/0x90 entrySYSCALL64afterhwframe+0x63/0xcd ... </TASK>

It's bacause in sndsocinit(), sndsocutilinit() is possble to fail, but its ret is ignored, which makes socdummy_dev unregistered twice.

sndsocinit() sndsocutilinit() platformdeviceregistersimple(socdummydev) platformdriverregister() # fail platformdeviceunregister(socdummydev) platformdriverregister() # success ... sndsocexit() sndsocutilexit() # socdummy_dev will be unregistered for second time

To fix it, handle error and stop sndsocinit() when utilinit() fail. Also clean debugfs when utilinit() or driver_register() fail.(CVE-2022-49842)

In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix deadlock in nilfscountfree_blocks()

A semaphore deadlock can occur if nilfsgetblock() detects metadata corruption while locating data blocks and a superblock writeback occurs at the same time:

task 1 task 2 ------ ------ * A file operation * nilfstruncate() nilfsgetblock() downread(rwsem A) <-- nilfsbmaplookupcontig() ... genericshutdownsuper() nilfsputsuper() * Prepare to write superblock * downwrite(rwsem B) <-- nilfscleanupsuper() * Detect b-tree corruption * nilfssetlogcursor() nilfsbmapconverterror() nilfscountfreeblocks() _nilfserror() downread(rwsem A) <-- nilfsseterror() down_write(rwsem B) <--

                       *** DEADLOCK ***

Here, nilfsgetblock() readlocks rwsem A (= NILFSMDT(datinode)->misem) and then calls nilfsbmaplookupcontig(), but if it fails due to metadata corruption, _nilfserror() is called from nilfsbmapconvert_error() inside the lock section.

Since _nilfserror() calls nilfsseterror() unless the filesystem is read-only and nilfsseterror() attempts to writelock rwsem B (= nilfs->ns_sem) to write back superblock exclusively, hierarchical lock acquisition occurs in the order rwsem A -> rwsem B.

Now, if another task starts updating the superblock, it may writelock rwsem B during the lock sequence above, and can deadlock trying to readlock rwsem A in nilfscountfree_blocks().

However, there is actually no need to take rwsem A in nilfscountfreeblocks() because it, within the lock section, only reads a single integer data on a shared struct with nilfssufilegetncleansegs(). This has been the case after commit aa474a220180 ("nilfs2: add local variable to cache the number of clean segments"), that is, even before this bug was introduced.

So, this resolves the deadlock problem by just not taking the semaphore in nilfscountfree_blocks().(CVE-2022-49850)

In the Linux kernel, the following vulnerability has been resolved:

mISDN: fix possible memory leak in mISDNregisterdevice()

Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's busid string array"), the name of device is allocated dynamically, add putdevice() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0.

Set device class before putdevice() to avoid null release() function WARN message in devicerelease().(CVE-2022-49915)

In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Fix an illegal memory access

In the kfdwaitonevents() function, the kfdeventwaiter structure is allocated by alloceventwaiters(), but the event field of the waiter structure is not initialized; When copyfromuser() fails in the kfdwaitonevents() function, it will enter exception handling to release the previously allocated memory of the waiter structure; Due to the event field of the waiters structure being accessed in the free_waiters() function, this results in illegal memory access and system crash, here is the crash log:

localhost kernel: RIP: 0010:nativequeuedspinlockslowpath+0x185/0x1e0 localhost kernel: RSP: 0018:ffffaa53c362bd60 EFLAGS: 00010082 localhost kernel: RAX: ff3d3d6bff4007cb RBX: 0000000000000282 RCX: 00000000002c0000 localhost kernel: RDX: ffff9e855eeacb80 RSI: 000000000000279c RDI: ffffe7088f6a21d0 localhost kernel: RBP: ffffe7088f6a21d0 R08: 00000000002c0000 R09: ffffaa53c362be64 localhost kernel: R10: ffffaa53c362bbd8 R11: 0000000000000001 R12: 0000000000000002 localhost kernel: R13: ffff9e7ead15d600 R14: 0000000000000000 R15: ffff9e7ead15d698 localhost kernel: FS: 0000152a3d111700(0000) GS:ffff9e855ee80000(0000) knlGS:0000000000000000 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 localhost kernel: CR2: 0000152938000010 CR3: 000000044d7a4000 CR4: 00000000003506e0 localhost kernel: Call Trace: localhost kernel: rawspinlockirqsave+0x30/0x40 localhost kernel: removewaitqueue+0x12/0x50 localhost kernel: kfdwaitonevents+0x1b6/0x490 [hydcu] localhost kernel: ? ftracegraphcaller+0xa0/0xa0 localhost kernel: kfdioctl+0x38c/0x4a0 [hydcu] localhost kernel: ? kfdioctlsettraphandler+0x70/0x70 [hydcu] localhost kernel: ? kfdioctlcreatequeue+0x5a0/0x5a0 [hydcu] localhost kernel: ? ftracegraphcaller+0xa0/0xa0 localhost kernel: _x64sysioctl+0x8e/0xd0 localhost kernel: ? syscalltraceenter.isra.18+0x143/0x1b0 localhost kernel: dosyscall64+0x33/0x80 localhost kernel: entrySYSCALL64afterhwframe+0x44/0xa9 localhost kernel: RIP: 0033:0x152a4dff68d7

Allocate the structure with kcalloc, and remove redundant 0-initialization and a redundant loop condition check.(CVE-2023-53090)

In the Linux kernel, the following vulnerability has been resolved:

nvmet: avoid potential UAF in nvmetreqcomplete()

An nvme target ->queueresponse() operation implementation may free the request passed as argument. Such implementation potentially could result in a use after free of the request pointer when percpurefput() is called in nvmetreq_complete().

Avoid such problem by using a local variable to save the sq pointer before calling _nvmetreq_complete(), thus avoiding dereferencing the req pointer after that function call.(CVE-2023-53116)

In the Linux kernel, the following vulnerability has been resolved:

proc: fix UAF in procgetinode()

Fix race between rmmod and /proc/XXX's inode instantiation.

The bug is that pde->procops don't belong to /proc, it belongs to a module, therefore dereferencing it after /proc entry has been registered is a bug unless usepde/unuse_pde() pair has been used.

usepde/unusepde can be avoided (2 atomic ops!) because pde->procops never changes so information necessary for inode instantiation can be saved _before procregister() in PDE itself and used later, avoiding pde->procops->... dereference.

  rmmod                         lookup

sysdeletemodule proclookupde pdeget(de); procgetinode(dir->isb, de); mod->exit() procremove removeprocsubtree procentryrundown(de); freemodule(mod);

                           if (S_ISREG(inode->i_mode))
                         if (de->proc_ops->proc_read_iter)
                       --> As module is already freed, will trigger UAF

BUG: unable to handle page fault for address: fffffbfff80a702b PGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:procgetinode+0x302/0x6e0 RSP: 0018:ffff88811c837998 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007 RDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158 RBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20 R10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0 R13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001 FS: 00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> proclookupde+0x11f/0x2e0 _lookupslow+0x188/0x350 walkcomponent+0x2ab/0x4f0 pathlookupat+0x120/0x660 filenamelookup+0x1ce/0x560 vfsstatx+0xac/0x150 _dosysnewstat+0x96/0x110 dosyscall64+0x5f/0x170 entrySYSCALL64after_hwframe+0x76/0x7e

adobriyan@gmail.com: don't do 2 atomic ops on the common path