The Linux Kernel, the operating system core itself.

Security Fix(es):

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

thermal: Fix NULL pointer dereferences in ofthermal functions

ofparsethermalzones() parses the thermal-zones node and registers a thermalzone device for each subnode. However, if a thermal zone is consuming a thermal sensor and that thermal sensor device hasn't probed yet, an attempt to set trippoint*_temp for that thermal zone device can cause a NULL pointer dereference. Fix it.

console:/sys/class/thermal/thermalzone87 # echo 120000 > trippoint0temp ... Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... Call trace: ofthermalsettriptemp+0x40/0xc4 trippointtempstore+0xc0/0x1dc devattrstore+0x38/0x88 sysfskfwrite+0x64/0xc0 kernfsfopwriteiter+0x108/0x1d0 vfswrite+0x2f4/0x368 ksyswrite+0x7c/0xec _arm64syswrite+0x20/0x30 el0svccommon.llvm.7279915941325364641+0xbc/0x1bc doel0svc+0x28/0xa0 el0svc+0x14/0x24 el0synchandler+0x88/0xec el0_sync+0x1c0/0x200

While at it, fix the possible NULL pointer dereference in other functions as well: ofthermalgettemp(), ofthermalsetemultemp(), ofthermalgettrend().(CVE-2021-47202)

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

ipvlan: Dont Use skb->sk in ipvlanprocessv{4,6}_outbound

Raw packet from PFPACKET socket ontop of an IPv6-backed ipvlan device will hit WARNONONCE() in skmcloop() through schdirect_xmit() path.

WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 skmcloop+0x2d/0x70 Modules linked in: schnetem ipvlan rfkill cirrus drmshmemhelper sg drmkmshelper CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:skmcloop+0x2d/0x70 Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212 RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001 RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000 RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00 R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000 R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000 FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? _warn (kernel/panic.c:693) ? skmcloop (net/core/sock.c:760) ? reportbug (lib/bug.c:201 lib/bug.c:219) ? handlebug (arch/x86/kernel/traps.c:239) ? excinvalidop (arch/x86/kernel/traps.c:260 (discriminator 1)) ? asmexcinvalidop (./arch/x86/include/asm/idtentry.h:621) ? skmcloop (net/core/sock.c:760) ip6finishoutput2 (net/ipv6/ip6output.c:83 (discriminator 1)) ? nfhookslow (net/netfilter/core.c:626) ip6finishoutput (net/ipv6/ip6output.c:222) ? _pfxip6finishoutput (net/ipv6/ip6output.c:215) ipvlanxmitmodel3 (drivers/net/ipvlan/ipvlancore.c:602) ipvlan ipvlanstartxmit (drivers/net/ipvlan/ipvlanmain.c:226) ipvlan devhardstartxmit (net/core/dev.c:3594) schdirectxmit (net/sched/schgeneric.c:343) _qdiscrun (net/sched/schgeneric.c:416) nettxaction (net/core/dev.c:5286) handlesoftirqs (kernel/softirq.c:555) _irqexitrcu (kernel/softirq.c:589) sysvecapictimer_interrupt (arch/x86/kernel/apic/apic.c:1043)

The warning triggers as this: packetsendmsg packetsnd //skb->sk is packet sk _devqueuexmit _devxmitskb //q->enqueue is not NULL _qdiscrun schdirectxmit devhardstartxmit ipvlanstartxmit ipvlanxmitmodel3 //l3 mode ipvlanprocessoutbound //vepa flag ipvlanprocessv6outbound ip6localout _ip6finishoutput ip6finishoutput2 //multicast packet skmcloop //sk->skfamily is AFPACKET

Call ip{6}localout() with NULL sk in ipvlan as other tunnels to fix this.(CVE-2024-33621)

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

jfs: xattr: fix buffer overflow for invalid xattr

When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer.

Fix this all up by properly restricting the size of the debug hex dump in the kernel log.(CVE-2024-40902)

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

xfrm6: check ip6dstidev() return value in xfrm6getsaddr()

ip6dstidev() can return NULL, xfrm6getsaddr() must act accordingly.

syzbot reported:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: wg-kex-wg1 wgpackethandshakesendworker RIP: 0010:xfrm6getsaddr+0x93/0x130 net/ipv6/xfrm6policy.c:64 Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00 RSP: 0018:ffffc90000117378 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7 RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98 RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000 R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> xfrmgetsaddr net/xfrm/xfrmpolicy.c:2452 [inline] xfrmtmplresolveone net/xfrm/xfrmpolicy.c:2481 [inline] xfrmtmplresolve+0xa26/0xf10 net/xfrm/xfrmpolicy.c:2541 xfrmresolveandcreatebundle+0x140/0x2570 net/xfrm/xfrmpolicy.c:2835 xfrmbundlelookup net/xfrm/xfrmpolicy.c:3070 [inline] xfrmlookupwithifid+0x4d1/0x1e60 net/xfrm/xfrmpolicy.c:3201 xfrmlookup net/xfrm/xfrmpolicy.c:3298 [inline] xfrmlookuproute+0x3b/0x200 net/xfrm/xfrmpolicy.c:3309 ip6dstlookupflow+0x15c/0x1d0 net/ipv6/ip6output.c:1256 send6+0x611/0xd20 drivers/net/wireguard/socket.c:139 wgsocketsendskbtopeer+0xf9/0x220 drivers/net/wireguard/socket.c:178 wgsocketsendbuffertopeer+0x12b/0x190 drivers/net/wireguard/socket.c:200 wgpacketsendhandshakeinitiation+0x227/0x360 drivers/net/wireguard/send.c:40 wgpackethandshakesendworker+0x1c/0x30 drivers/net/wireguard/send.c:51 processonework+0x9fb/0x1b60 kernel/workqueue.c:3231 processscheduledworks kernel/workqueue.c:3312 [inline] workerthread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 retfromfork+0x45/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-40959)

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

netrom: Fix a memory leak in nrheartbeatexpiry()

syzbot reported a memory leak in nr_create() [0].

Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.") added sockhold() to the nrheartbeatexpiry() function, where a) a socket has a SOCKDESTROY flag or b) a listening socket has a SOCK_DEAD flag.

But in the case "a," when the SOCKDESTROY flag is set, the file descriptor has already been closed and the nrrelease() function has been called. So it makes no sense to hold the reference count because no one will call another nrdestroysocket() and put it as in the case "b."

nrconnect nrestablishdatalink nrstartheartbeat

nrrelease switch (nr->state) case NRSTATE3 nr->state = NRSTATE2 socksetflag(sk, SOCKDESTROY);

                    nr_rx_frame
                      nr_process_rx_frame
                        switch (nr->state)
                        case NR_STATE_2
                          nr_state2_machine()
                            nr_disconnect()
                              nr_sk(sk)->state = NR_STATE_0
                              sock_set_flag(sk, SOCK_DEAD)

                    nr_heartbeat_expiry
                      switch (nr->state)
                      case NR_STATE_0
                        if (sock_flag(sk, SOCK_DESTROY) ||
                           (sk->sk_state == TCP_LISTEN
                             && sock_flag(sk, SOCK_DEAD)))
                           sock_hold()  // ( !!! )
                           nr_destroy_socket()

To fix the memory leak, let's call sock_hold() only for a listening socket.

Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.

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

xfs: add bounds checking to xlogrecoverprocess_data

There is a lack of verification of the space occupied by fixed members of xlogopheader in the xlogrecoverprocess_data.

We can create a crafted image to trigger an out of bounds read by following these steps: 1) Mount an image of xfs, and do some file operations to leave records 2) Before umounting, copy the image for subsequent steps to simulate abnormal exit. Because umount will ensure that tailblk and headblk are the same, which will result in the inability to enter xlogrecoverprocessdata 3) Write a tool to parse and modify the copied image in step 2 4) Make the end of the xlogopheader entries only 1 byte away from xlogrecheader->hsize 5) xlogrecheader->hnumlogops++ 6) Modify xlogrecheader->h_crc

Fix: Add a check to make sure there is sufficient space to access fixed members of xlogopheader.(CVE-2024-41014)

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

jfs: don't walk off the end of ealist

Add a check before visiting the members of ea to make sure each ea stays within the ealist.(CVE-2024-41017)

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

filelock: Fix fcntl/close race recovery compat path

When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected"), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels. Thanks to Greg KH for stumbling over this while doing the stable backport...

Apply exactly the same fix to the compat path for 32-bit kernels.(CVE-2024-41020)

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

ppp: reject claimed-as-LCP but actually malformed packets

Since 'pppasyncencode()' assumes valid LCP packets (with code from 1 to 7 inclusive), add 'pppcheckpacket()' to ensure that LCP packet has an actual body beyond PPP_LCP header bytes, and reject claimed-as-LCP but actually malformed data otherwise.(CVE-2024-41044)

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

Bluetooth: hcicore: cancel all works upon hciunregister_dev()

syzbot is reporting that calling hcireleasedev() from hcierrorreset() due to hcidevput() from hcierrorreset() can cause deadlock at destroyworkqueue(), for hcierrorreset() is called from hdev->reqworkqueue which destroy_workqueue() needs to flush.

We need to make sure that hdev->{rxwork,cmdwork,txwork} which are queued into hdev->workqueue and hdev->{poweron,errorreset} which are queued into hdev->reqworkqueue are no longer running by the moment

   destroy_workqueue(hdev->workqueue);
   destroy_workqueue(hdev->req_workqueue);

are called from hcireleasedev().

Call cancelworksync() on these work items from hciunregisterdev() as soon as hdev->list is removed from hcidevlist.(CVE-2024-41063)

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

ASoC: topology: Fix references to freed memory

Most users after parsing a topology file, release memory used by it, so having pointer references directly into topology file contents is wrong. Use devm_kmemdup(), to allocate memory as needed.(CVE-2024-41069)

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

wifi: cfg80211: wext: add extra SIOCSIWSCAN data check

In 'cfg80211wextsiwscan()', add extra check whether number of channels passed via 'ioctl(sock, SIOCSIWSCAN, ...)' doesn't exceed IWMAXFREQUENCIES and reject invalid request with -EINVAL otherwise.(CVE-2024-41072)

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

ila: block BH in ila_output()

As explained in commit 1378817486d6 ("tipc: block BH before using dstcache"), net/core/dstcache.c helpers need to be called with BH disabled.

ilaoutput() is called from lwtunneloutput() possibly from process context, and under rcureadlock().

We might be interrupted by a softirq, re-enter ilaoutput() and corrupt dstcache data structures.

Fix the race by using localbhdisable().(CVE-2024-41081)

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

drm/nouveau/dispnv04: fix null pointer dereference in nv17tvgethdmodes

In nv17tvgethdmodes(), the return value of drmmodeduplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drmmodeduplicate(). The same applies to drmcvtmode(). Add a check to avoid null pointer dereference.(CVE-2024-41089)

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

drm/nouveau/dispnv04: fix null pointer dereference in nv17tvgetldmodes

In nv17tvgetldmodes(), the return value of drmmodeduplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drmmodeduplicate(). Add a check to avoid npd.(CVE-2024-41095)

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

usb: atm: cxacru: fix endpoint checking in cxacru_bind()

Syzbot is still reporting quite an old issue [1] that occurs due to incomplete checking of present usb endpoints. As such, wrong endpoints types may be used at urb sumbitting stage which in turn triggers a warning in usbsubmiturb().

Fix the issue by verifying that required endpoint types are present for both in and out endpoints, taking into account cmd endpoint type.

Unfortunately, this patch has not been tested on real hardware.

[1] Syzbot report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usbsubmiturb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usbhubwq hubevent RIP: 0010:usbsubmiturb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Call Trace: cxacrucm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacrucardstatus+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacrubind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatmusbprobe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacruusbprobe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usbprobeinterface+0x315/0x7f0 drivers/usb/core/driver.c:396 calldriverprobe drivers/base/dd.c:517 [inline] reallyprobe+0x23c/0xcd0 drivers/base/dd.c:595 _driverprobedevice+0x338/0x4d0 drivers/base/dd.c:747 driverprobedevice+0x4c/0x1a0 drivers/base/dd.c:777 _deviceattachdriver+0x20b/0x2f0 drivers/base/dd.c:894 busforeachdrv+0x15f/0x1e0 drivers/base/bus.c:427 _deviceattach+0x228/0x4a0 drivers/base/dd.c:965 busprobedevice+0x1e4/0x290 drivers/base/bus.c:487 deviceadd+0xc2f/0x2180 drivers/base/core.c:3354 usbsetconfiguration+0x113a/0x1910 drivers/usb/core/message.c:2170 usbgenericdriverprobe+0xba/0x100 drivers/usb/core/generic.c:238 usbprobe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293(CVE-2024-41097)

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

ocfs2: fix DIO failure due to insufficient transaction credits

The code in ocfs2dioendiowrite() estimates number of necessary transaction credits using ocfs2calcextend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents.

Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2markextentwritten() will end up calling ocfs2replaceextentrec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Once that happens a WARNON(jbd2handlebuffercredits(handle) <= 0) is triggered in jbd2journaldirty_metadata() and subsequently OCFS2 aborts in response to this error. This was actually triggered by one of our customers on a heavily fragmented OCFS2 filesystem.

To fix the issue make sure the transaction always has enough credits for one extent insert before each call of ocfs2markextent_written().

Heming Zhao said:

PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error"

PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA" #0 machinekexec at ffffffff8c069932 #1 _crashkexec at ffffffff8c1338fa #2 panic at ffffffff8c1d69b9 #3 ocfs2handleerror at ffffffffc0c86c0c [ocfs2] #4 _ocfs2abort at ffffffffc0c88387 [ocfs2] #5 ocfs2journaldirty at ffffffffc0c51e98 [ocfs2] #6 ocfs2splitextent at ffffffffc0c27ea3 [ocfs2] #7 ocfs2changeextentflag at ffffffffc0c28053 [ocfs2] #8 ocfs2markextentwritten at ffffffffc0c28347 [ocfs2] #9 ocfs2dioendio_write at ffffffffc0c2bef9 [ocfs2]

10 ocfs2dioend_io at ffffffffc0c2c0f5 [ocfs2]

11 dio_complete at ffffffff8c2b9fa7

12 doblockdevdirect_IO at ffffffff8c2bc09f

13 ocfs2directIO at ffffffffc0c2b653 [ocfs2]

14 genericfiledirect_write at ffffffff8c1dcf14

15 _genericfilewriteiter at ffffffff8c1dd07b

16 ocfs2filewrite_iter at ffffffffc0c49f1f [ocfs2]

17 aio_write at ffffffff8c2cc72e

18 kmemcachealloc at ffffffff8c248dde

19 doiosubmit at ffffffff8c2ccada

20 dosyscall64 at ffffffff8c004984

21 entrySYSCALL64afterhwframe at ffffffff8c8000ba(CVE-2024-42077)

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

iio: chemical: bme680: Fix overflows in compensate() functions

There are cases in the compensate functions of the driver that there could be overflows of variables due to bit shifting ops. These implications were initially discussed here [1] and they were mentioned in log message of Commit 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor").

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

pinctrl: fix deadlock in createpinctrl() when handling -EPROBEDEFER

In createpinctrl(), pinctrlmapsmutex is acquired before calling addsetting(). If addsetting() returns -EPROBEDEFER, createpinctrl() calls pinctrlfree(). However, pinctrlfree() attempts to acquire pinctrlmapsmutex, which is already held by createpinctrl(), leading to a potential deadlock.

This patch resolves the issue by releasing pinctrlmapsmutex before calling pinctrl_free(), preventing the deadlock.

This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.(CVE-2024-42090)

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

gpio: davinci: Validate the obtained number of IRQs

Value of pdata->gpiounbanked is taken from Device Tree. In case of broken DT due to any error this value can be any. Without this value validation there can be out of chips->irqs array boundaries access in davincigpio_probe().

Validate the obtained nirq value so that it won't exceed the maximum number of IRQs per bank.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-42092)

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

net/iucv: Avoid explicit cpumask var allocation on stack

For CONFIGCPUMASKOFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow.

Instead, kernel code should always use *cpumaskvar API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIGCPUMASK_OFFSTACK.

Use *cpumask_var API(s) to address it.(CVE-2024-42094)

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

ALSA: emux: improve patch ioctl data validation

In loaddata(), make the validation of and skipping over the main info block match that in loadguspatch().

In loadguspatch(), add checking that the specified patch length matches the actually supplied data, like loaddata() already did.(CVE-2024-42097)

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

nilfs2: add missing check for inode numbers on directory entries

Syzbot reported that mounting and unmounting a specific pattern of corrupted nilfs2 filesystem images causes a use-after-free of metadata file inodes, which triggers a kernel bug in lruaddfn().

As Jan Kara pointed out, this is because the link count of a metadata file gets corrupted to 0, and nilfsevictinode(), which is called from iput(), tries to delete that inode (ifile inode in this case).

The inconsistency occurs because directories containing the inode numbers of these metadata files that should not be visible in the namespace are read without checking.

Fix this issue by treating the inode numbers of these internal files as errors in the sanity check helper when reading directory folios/pages.

Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer analysis.(CVE-2024-42104)

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

inetdiag: Initialize pad field in struct inetdiagreqv2

KMSAN reported uninit-value access in rawlookup() [1]. Diag for raw sockets uses the pad field in struct inetdiagreqv2 for the underlying protocol. This field corresponds to the sdiagrawprotocol field in struct inetdiagreq_raw.

inetdiaggetexactcompat() converts inetdiagreq to inetdiagreqv2, but leaves the pad field uninitialized. So the issue occurs when rawlookup() accesses the sdiagrawprotocol field.

Fix this by initializing the pad field in inetdiaggetexactcompat(). Also, do the same fix in inetdiagdump_compat() to avoid the similar issue in the future.

[1] BUG: KMSAN: uninit-value in rawlookup net/ipv4/rawdiag.c:49 [inline] BUG: KMSAN: uninit-value in rawsockget+0x657/0x800 net/ipv4/rawdiag.c:71 rawlookup net/ipv4/rawdiag.c:49 [inline] rawsockget+0x657/0x800 net/ipv4/rawdiag.c:71 rawdiagdumpone+0xa1/0x660 net/ipv4/rawdiag.c:99 inetdiagcmdexact+0x7d9/0x980 inetdiaggetexactcompat net/ipv4/inetdiag.c:1404 [inline] inetdiagrcvmsgcompat+0x469/0x530 net/ipv4/inetdiag.c:1426 sockdiagrcvmsg+0x23d/0x740 net/core/sockdiag.c:282 netlinkrcvskb+0x537/0x670 net/netlink/afnetlink.c:2564 sockdiagrcv+0x35/0x40 net/core/sockdiag.c:297 netlinkunicastkernel net/netlink/afnetlink.c:1335 [inline] netlinkunicast+0xe74/0x1240 net/netlink/afnetlink.c:1361 netlinksendmsg+0x10c6/0x1260 net/netlink/afnetlink.c:1905 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x332/0x3d0 net/socket.c:745 _syssendmsg+0x7f0/0xb70 net/socket.c:2585 _syssendmsg+0x271/0x3b0 net/socket.c:2639 _syssendmsg net/socket.c:2668 [inline] _dosyssendmsg net/socket.c:2677 [inline] _sesyssendmsg net/socket.c:2675 [inline] _x64syssendmsg+0x27e/0x4a0 net/socket.c:2675 x64syscall+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls64.h:47 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd9/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was stored to memory at: rawsockget+0x650/0x800 net/ipv4/rawdiag.c:71 rawdiagdumpone+0xa1/0x660 net/ipv4/rawdiag.c:99 inetdiagcmdexact+0x7d9/0x980 inetdiaggetexactcompat net/ipv4/inetdiag.c:1404 [inline] inetdiagrcvmsgcompat+0x469/0x530 net/ipv4/inetdiag.c:1426 sockdiagrcvmsg+0x23d/0x740 net/core/sockdiag.c:282 netlinkrcvskb+0x537/0x670 net/netlink/afnetlink.c:2564 sockdiagrcv+0x35/0x40 net/core/sockdiag.c:297 netlinkunicastkernel net/netlink/afnetlink.c:1335 [inline] netlinkunicast+0xe74/0x1240 net/netlink/afnetlink.c:1361 netlinksendmsg+0x10c6/0x1260 net/netlink/afnetlink.c:1905 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x332/0x3d0 net/socket.c:745 syssendmsg+0x7f0/0xb70 net/socket.c:2585 _syssendmsg+0x271/0x3b0 net/socket.c:2639 _syssendmsg net/socket.c:2668 [inline] _dosyssendmsg net/socket.c:2677 [inline] _sesyssendmsg net/socket.c:2675 [inline] _x64syssendmsg+0x27e/0x4a0 net/socket.c:2675 x64syscall+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls64.h:47 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd9/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Local variable req.i created at: inetdiaggetexactcompat net/ipv4/inetdiag.c:1396 [inline] inetdiagrcvmsgcompat+0x2a6/0x530 net/ipv4/inetdiag.c:1426 sockdiagrcvmsg+0x23d/0x740 net/core/sockdiag.c:282

CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014(CVE-2024-42106)

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

jffs2: Fix potential illegal address access in jffs2freeinode

During the stress testing of the jffs2 file system,the following abnormal printouts were found: [ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948 [ 2430.649622] Mem abort info: [ 2430.649829] ESR = 0x96000004 [ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits [ 2430.650564] SET = 0, FnV = 0 [ 2430.650795] EA = 0, S1PTW = 0 [ 2430.651032] FSC = 0x04: level 0 translation fault [ 2430.651446] Data abort info: [ 2430.651683] ISV = 0, ISS = 0x00000004 [ 2430.652001] CM = 0, WnR = 0 [ 2430.652558] [0069696969696948] address between user and kernel address ranges [ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33 [ 2430.655008] Hardware name: linux,dummy-virt (DT) [ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2430.656142] pc : kfree+0x78/0x348 [ 2430.656630] lr : jffs2freeinode+0x24/0x48 [ 2430.657051] sp : ffff800009eebd10 [ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000 [ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000 [ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14 [ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000 [ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000 [ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19 [ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14 [ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302 [ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342 [ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000 [ 2430.664217] Call trace: [ 2430.664528] kfree+0x78/0x348 [ 2430.664855] jffs2freeinode+0x24/0x48 [ 2430.665233] icallback+0x24/0x50 [ 2430.665528] rcudobatch+0x1ac/0x448 [ 2430.665892] rcucore+0x28c/0x3c8 [ 2430.666151] rcucoresi+0x18/0x28 [ 2430.666473] _dosoftirq+0x138/0x3cc [ 2430.666781] irqexit+0xf0/0x110 [ 2430.667065] handledomainirq+0x6c/0x98 [ 2430.667447] gichandleirq+0xac/0xe8 [ 2430.667739] callonirqstack+0x28/0x54 The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of the jffsinodeinfo structure. It was found that all variables in the jffsinodeinfo structure were 5a5a5a5a, except for the first member sem. It is suspected that these variables are not initialized because they were set to 5a5a5a5a during memory testing, which is meant to detect uninitialized memory.The sem variable is initialized in the function jffs2iinitonce, while other members are initialized in the function jffs2initinodeinfo.

The function jffs2initinodeinfo is called after igetlocked, but in the igetlocked function, the destroyinode process is triggered, which releases the inode and consequently, the target member of the inode is not initialized.In concurrent high pressure scenarios, igetlocked may enter the destroyinode branch as described in the code.

Since the destroyinode functionality of jffs2 only releases the target, the fix method is to set target to NULL in jffs2iinitonce.(CVE-2024-42115)

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

drm/amd/display: Skip finding free audio for unknown engine_id

[WHY] ENGINEIDUNKNOWN = -1 and can not be used as an array index. Plus, it also means it is uninitialized and does not need free audio.

[HOW] Skip and return NULL.

This fixes 2 OVERRUN issues reported by Coverity.(CVE-2024-42119)

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

IB/core: Implement a limit on UMAD receive List

The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow.

To address this, we introduce a limit to the size of the list. After considering typical scenarios, such as OpenSM processing, which can handle approximately 100k packets per second, and the 1-second retry timeout for most packets, we set the list size limit to 200k. Packets received beyond this limit are dropped, assuming they are likely timed out by the time they are handled by user-space.

Notably, packets queued on the receive list due to reasons like timed-out sends are preserved even when the list is full.(CVE-2024-42145)

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

net: dsa: mv88e6xxx: Correct check for empty list

Since commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO busses") mv88e6xxxdefaultmdiobus() has checked that the return value of listfirst_entry() is non-NULL.

This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of listfirstentry is not designed to return NULL for empty lists.

Instead, use listfirstentryornull() which does return NULL if the list is empty.

Flagged by Smatch. Compile tested only.(CVE-2024-42224)

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

drm/amdgpu: Using uninitialized value *size when calling amdgpuvcecs_reloc

Initialize the size before calling amdgpuvcecs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)(CVE-2024-42228)