OESA-2024-2325

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs ISERR() bug for debugfscreatedir() The debugfscreatedir() function returns error pointers. It never returns NULL. So use ISERR() to check it.(CVE-2023-52917)

In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885vdevinit() return cx23885vdevinit() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)

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

btrfs: make sure that WRITTEN is set on all metadata blocks

We previously would call btrfscheckleaf() if we had the check integrity code enabled, which meant that we could only run the extended leaf checks if we had WRITTEN set on the header flags.

This leaves a gap in our checking, because we could end up with corruption on disk where WRITTEN isn't set on the leaf, and then the extended leaf checks don't get run which we rely on to validate all of the item pointers to make sure we don't access memory outside of the extent buffer.

However, since 732fab95abe2 ("btrfs: check-integrity: remove CONFIGBTRFSFSCHECKINTEGRITY option") we no longer call btrfscheckleaf() from btrfsmarkbuffer_dirty(), which means we only ever call it on blocks that are being written out, and thus have WRITTEN set, or that are being read in, which should have WRITTEN set.

Add checks to make sure we have WRITTEN set appropriately, and then make sure _btrfscheck_leaf() always does the item checking. This will protect us from file systems that have been corrupted and no longer have WRITTEN set on some of the blocks.

This was hit on a crafted image tweaking the WRITTEN bit and reported by KASAN as out-of-bound access in the eb accessors. The example is a dir item at the end of an eb.

[2.042] BTRFS warning (device loop1): bad eb member start: ptr 0x3fff start 30572544 member offset 16410 size 2 [2.040] general protection fault, probably for non-canonical address 0xe0009d1000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI [2.537] KASAN: maybe wild-memory-access in range [0x0005088000000018-0x000508800000001f] [2.729] CPU: 0 PID: 2587 Comm: mount Not tainted 6.8.2 #1 [2.729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [2.621] RIP: 0010:btrfsget16+0x34b/0x6d0 [2.621] RSP: 0018:ffff88810871fab8 EFLAGS: 00000206 [2.621] RAX: 0000a11000000003 RBX: ffff888104ff8720 RCX: ffff88811b2288c0 [2.621] RDX: dffffc0000000000 RSI: ffffffff81dd8aca RDI: ffff88810871f748 [2.621] RBP: 000000000000401a R08: 0000000000000001 R09: ffffed10210e3ee9 [2.621] R10: ffff88810871f74f R11: 205d323430333737 R12: 000000000000001a [2.621] R13: 000508800000001a R14: 1ffff110210e3f5d R15: ffffffff850011e8 [2.621] FS: 00007f56ea275840(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 [2.621] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2.621] CR2: 00007febd13b75c0 CR3: 000000010bb50000 CR4: 00000000000006f0 [2.621] Call Trace: [2.621] <TASK> [2.621] ? showregs+0x74/0x80 [2.621] ? dieaddr+0x46/0xc0 [2.621] ? excgeneralprotection+0x161/0x2a0 [2.621] ? asmexcgeneralprotection+0x26/0x30 [2.621] ? btrfsget16+0x33a/0x6d0 [2.621] ? btrfsget16+0x34b/0x6d0 [2.621] ? btrfsget16+0x33a/0x6d0 [2.621] ? _pfxbtrfsget16+0x10/0x10 [2.621] ? _pfxmutexunlock+0x10/0x10 [2.621] btrfsmatchdiritemname+0x101/0x1a0 [2.621] btrfslookupdiritem+0x1f3/0x280 [2.621] ? _pfxbtrfslookupdiritem+0x10/0x10 [2.621] btrfsgettree+0xd25/0x1910

copy more details from report

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

Bluetooth: ISO: Fix not validating setsockopt user input

Check user input length before copying data.(CVE-2024-35964)

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

iommu/arm-smmu: Use the correct type in nvidiasmmucontext_fault()

This was missed because of the function pointer indirection.

nvidiasmmucontextfault() is also installed as a irq function, and the 'void *' was changed to a struct armsmmudomain. Since the iommudomain is embedded at a non-zero offset this causes nvidiasmmucontext_fault() to miscompute the offset. Fixup the types.

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000120 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000107c9f000 [0000000000000120] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 1 PID: 47 Comm: kworker/u25:0 Not tainted 6.9.0-0.rc7.58.eln136.aarch64 #1 Hardware name: Unknown NVIDIA Jetson Orin NX/NVIDIA Jetson Orin NX, BIOS 3.1-32827747 03/19/2023 Workqueue: eventsunbound deferredprobeworkfunc pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : nvidiasmmucontextfault+0x1c/0x158 lr : _freeirq+0x1d4/0x2e8 sp : ffff80008044b6f0 x29: ffff80008044b6f0 x28: ffff000080a60b18 x27: ffffd32b5172e970 x26: 0000000000000000 x25: ffff0000802f5aac x24: ffff0000802f5a30 x23: ffff0000802f5b60 x22: 0000000000000057 x21: 0000000000000000 x20: ffff0000802f5a00 x19: ffff000087d4cd80 x18: ffffffffffffffff x17: 6234362066666666 x16: 6630303078302d30 x15: ffff00008156d888 x14: 0000000000000000 x13: ffff0000801db910 x12: ffff00008156d6d0 x11: 0000000000000003 x10: ffff0000801db918 x9 : ffffd32b50f94d9c x8 : 1fffe0001032fda1 x7 : ffff00008197ed00 x6 : 000000000000000f x5 : 000000000000010e x4 : 000000000000010e x3 : 0000000000000000 x2 : ffffd32b51720cd8 x1 : ffff000087e6f700 x0 : 0000000000000057 Call trace: nvidiasmmucontextfault+0x1c/0x158 _freeirq+0x1d4/0x2e8 freeirq+0x3c/0x80 devmfreeirq+0x64/0xa8 armsmmudomainfree+0xc4/0x158 iommudomainfree+0x44/0xa0 iommudeinitdevice+0xd0/0xf8 _iommugroupremovedevice+0xcc/0xe0 iommubusnotifier+0x64/0xa8 notifiercallchain+0x78/0x148 blockingnotifiercallchain+0x4c/0x90 busnotify+0x44/0x70 devicedel+0x264/0x3e8 pciremovebusdevice+0x84/0x120 pciremoverootbus+0x5c/0xc0 dwpciehostdeinit+0x38/0xe0 tegrapcieconfigrp+0xc0/0x1f0 tegrapciedwprobe+0x34c/0x700 platformprobe+0x70/0xe8 reallyprobe+0xc8/0x3a0 _driverprobedevice+0x84/0x160 driverprobedevice+0x44/0x130 _deviceattachdriver+0xc4/0x170 busforeachdrv+0x90/0x100 _deviceattach+0xa8/0x1c8 deviceinitialprobe+0x1c/0x30 busprobedevice+0xb0/0xc0 deferredprobeworkfunc+0xbc/0x120 processonework+0x194/0x490 workerthread+0x284/0x3b0 kthread+0xf4/0x108 retfrom_fork+0x10/0x20 Code: a9b97bfd 910003fd a9025bf5 f85a0035 (b94122a1)(CVE-2024-36884)

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

dev/parport: fix the array out-of-bounds risk

Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed.

Below is the stack trace I encountered during the actual issue:

[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: dohardwarebaseaddr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm: QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024 [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace: [ 66.575469s] [pid:5118,cpu4,QThread,9] dumpbacktrace+0x0/0x1c0 [ 66.575469s] [pid:5118,cpu4,QThread,0] showstack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dumpstack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] _stackchkfail+0x2c/0x38 [ 66.575500s] [pid:5118,cpu4,QThread,4] dohardwarebaseaddr+0xcc/0xd0 parport

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

jfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)

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

drm/nouveau: prime: fix refcount underflow

Calling nouveauboref() on a nouveaubo without initializing it (and hence the backing ttmbo) leads to a refcount underflow.

Instead of calling nouveauboref() in the unwind path of drmgemobject_init(), clean things up manually.

(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)(CVE-2024-43867)

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

devres: Fix memory leakage caused by driver API devmfreepercpu()

It will cause memory leakage when use driver API devmfreepercpu() to free memory allocated by devmallocpercpu(), fixed by using devresrelease() instead of devresdestroy() within devmfreepercpu().(CVE-2024-43871)

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

drm/msm/dpu: cleanup FB if dpuformatpopulate_layout fails

If the dpuformatpopulatelayout() fails, then FB is prepared, but not cleaned up. This ends up leaking the pincount on the GEM object and causes a splat during DRM file closure:

msmobj->pincount WARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msmgem.c:121 updatelrulocked+0xc4/0xcc [...] Call trace: updatelrulocked+0xc4/0xcc putpages+0xac/0x100 msmgemfreeobject+0x138/0x180 drmgemobjectfree+0x1c/0x30 drmgemobjecthandleputunlocked+0x108/0x10c drmgemobjectreleasehandle+0x58/0x70 idrforeach+0x68/0xec drmgemrelease+0x28/0x40 drmfilefree+0x174/0x234 drmrelease+0xb0/0x160 _fput+0xc0/0x2c8 _fputsync+0x50/0x5c _arm64sysclose+0x38/0x7c invokesyscall+0x48/0x118 el0svccommon.constprop.0+0x40/0xe0 doel0svc+0x1c/0x28 el0svc+0x4c/0x120 el0t64synchandler+0x100/0x12c el0t64sync+0x190/0x194 irq event stamp: 129818 hardirqs last enabled at (129817): [<ffffa5f6d953fcc0>] consoleunlock+0x118/0x124 hardirqs last disabled at (129818): [<ffffa5f6da7dcf04>] el1dbg+0x24/0x8c softirqs last enabled at (129808): [<ffffa5f6d94afc18>] handlesoftirqs+0x4c8/0x4e8 softirqs last disabled at (129785): [<ffffa5f6d94105e4>] _dosoftirq+0x14/0x20

Patchwork: https://patchwork.freedesktop.org/patch/600714/(CVE-2024-44982)

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

net: ethernet: mtkwed: fix use-after-free panic in mtkwedsetuptcblockcb()

When there are multiple ap interfaces on one band and with WED on, turning the interface down will cause a kernel panic on MT798X.

Previously, cbpriv was freed in mtkwedsetuptcblock() without marking NULL,and mtkwedsetuptcblockcb() didn't check the value, too.

Assign NULL after free cbpriv in mtkwedsetuptcblock() and check NULL in mtkwedsetuptcblockcb().

Unable to handle kernel paging request at virtual address 0072460bca32b4f5 Call trace: mtkwedsetuptcblockcb+0x4/0x38 0xffffffc0794084bc tcfblockplaybackoffloads+0x70/0x1e8 tcfblockunbind+0x6c/0xc8 ... ---------(CVE-2024-44997)

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

usb: dwc3: core: Prevent USB core invalid event buffer address access

This commit addresses an issue where the USB core could access an invalid event buffer address during runtime suspend, potentially causing SMMU faults and other memory issues in Exynos platforms. The problem arises from the following sequence. 1. In dwc3gadgetsuspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3coreexit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address.

To prevent this hardware quirk on Exynos platforms, this commit ensures that the event buffer address is not cleared by software when the USB core is active during runtime suspend by checking its status before clearing the buffer address.(CVE-2024-46675)

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

gtp: fix a potential NULL pointer dereference

When sockfdlookup() fails, gtpencapenablesocket() returns a NULL pointer, but its callers only check for error pointers thus miss the NULL pointer case.

Fix it by returning an error pointer with the error code carried from sockfd_lookup().

(I found this bug during code inspection.)(CVE-2024-46677)

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

drm/amdgpu: Fix out-of-bounds read of dfv17channelnumber

Check the fbchannelnumber range to avoid the array out-of-bounds read error(CVE-2024-46724)

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

Bluetooth: btnxpuart: Fix Null pointer dereference in btnxpuart_flush()

This adds a check before freeing the rx->skb in flush and close functions to handle the kernel crash seen while removing driver after FW download fails or before FW download completes.

dmesg log: [ 54.634586] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080 [ 54.643398] Mem abort info: [ 54.646204] ESR = 0x0000000096000004 [ 54.649964] EC = 0x25: DABT (current EL), IL = 32 bits [ 54.655286] SET = 0, FnV = 0 [ 54.658348] EA = 0, S1PTW = 0 [ 54.661498] FSC = 0x04: level 0 translation fault [ 54.666391] Data abort info: [ 54.669273] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 54.674768] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 54.674771] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 54.674775] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000048860000 [ 54.674780] [0000000000000080] pgd=0000000000000000, p4d=0000000000000000 [ 54.703880] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 54.710152] Modules linked in: btnxpuart(-) overlay fsljruio caamjr caamkeyblobdesc caamhashdesc caamalgdesc cryptoengine authenc libdes crct10difce polyvalce polyvalgeneric sndsocimxspdif sndsocimxcard sndsocak5558 sndsocak4458 caam secvio error sndsocfslmicfil sndsocfslspdif sndsocfslsai sndsocfslutils imxpcmdma gpioirrecv rccore schfqcodel fuse [ 54.744357] CPU: 3 PID: 72 Comm: kworker/u9:0 Not tainted 6.6.3-otbr-g128004619037 #2 [ 54.744364] Hardware name: FSL i.MX8MM EVK board (DT) [ 54.744368] Workqueue: hci0 hcipoweron [ 54.757244] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 54.757249] pc : kfreeskbreason+0x18/0xb0 [ 54.772299] lr : btnxpuartflush+0x40/0x58 [btnxpuart] [ 54.782921] sp : ffff8000805ebca0 [ 54.782923] x29: ffff8000805ebca0 x28: ffffa5c6cf1869c0 x27: ffffa5c6cf186000 [ 54.782931] x26: ffff377b84852400 x25: ffff377b848523c0 x24: ffff377b845e7230 [ 54.782938] x23: ffffa5c6ce8dbe08 x22: ffffa5c6ceb65410 x21: 00000000ffffff92 [ 54.782945] x20: ffffa5c6ce8dbe98 x19: ffffffffffffffac x18: ffffffffffffffff [ 54.807651] x17: 0000000000000000 x16: ffffa5c6ce2824ec x15: ffff8001005eb857 [ 54.821917] x14: 0000000000000000 x13: ffffa5c6cf1a02e0 x12: 0000000000000642 [ 54.821924] x11: 0000000000000040 x10: ffffa5c6cf19d690 x9 : ffffa5c6cf19d688 [ 54.821931] x8 : ffff377b86000028 x7 : 0000000000000000 x6 : 0000000000000000 [ 54.821938] x5 : ffff377b86000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 54.843331] x2 : 0000000000000000 x1 : 0000000000000002 x0 : ffffffffffffffac [ 54.857599] Call trace: [ 54.857601] kfreeskbreason+0x18/0xb0 [ 54.863878] btnxpuartflush+0x40/0x58 [btnxpuart] [ 54.863888] hcidevopensync+0x3a8/0xa04 [ 54.872773] hcipoweron+0x54/0x2e4 [ 54.881832] processonework+0x138/0x260 [ 54.881842] workerthread+0x32c/0x438 [ 54.881847] kthread+0x118/0x11c [ 54.881853] retfrom_fork+0x10/0x20 [ 54.896406] Code: a9be7bfd 910003fd f9000bf3 aa0003f3 (b940d400) [ 54.896410] ---[ end trace 0000000000000000 ]---(CVE-2024-46749)

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

hwmon: (nct6775-core) Fix underflows seen when writing limit attributes

DIVROUNDCLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clampval() and DIVROUND_CLOSEST() operations.(CVE-2024-46757)

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

drm/amd/display: Validate function returns

[WHAT & HOW] Function return values must be checked before data can be used in subsequent functions.

This fixes 4 CHECKED_RETURN issues reported by Coverity.(CVE-2024-46775)

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

ila: call nfunregisternet_hooks() sooner

syzbot found an use-after-free Read in ilanfinput [1]

Issue here is that ilaxlatexitnet() frees the rhashtable, then call nfunregisternethooks().

It should be done in the reverse way, with a synchronize_rcu().

This is a good match for a pre_exit() method.

[1] BUG: KASAN: use-after-free in rhtkeyhashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: use-after-free in _rhashtablelookup include/linux/rhashtable.h:604 [inline] BUG: KASAN: use-after-free in rhashtablelookup include/linux/rhashtable.h:646 [inline] BUG: KASAN: use-after-free in rhashtablelookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16

CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:93 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:119 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 rhtkeyhashfn include/linux/rhashtable.h:159 [inline] _rhashtablelookup include/linux/rhashtable.h:604 [inline] rhashtablelookup include/linux/rhashtable.h:646 [inline] rhashtablelookupfast+0x77a/0x9b0 include/linux/rhashtable.h:672 ilalookupwildcards net/ipv6/ila/ilaxlat.c:132 [inline] ilaxlataddr net/ipv6/ila/ilaxlat.c:652 [inline] ilanfinput+0x1fe/0x3c0 net/ipv6/ila/ilaxlat.c:190 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xc3/0x220 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] NFHOOK+0x29e/0x450 include/linux/netfilter.h:312 _netifreceiveskbonecore net/core/dev.c:5661 [inline] _netifreceiveskb+0x1ea/0x650 net/core/dev.c:5775 processbacklog+0x662/0x15b0 net/core/dev.c:6108 _napipoll+0xcb/0x490 net/core/dev.c:6772 napipoll net/core/dev.c:6841 [inline] netrxaction+0x89b/0x1240 net/core/dev.c:6963 handlesoftirqs+0x2c4/0x970 kernel/softirq.c:554 runksoftirqd+0xca/0x130 kernel/softirq.c:928 smpbootthreadfn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>

The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620 flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) pagetype: 0xbfffffff(buddy) raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000 raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000 page dumped because: kasan: bad access detected pageowner tracks the page as freed page last allocated via order 3, migratetype Unmovable, gfpmask 0x52dc0(GFPKERNEL|GFPNOWARN|GFPNORETRY|GFPCOMP|GFPZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, freets 618981657187 setpageowner include/linux/pageowner.h:32 [inline] postallochook+0x1f3/0x230 mm/pagealloc.c:1493 prepnewpage mm/pagealloc.c:1501 [inline] getpagefromfreelist+0x2e4c/0x2f10 mm/pagealloc.c:3439 allocpagesnoprof+0x256/0x6c0 mm/pagealloc.c:4695 _allocpagesnodenoprof include/linux/gfp.h:269 [inline] allocpagesnodenoprof include/linux/gfp.h:296 [inline] kmalloclargenode+0x8b/0x1d0 mm/slub.c:4103 _kmalloclargenodenoprof+0x1a/0x80 mm/slub.c:4130 _dokmallocnode mm/slub.c:4146 [inline] _kmallocnodenoprof+0x2d2/0x440 mm/slub.c:4164 _kvmallocnodenoprof+0x72/0x190 mm/util.c:650 buckettablealloc lib/rhashtable.c:186 [inline] rhashtableinitnoprof+0x534/0xa60 lib/rhashtable.c:1071 ilaxlatinitnet+0xa0/0x110 net/ipv6/ila/ilaxlat.c:613 ops_ini ---truncated---(CVE-2024-46782)

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

drm/amd/display: added NULL check at start of dcvalidatestream

[Why] prevent invalid memory access

[How] check if dc and stream are NULL(CVE-2024-46802)

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

spi: nxp-fspi: fix the KASAN report out-of-bounds bug

Change the memcpy length to fix the out-of-bounds issue when writing the data that is not 4 byte aligned to TX FIFO.

To reproduce the issue, write 3 bytes data to NOR chip.

dd if=3b of=/dev/mtd0 [ 36.926103] ================================================================== [ 36.933409] BUG: KASAN: slab-out-of-bounds in nxpfspiexecop+0x26ec/0x2838 [ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455 [ 36.946721] [ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070 [ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT) [ 36.961260] Call trace: [ 36.963723] dumpbacktrace+0x90/0xe8 [ 36.967414] showstack+0x18/0x24 [ 36.970749] dumpstacklvl+0x78/0x90 [ 36.974451] printreport+0x114/0x5cc [ 36.978151] kasanreport+0xa4/0xf0 [ 36.981670] _asanreportloadnnoabort+0x1c/0x28 [ 36.986587] nxpfspiexecop+0x26ec/0x2838 [ 36.990800] spimemexecop+0x8ec/0xd30 [ 36.994762] spimemnodirmapread+0x190/0x1e0 [ 36.999323] spimemdirmapwrite+0x238/0x32c [ 37.003710] spinorwritedata+0x220/0x374 [ 37.007932] spinorwrite+0x110/0x2e8 [ 37.011711] mtdwriteoobstd+0x154/0x1f0 [ 37.015838] mtdwriteoob+0x104/0x1d0 [ 37.019617] mtdwrite+0xb8/0x12c [ 37.022953] mtdcharwrite+0x224/0x47c [ 37.026732] vfswrite+0x1e4/0x8c8 [ 37.030163] ksyswrite+0xec/0x1d0 [ 37.033586] _arm64syswrite+0x6c/0x9c [ 37.037539] invokesyscall+0x6c/0x258 [ 37.041327] el0svccommon.constprop.0+0x160/0x22c [ 37.046244] doel0svc+0x44/0x5c [ 37.049589] el0svc+0x38/0x78 [ 37.052681] el0t64synchandler+0x13c/0x158 [ 37.057077] el0t64sync+0x190/0x194 [ 37.060775] [ 37.062274] Allocated by task 455: [ 37.065701] kasansavestack+0x2c/0x54 [ 37.069570] kasansavetrack+0x20/0x3c [ 37.073438] kasansaveallocinfo+0x40/0x54 [ 37.077736] _kasankmalloc+0xa0/0xb8 [ 37.081515] _kmallocnoprof+0x158/0x2f8 [ 37.085563] mtdkmallocupto+0x120/0x154 [ 37.089690] mtdcharwrite+0x130/0x47c [ 37.093469] vfswrite+0x1e4/0x8c8 [ 37.096901] ksyswrite+0xec/0x1d0 [ 37.100332] _arm64syswrite+0x6c/0x9c [ 37.104287] invokesyscall+0x6c/0x258 [ 37.108064] el0svccommon.constprop.0+0x160/0x22c [ 37.112972] doel0svc+0x44/0x5c [ 37.116319] el0svc+0x38/0x78 [ 37.119401] el0t64synchandler+0x13c/0x158 [ 37.123788] el0t64sync+0x190/0x194 [ 37.127474] [ 37.128977] The buggy address belongs to the object at ffff00081037c2a0 [ 37.128977] which belongs to the cache kmalloc-8 of size 8 [ 37.141177] The buggy address is located 0 bytes inside of [ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3) [ 37.153465] [ 37.154971] The buggy address belongs to the physical page: [ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c [ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff) [ 37.175149] page_type: 0xfdffffff(slab) [ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000 [ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000 [ 37.194553] page dumped because: kasan: bad access detected [ 37.200144] [ 37.201647] Memory state around the buggy address: [ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc [ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc [ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc [ 37.228186] ^ [ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.246962] ============================================================== ---truncated---(CVE-2024-46853)

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

drm/amd/display: Correct the defined value for AMDGPUDMUBNOTIFICATION_MAX

[Why & How] It actually exposes '6' types in enum dmubnotificationtype. Not 5. Using smaller number to create array dmubcallback & dmubthread_offload has potential to access item out of array bound. Fix it.(CVE-2024-46871)

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

smack: tcp: ipv4, fix incorrect labeling

Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to write.

Here is a scenario how to see this:

• Take two machines, let's call them C and S, with active Smack in the default state (no settings, no rules, no labeled hosts, only builtin labels)

• At S, add Smack rule 'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment)

• At S, at label 'bar', launch a program that listens for incoming tcp/ipv4 connections

• From C, at label 'foo', connect to the listener at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works.

• Send some data in both directions.

• Collect network traffic of this connection.

All packets in both directions are labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized, and even without ever being known at C.

If anybody cares: exactly the same happens with DCCP.

This behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no explanation was provided.

I changed returned packes label into the 'bar', to bring it into line with the Smack documentation claims.(CVE-2024-47659)

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

fsnotify: clear PARENT_WATCHED flags lazily

In some setups directories can have many (usually negative) dentries. Hence _fsnotifyupdatechilddentryflags() function can take a significant amount of time. Since the bulk of this function happens under inode->ilock this causes a significant contention on the lock when we remove the watch from the directory as the _fsnotifyupdatechilddentryflags() call from fsnotifyrecalcmask() races with _fsnotifyupdatechilddentryflags() calls from _fsnotifyparent() happening on children. This can lead upto softlockup reports reported by users.

Fix the problem by calling fsnotifyupdatechildrendentryflags() to set PARENT_WATCHED flags only when parent starts watching children.

When parent stops watching children, clear false positive PARENTWATCHED flags lazily in _fsnotify_parent() for each accessed child.(CVE-2024-47660)

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

drm/amd/display: Avoid overflow from uint32t to uint8t

[WHAT & HOW] dmubrbcmd's rampingboundary has size of uint8t and it is assigned 0xFFFF. Fix it by changing it to uint8_t with value of 0xFF.

This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-47661)

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

PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)

Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0 (SPRZ452DJuly 2018Revised December 2019 [1]) mentions when an inbound PCIe TLP spans more than two internal AXI 128-byte bursts, the bus may corrupt the packet payload and the corrupt data may cause associated applications or the processor to hang.

The workaround for Errata #i2037 is to limit the maximum read request size and maximum payload size to 128 bytes. Add workaround for Errata #i2037 here.

The errata and workaround is applicable only to AM65x SR 1.0 and later versions of the silicon will have this fixed.

[1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf(CVE-2024-47667)

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996mcustabferhe Fix the NULL pointer dereference in mt7996mcustabferhe routine adding an sta interface to the mt7996 driver. Found by code review.(CVE-2024-47681)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip Recompute DSC Params if no Stream on Link [why] Encounter NULL pointer dereference uner mst + dsc setup. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 RIP: 0010:drmdpatomicfindtimeslots+0x5e/0x260 [drmdisplayhelper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0 Call Trace: <TASK> ? _die+0x23/0x70 ? pagefaultoops+0x171/0x4e0 ? plistadd+0xbe/0x100 ? excpagefault+0x7c/0x180 ? asmexcpagefault+0x26/0x30 ? drmdpatomicfindtimeslots+0x5e/0x260 [drmdisplayhelper 0e67723696438d8e02b741593dd50d80b44c2026] ? drmdpatomicfindtimeslots+0x28/0x260 [drmdisplayhelper 0e67723696438d8e02b741593dd50d80b44c2026] computemstdscconfigsforlink+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] ? fillplanebufferattributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] computemstdscconfigsforstate+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] amdgpudmatomiccheck+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] drmatomiccheckonly+0x5c5/0xa40 drmmodeatomicioctl+0x76e/0xbc0 [how] dsc recompute should be skipped if no mode change detected on the new request. If detected, keep checking whether the stream is already on current state or not.(CVE-2024-47683)

In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcprtodeltaus() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcprearmrto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: errorcode(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcprearmrto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? showregs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? _die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? nocontext+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6protocoldeliverrcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6sublistrcvfinish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? _badareanosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? badareanosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? douseraddrfault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6listrcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? _dopagefault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? dopagefault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? pagefault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcprearmrto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcprearmrto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcpsendlossprobe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcpwritetimerhandler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcpwritetimer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcpwritetimerhandler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] calltimerfn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] _runtimers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibratecpukhz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? nativex2apicicrwrite+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapicnext_even ---truncated---(CVE-2024-47684)

In the Linux kernel, the following vulnerability has been resolved: netfilter: nfrejectipv6: fix nfrejectip6tcphdrput() syzbot reported that nfrejectip6tcphdrput() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skbputzero() to clear the whole TCP header, as done in nfrejectiptcphdrput() BUG: KMSAN: uninit-value in nfrejectip6tcphdrput+0x688/0x6c0 net/ipv6/netfilter/nfrejectipv6.c:255 nfrejectip6tcphdrput+0x688/0x6c0 net/ipv6/netfilter/nfrejectipv6.c:255 nfsendreset6+0xd84/0x15b0 net/ipv6/netfilter/nfrejectipv6.c:344 nftrejectineteval+0x3c1/0x880 net/netfilter/nftrejectinet.c:48 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x438/0x22a0 net/netfilter/nftablescore.c:288 nftdochaininet+0x41a/0x4f0 net/netfilter/nftchainfilter.c:161 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] NFHOOK include/linux/netfilter.h:312 [inline] ipv6rcv+0x29b/0x390 net/ipv6/ip6input.c:310 _netifreceiveskbonecore net/core/dev.c:5661 [inline] _netifreceiveskb+0x1da/0xa00 net/core/dev.c:5775 processbacklog+0x4ad/0xa50 net/core/dev.c:6108 _napipoll+0xe7/0x980 net/core/dev.c:6772 napipoll net/core/dev.c:6841 [inline] netrxaction+0xa5a/0x19b0 net/core/dev.c:6963 handlesoftirqs+0x1ce/0x800 kernel/softirq.c:554 _dosoftirq+0x14/0x1a kernel/softirq.c:588 dosoftirq+0x9a/0x100 kernel/softirq.c:455 _localbhenableip+0x9f/0xb0 kernel/softirq.c:382 localbhenable include/linux/bottomhalf.h:33 [inline] rcureadunlockbh include/linux/rcupdate.h:908 [inline] _devqueuexmit+0x2692/0x5610 net/core/dev.c:4450 devqueuexmit include/linux/netdevice.h:3105 [inline] neighresolveoutput+0x9ca/0xae0 net/core/neighbour.c:1565 neighoutput include/net/neighbour.h:542 [inline] ip6finishoutput2+0x2347/0x2ba0 net/ipv6/ip6output.c:141 _ip6finishoutput net/ipv6/ip6output.c:215 [inline] ip6finishoutput+0xbb8/0x14b0 net/ipv6/ip6output.c:226 NFHOOKCOND include/linux/netfilter.h:303 [inline] ip6output+0x356/0x620 net/ipv6/ip6output.c:247 dstoutput include/net/dst.h:450 [inline] NFHOOK include/linux/netfilter.h:314 [inline] ip6xmit+0x1ba6/0x25d0 net/ipv6/ip6output.c:366 inet6cskxmit+0x442/0x530 net/ipv6/inet6connectionsock.c:135 _tcptransmitskb+0x3b07/0x4880 net/ipv4/tcpoutput.c:1466 tcptransmitskb net/ipv4/tcpoutput.c:1484 [inline] tcpconnect+0x35b6/0x7130 net/ipv4/tcpoutput.c:4143 tcpv6connect+0x1bcc/0x1e40 net/ipv6/tcpipv6.c:333 _inetstreamconnect+0x2ef/0x1730 net/ipv4/afinet.c:679 inetstreamconnect+0x6a/0xd0 net/ipv4/afinet.c:750 _sysconnectfile net/socket.c:2061 [inline] _sysconnect+0x606/0x690 net/socket.c:2078 _dosysconnect net/socket.c:2088 [inline] _sesysconnect net/socket.c:2085 [inline] _x64sysconnect+0x91/0xe0 net/socket.c:2085 x64syscall+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls64.h:43 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f Uninit was stored to memory at: nfrejectip6tcphdrput+0x60c/0x6c0 net/ipv6/netfilter/nfrejectipv6.c:249 nfsendreset6+0xd84/0x15b0 net/ipv6/netfilter/nfrejectipv6.c:344 nftrejectineteval+0x3c1/0x880 net/netfilter/nftrejectinet.c:48 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x438/0x22a0 net/netfilter/nftablescore.c:288 nftdochaininet+0x41a/0x4f0 net/netfilter/nftchainfilter.c:161 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] NFHOOK include/linux/netfilter.h:312 [inline] ipv6rcv+0x29b/0x390 net/ipv6/ip6input.c:310 _netifreceiveskbone_core ---truncated---(CVE-2024-47685)

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SBRDONLY in f2fshandlecriticalerror() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcusyncdtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroysuperwork RIP: 0010:rcusyncdtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpufreerwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroysuperwork+0xec/0x130 fs/super.c:282 processonework kernel/workqueue.c:3231 [inline] processscheduledworks+0xa2c/0x1830 kernel/workqueue.c:3312 workerthread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SBRDONLY flag in internal function, rather than setting the flag covered w/ sb->sumount semaphore via remount procedure, then below race condition causes this bug: - freezesuper() - sbwaitwrite(sb, SBFREEZEWRITE) - sbwaitwrite(sb, SBFREEZEPAGEFAULT) - sbwaitwrite(sb, SBFREEZEFS) - f2fshandlecriticalerror - sb->sflags |= SBRDONLY - thawsuper - thawsuperlocked - sbrdonly() is true, so it skips sbfreezeunlock(sb, SBFREEZEFS) - deactivatelockedsuper Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CPERRORFLAG flag which indicates filesystem is stopped - record errors to superblock - set SBRDONLY falg Once we set CPERRORFLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz(CVE-2024-47689)

In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdupuser() to return ZEROSIZEPTR. When we access the name.data that has been assigned the value of ZEROSIZEPTR in nfs4clienttoreclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4clienttoreclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dumpstack+0x9a/0xd0 [ T1205] ? nfs4clienttoreclaim+0xe9/0x260 [ T1205] _kasanreport.cold+0x34/0x84 [ T1205] ? nfs4clienttoreclaim+0xe9/0x260 [ T1205] kasanreport+0x3a/0x50 [ T1205] nfs4clienttoreclaim+0xe9/0x260 [ T1205] ? nfsd4releaselockowner+0x410/0x410 [ T1205] cldpipedowncall+0x5ca/0x760 [ T1205] ? nfsd4cldtrackingexit+0x1d0/0x1d0 [ T1205] ? downwritekillablenested+0x170/0x170 [ T1205] ? avcpolicyseqno+0x28/0x40 [ T1205] ? selinuxfilepermission+0x1b4/0x1e0 [ T1205] rpcpipewrite+0x84/0xb0 [ T1205] vfswrite+0x143/0x520 [ T1205] ksyswrite+0xc9/0x170 [ T1205] ? _ia32sysread+0x50/0x50 [ T1205] ? ktimegetcoarserealts64+0xfe/0x110 [ T1205] ? ktimegetcoarserealts64+0xa2/0x110 [ T1205] dosyscall64+0x33/0x40 [ T1205] entrySYSCALL64afterhwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.(CVE-2024-47692)

In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to connum - 1 to stay in bounds In the function initconns(), after the createcon() and createcm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to cltpath->s.connum. This commits resets the cid to cltpath->s.connum - 1, to stay in bounds in the cleanup loop later.(CVE-2024-47695)

In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832pidfilter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so setbit and clearbit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. hverkuil: added fixes tag, rtl2830pidfilter -> rtl2832pidfilter in logmsg

In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcmprocread after removeprocentry(). syzbot reported a warning in bcmrelease(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcmprocread triggers unnecessary removeprocentry() in bcmrelease(). Let's clear bo->bcmprocread after removeprocentry() in bcmnotify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 removeprocentry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:removeprocentry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> bcmrelease+0x250/0x880 net/can/bcm.c:1578 _sockrelease net/socket.c:659 [inline] sockclose+0xbc/0x240 net/socket.c:1421 _fput+0x24a/0x8a0 fs/filetable.c:422 taskworkrun+0x24f/0x310 kernel/taskwork.c:228 exittaskwork include/linux/taskwork.h:40 [inline] doexit+0xa2f/0x27f0 kernel/exit.c:882 dogroupexit+0x207/0x2c0 kernel/exit.c:1031 _dosysexitgroup kernel/exit.c:1042 [inline] _sesysexitgroup kernel/exit.c:1040 [inline] _x64sysexitgroup+0x3f/0x40 kernel/exit.c:1040 x64syscall+0x2634/0x2640 arch/x86/include/generated/asm/syscalls64.h:232 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIGRAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 </TASK>(CVE-2024-47709)

In the Linux kernel, the following vulnerability has been resolved: sockmap: Add a condresched() in sockhashfree() Several syzbot soft lockup reports all have in common sockhashfree() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.(CVE-2024-47710)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for setoutputgamma in dcn30setoutputtransferfunc This commit adds a null check for the setoutputgamma function pointer in the dcn30setoutputtransferfunc function. Previously, setoutputgamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if setoutputgamma is indeed null. To fix this, we now ensure that setoutputgamma is not null before dereferencing it. We do this by adding a nullity check for setoutputgamma before the call to setoutputgamma at line 401. If setoutputgamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30hwseq.c:401 dcn30setoutputtransferfunc() error: we previously assumed 'mpc->funcs->setoutputgamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30hwseq.c 373 bool dcn30setoutputtransferfunc(struct dc dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 / program OGAM or 3DLUT only for the top pipe/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /program rmu shaper and 3dlut in MPC/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 / there are no ROM LUTs in OUTGAM */ 396 if (stream->outtransferfunc.type == TFTYPEPREDEFINED) 397 BREAKTODEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->setoutputgamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }(CVE-2024-47720)

In the Linux kernel, the following vulnerability has been resolved: nfsd: call cacheput if xdrreservespace returns NULL If not enough buffer space available, but idmaplookup has triggered lookupfn which calls cacheget and returns successfully. Then we missed to call cacheput here which pairs with cacheget. Reviwed-by: Jeff Layton <jlayton@kernel.org>(CVE-2024-47737)

In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in findasymmetrickey() In findasymmetrickey(), if all NULLs are passed in the id{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id2 gets dereferenced anyway. Add the missing id2 check and move WARNON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.(CVE-2024-47743)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfsbtreecheckdelete() The function nilfsbtreecheckdelete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.(CVE-2024-47757)

In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbdrequeuecmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBDCMDINFLIGHT in nbdrequeuecmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.(CVE-2024-49855)

In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpuonlinemask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHPONLINE] | cpudevicedown() osnoisehotplugworkfn() | | cpuswritelock() | takedowncpu(1) | cpuswriteunlock() [CPUHPOFFLINE] | cpusreadlock() | startkthread(1) | cpusreadunlock() | To fix this, skip online processing if the CPU is already offline.(CVE-2024-49866)

In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at closectree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct taskstruct; 3) We call btrfsstopallworkers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfsadddelayediput(), because the taskstruct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthreadstop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at closectree() before we call kthreadstop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in _lockacquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfsworkhelper Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 _lockacquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lockacquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 _rawspinlockirqsave include/linux/spinlockapismp.h:110 [inline] _rawspinlockirqsave+0xd5/0x120 kernel/locking/spinlock.c:162 classrawspinlockirqsaveconstructor include/linux/spinlock.h:551 [inline] trytowakeup+0xb0/0x1480 kernel/sched/core.c:4154 btrfswritepagefixupworker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfsworkhelper+0x390/0xc50 fs/btrfs/async-thread.c:314 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xa63/0x1850 kernel/workqueue.c:3310 workerthread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244 </TASK> Allocated by task 2: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 unpoisonslabobject mm/kasan/common.c:319 [inline] _kasanslaballoc+0x66/0x80 mm/kasan/common.c:345 kasanslaballoc include/linux/kasan.h:247 [inline] slabpostallochook mm/slub.c:4086 [inline] slaballocnode mm/slub.c:4135 [inline] kmemcacheallocnodenoprof+0x16b/0x320 mm/slub.c:4187 alloctaskstructnode kernel/fork.c:180 [inline] duptaskstruct+0x57/0x8c0 kernel/fork.c:1107 copyprocess+0x5d1/0x3d50 kernel/fork.c:2206 kernelclone+0x223/0x880 kernel/fork.c:2787 kernelthread+0x1bc/0x240 kernel/fork.c:2849 createkthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244 Freed by task 61: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x40/0x50 mm/kasan/generic.c:579 poisonslabobject mm/kasan/common.c:247 [inline] _kasanslabfree+0x59/0x70 mm/kasan/common.c:264 kasanslabfree include/linux/kasan.h:230 [inline] slabfreeh ---truncated---(CVE-2024-49867)

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULTINJECTION: forcing a failure. starttransaction+0x830/0x1670 fs/btrfs/transaction.c:676 preparetorelocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocateblockgroup+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfsupdaterelocroot+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: <TASK> commitfsroots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfscommittransaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 delbalanceitem fs/btrfs/volumes.c:3678 [inline] resetbalancestate+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfsbalance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfsioctlbalance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:907 [inline] _sesysioctl+0xf9/0x170 fs/ioctl.c:893 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f [CAUSE] The allocation failure happens at the starttransaction() inside preparetorelocate(), and during the error handling we call unsetreloccontrol(), which makes fsinfo->balancectl to be NULL. Then we continue the error path cleanup in btrfsbalance() by calling resetbalancestate() which will call delbalanceitem() to fully delete the balance item in the root tree. However during the small window between setreloccontrl() and unsetreloccontrol(), we can have a subvolume tree update and created a relocroot for that subvolume. Then we go into the final btrfscommittransaction() of delbalanceitem(), and into btrfsupdaterelocroot() inside commitfsroots(). That function checks if fsinfo->relocctl is in the mergereloctree stage, but since fsinfo->relocctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fsinfo->relocctl inside btrfsupdaterelocroot(), before checking fsinfo->relocctl->mergereloctree. That DEADRELOCTREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.(CVE-2024-49868)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the cm3_helper_translate_curve_to_degamma_hw_format function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFERFUNCPOINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30cmcommon.c:338 cm3helpertranslatecurvetodegammahwformat() error: buffer overflow 'outputtf->tfpts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30cmcommon.c:339 cm3helpertranslatecurvetodegammahwformat() error: buffer overflow 'outputtf->tfpts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30cmcommon.c:340 cm3helpertranslatecurvetodegammahwformat() error: buffer overflow 'outputtf->tf_pts.blue' 1025 <= s32max(CVE-2024-49895)

In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of newea in eabuffer syzbot reports that lzo1x1docompress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x1docompress+0x19f9/0x2510 lib/lzo/lzo1xcompress.c:178 ... Uninit was stored to memory at: eaput fs/jfs/xattr.c:639 [inline] ... Local variable eabuf created at: _jfssetxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 _jfsxattrset+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is eabuf->newea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)

In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmtleafidx greater than num leaves per dmap tree, add a checking for dmtleafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.(CVE-2024-49902)

In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in _mutexlockcommon kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in _mutexlock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:93 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:119 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 _mutexlockcommon kernel/locking/mutex.c:587 [inline] _mutexlock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfsdmap.c:2390 dbFreeDmap fs/jfs/jfsdmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfsdmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfsdmap.c:1650 jfsioctrim+0x433/0x670 fs/jfs/jfsdiscard.c:100 jfsioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:907 [inline] _sesysioctl+0xfc/0x170 fs/ioctl.c:893 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x40/0x50 mm/kasan/generic.c:579 poisonslabobject+0xe0/0x150 mm/kasan/common.c:240 _kasanslabfree+0x37/0x60 mm/kasan/common.c:256 kasanslabfree include/linux/kasan.h:184 [inline] slabfreehook mm/slub.c:2252 [inline] slabfree mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfsdmap.c:278 jfsmountrw+0x4ac/0x6a0 fs/jfs/jfsmount.c:247 jfsremount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfiguresuper+0x445/0x880 fs/super.c:1083 vfscmdreconfigure fs/fsopen.c:263 [inline] vfsfsconfiglocked fs/fsopen.c:292 [inline] _dosysfsconfig fs/fsopen.c:473 [inline] _sesysfsconfig+0xb6e/0xf80 fs/fsopen.c:345 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f [Analysis] There are two paths (dbUnmount and jfsioctrim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.(CVE-2024-49903)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20setoutputtransferfunc This commit adds a null check for the setoutputgamma function pointer in the dcn20setoutputtransferfunc function. Previously, setoutputgamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if setoutputgamma is null. To fix this, we now ensure that setoutputgamma is not null before dereferencing it. We do this by adding a null check for setoutputgamma before the call to setoutputgamma at line 1048.(CVE-2024-49911)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for headpipe in dcn32acquireidlepipeforheadpipeinlayer This commit addresses a potential null pointer dereference issue in the dcn32_acquire_idle_pipe_for_head_pipe_in_layer function. The issue could occur when head_pipe is null. The fix adds a check to ensure head_pipe is not null before asserting it. If head_pipe is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32resource.c:2690 dcn32acquireidlepipeforheadpipeinlayer() error: we previously assumed 'head_pipe' could be null (see line 2681)(CVE-2024-49918)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for headpipe in dcn201acquirefreepipeforlayer This commit addresses a potential null pointer dereference issue in the dcn201_acquire_free_pipe_for_layer function. The issue could occur when head_pipe is null. The fix adds a check to ensure head_pipe is not null before asserting it. If head_pipe is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201resource.c:1016 dcn201acquirefreepipeforlayer() error: we previously assumed 'head_pipe' could be null (see line 1010)(CVE-2024-49919)

In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irqpinlist (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mpirqdomainalloc+0x9ab/0xa80 irqdomainallocirqslocked+0x25d/0x8d0 _irqdomainallocirqs+0x80/0x110 mpmappintoirq+0x645/0x890 acpiregistergsiioapic+0xe6/0x150 hpetopen+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timercheck() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around _addpintoirqnode() and making mpirqdomainalloc() aware of the failure condition and handle it as any other failure in this function gracefully.(CVE-2024-49927)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2readblocks Patch series "Misc fixes for ocfs2readblocks", v5. This series contains 2 fixes for ocfs2readblocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2readblocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.(CVE-2024-49965)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the cm3_helper_translate_curve_to_hw_format function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFERFUNCPOINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30cmcommon.c:180 cm3helpertranslatecurvetohwformat() error: buffer overflow 'outputtf->tfpts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30cmcommon.c:181 cm3helpertranslatecurvetohwformat() error: buffer overflow 'outputtf->tfpts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30cmcommon.c:182 cm3helpertranslatecurvetohwformat() error: buffer overflow 'outputtf->tfpts.blue' 1025 <= s32max(CVE-2024-49969)

In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.(CVE-2024-49974)

In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interfacelock in stopkthread() stopkthread() is the offline callback for "trace/osnoise:online", since commit 5bfbcd1ee57b ("tracing/timerlat: Add interfacelock around clearing of kthread in stopkthread()"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoisehotplugworkfn() | workforcpufn() | cpuhpthreadfun() | cpudown() | osnoisecpudie() mutexlock(&interfacelock) | | stopkthread() | cpuswritelock() | mutexlock(&interfacelock) cpusreadlock() | cpuhpkickap() | As the interfacelock here in just for protecting the "kthread" field of the osnvar, use xchg() instead to fix this issue. Also use foreachonlinecpu() back in stoppercpukthreads() as it can take cpuread_lock() again.(CVE-2024-49976)

In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clkops .prepare callback may trigger a deadlock on drivers/clk/clk.c preparelock mutex. This is because the clock controller first grabs the preparelock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtimeresume callback, which calls clkprepareenable(), which attempts to grab the preparelock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clkenable()/clkdisable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the preparelock mutex.(CVE-2024-49985)

In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.(CVE-2024-50007)

In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parseperfdomain function, if the call to ofparsephandlewithargs returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the _free(devicenode) cleanup attribute.(CVE-2024-50012)

In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42completecopies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42completecopies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsecgsskrb5 authrpcgss nfsv4 dnsresolver nfs lockd grace fscache netfs ocfs2dlmfs ocfs2stacko2cb ocfs2dlm vhostnet vhost vhostiotlb tap tun iptrpfilter xtmultiport ipsethaship ipsethashnet xfrminterface xfrm6tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519generic veth xtaddrtype xtset nfconntracknetlink ipsethashipportnet ipsethashipportip ipsetbitmapport ipsethashipport dummy ipset ipvssh ipvswrr ipvsrr ipvs iptablefilter schingress nfnetlinkcttimeout vportgre ipgre iptunnel gre vportgeneve geneve vportvxlan vxlan ip6udptunnel udptunnel openvswitch nfconncount dmroundrobin dmservicetime dmmultipath xtnat xtMASQUERADE nftchainnat nfnat xtmark xtconntrack xtcomment nftcompat nftcounter nftables nfnetlink ocfs2 ocfs2nodemanager ocfs2stackglue iscsitcp libiscsitcp libiscsi scsitransportiscsi ipmissif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cascache casdisk ses enclosure scsitransportsas sg acpiipmi ipmisi ipmidevintf ipmimsghandler iptables vfiopci vfiopcicore vfiovirqfd vfioiommutype1 vfio dmmirror dmregionhash dmlog dmmod nfconntrack nfdefragipv6 nfdefragipv4 brnetfilter bridge stp llc fuse xfs libcrc32c ast drmvramhelper qla2xxx drmkmshelper syscopyarea crct10difce sysfillrect ghashce sysimgblt sha2ce fbsysfops cec sha256arm64 sha1ce drmttmhelper ttm nvmefc igb sbsagwdt nvmefabrics drm nvmecore i2calgobit i40e scsitransportfc megaraidsas aesneonbs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBEV3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4reclaimopenstate+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4reclaimopenstate+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---(CVE-2024-50046)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-50049)

In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devmfreeirq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devmfreeirq+0x80/0x8c ... ... Call trace: devmfreeirq+0x80/0x8c tps6598xremove+0x28/0x88 [tps6598x] i2cdeviceremove+0x2c/0x9c deviceremove+0x4c/0x80 devicereleasedriverinternal+0x1cc/0x228 driverdetach+0x50/0x98 busremovedriver+0x6c/0xbc driverunregister+0x30/0x60 i2cdeldriver+0x54/0x64 tps6598xi2cdriverexit+0x18/0xc3c [tps6598x] _arm64sysdeletemodule+0x184/0x264 invokesyscall+0x48/0x110 el0svccommon.constprop.0+0xc8/0xe8 doel0svc+0x20/0x2c el0svc+0x28/0x98 el0t64synchandler+0x13c/0x158 el0t64_sync+0x190/0x194(CVE-2024-50057)

In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfsdhash dhash is done while under "rcu-walk" and should not sleep. _getname() allocates using GFPKERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.(CVE-2024-50065)