OESA-2024-2220

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

bcache: fix variable length array abuse in btree_iter

btreeiter is used in two ways: either allocated on the stack with a fixed size MAXBSETS, or from a mempool with a dynamic size based on the specific cache set. Previously, the struct had a fixed-length array of size MAX_BSETS which was indexed out-of-bounds for the dynamically-sized iterators, which causes UBSAN to complain.

This patch uses the same approach as in bcachefs's sortiter and splits the iterator into a btreeiter with a flexible array member and a btreeiterstack which embeds a btree_iter as well as a fixed-length data array.(CVE-2024-39482)

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

ksmbd: discard write access to the directory open

may_open() does not allow a directory to be opened with the write access. However, some writing flags set by client result in adding write access on server, making ksmbd incompatible with FUSE file system. Simply, let's discard the write access when opening a directory.

listadd corruption. next is NULL. ------------[ cut here ]------------ kernel BUG at lib/listdebug.c:26! pc : _listaddvalid+0x88/0xbc lr : _listaddvalid+0x88/0xbc Call trace: _listaddvalid+0x88/0xbc fusefinishopen+0x11c/0x170 fuseopencommon+0x284/0x5e8 fusediropen+0x14/0x24 dodentryopen+0x2a4/0x4e0 dentryopen+0x50/0x80 smb2open+0xbe4/0x15a4 handleksmbdwork+0x478/0x5ec processonework+0x1b4/0x448 workerthread+0x25c/0x430 kthread+0x104/0x1d4 retfromfork+0x10/0x20(CVE-2024-41030)

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:

media: xc2028: avoid use-after-free in loadfirmwarecb()

syzkaller reported use-after-free in loadfirmwarecb() [1]. The reason is because the module allocated a struct tuner in tuner_probe(), and then the module initialization failed, the struct tuner was released. A worker which created during module initialization accesses this struct tuner later, it caused use-after-free.

The process is as follows:

task-6504 workerthread tunerprobe <= alloc dvbfrontend [2] ... requestfirmwarenowait <= create a worker ... tunerremove <= free dvbfrontend ... requestfirmwareworkfunc <= the firmware is ready loadfirmwarecb <= but now the dvb_frontend has been freed

To fix the issue, check the dvdfrontend in loadfirmware_cb(), if it is null, report a warning and just return.

 BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0
 Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504

 Call trace:
  load_firmware_cb+0x1310/0x17a0
  request_firmware_work_func+0x128/0x220
  process_one_work+0x770/0x1824
  worker_thread+0x488/0xea0
  kthread+0x300/0x430
  ret_from_fork+0x10/0x20

 Allocated by task 6504:
  kzalloc
  tuner_probe+0xb0/0x1430
  i2c_device_probe+0x92c/0xaf0
  really_probe+0x678/0xcd0
  driver_probe_device+0x280/0x370
  __device_attach_driver+0x220/0x330
  bus_for_each_drv+0x134/0x1c0
  __device_attach+0x1f4/0x410
  device_initial_probe+0x20/0x30
  bus_probe_device+0x184/0x200
  device_add+0x924/0x12c0
  device_register+0x24/0x30
  i2c_new_device+0x4e0/0xc44
  v4l2_i2c_new_subdev_board+0xbc/0x290
  v4l2_i2c_new_subdev+0xc8/0x104
  em28xx_v4l2_init+0x1dd0/0x3770

 Freed by task 6504:
  kfree+0x238/0x4e4
  tuner_remove+0x144/0x1c0
  i2c_device_remove+0xc8/0x290
  __device_release_driver+0x314/0x5fc
  device_release_driver+0x30/0x44
  bus_remove_device+0x244/0x490
  device_del+0x350/0x900
  device_unregister+0x28/0xd0
  i2c_unregister_device+0x174/0x1d0
  v4l2_device_unregister+0x224/0x380
  em28xx_v4l2_init+0x1d90/0x3770

 The buggy address belongs to the object at ffff8000d7ca2000
  which belongs to the cache kmalloc-2k of size 2048
 The buggy address is located 776 bytes inside of
  2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)
 The buggy address belongs to the page:
 page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0
 flags: 0x7ff800000000100(slab)
 raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000
 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
 page dumped because: kasan: bad access detected

 Memory state around the buggy address:
  ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 >ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                       ^
  ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ==================================================================

[2] Actually, it is allocated for struct tuner, and dvb_frontend is inside.(CVE-2024-43900)

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

sched/smt: Fix unbalance schedsmtpresent dec/inc

I got the following warn report while doing stress test:

jump label: negative count! WARNING: CPU: 3 PID: 38 at kernel/jumplabel.c:263 statickeyslowtrydec+0x9d/0xb0 Call Trace: <TASK> _statickeyslowdeccpuslocked+0x16/0x70 schedcpudeactivate+0x26e/0x2a0 cpuhpinvokecallback+0x3ad/0x10d0 cpuhpthreadfun+0x3f5/0x680 smpbootthreadfn+0x56d/0x8d0 kthread+0x309/0x400 retfromfork+0x41/0x70 retfromfork_asm+0x1b/0x30 </TASK>

Because when cpusetcpuinactive() fails in schedcpudeactivate(), the cpu offline failed, but schedsmtpresent is decremented before calling schedcpudeactivate(), it leads to unbalanced dec/inc, so fix it by incrementing schedsmtpresent in the error path.(CVE-2024-44958)

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:

Input: MT - limit max slots

syzbot is reporting too large allocation at inputmtinitslots(), for numslots is supplied from userspace using ioctl(UIDEVCREATE).

Since nobody knows possible max slots, this patch chose 1024.(CVE-2024-45008)

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

netem: fix return value if duplicate enqueue fails

There is a bug in netemenqueue() introduced by commit 5845f706388a ("net: netem: fix skb length BUGON in _skbto_sgvec") that can lead to a use-after-free.

This commit made netemenqueue() always return NETXMITSUCCESS when a packet is duplicated, which can cause the parent qdisc's q.qlen to be mistakenly incremented. When this happens qlennotify() may be skipped on the parent during destruction, leaving a dangling pointer for some classful qdiscs like DRR.

There are two ways for the bug happen:

• If the duplicated packet is dropped by rootq->enqueue() and then the original packet is also dropped.
• If rootq->enqueue() sends the duplicated packet to a different qdisc and the original packet is dropped.

In both cases NETXMITSUCCESS is returned even though no packets are enqueued at the netem qdisc.

The fix is to defer the enqueue of the duplicate packet until after the original packet has been guaranteed to return NETXMITSUCCESS.(CVE-2024-45016)

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

scsi: aacraid: Fix double-free on probe failure

aacprobeone() calls hardware-specific init functions through the aacdriverident::init pointer, all of which eventually call down to aacinitadapter().

If aacinitadapter() fails after allocating memory for aac_dev::queues, it frees the memory but does not clear that member.

After the hardware-specific init function returns an error, aacprobeone() goes down an error path that frees the memory pointed to by aac_dev::queues, resulting.in a double-free.(CVE-2024-46673)

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

usb: dwc3: st: fix probed platform device ref count on probe error path

The probe function never performs any paltform device allocation, thus error path "undoplatformdev_alloc" is entirely bogus. It drops the reference count from the platform device being probed. If error path is triggered, this will lead to unbalanced device reference counts and premature release of device resources, thus possible use-after-free when releasing remaining devm-managed resources.(CVE-2024-46674)

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

ethtool: check device is present when getting link settings

A sysfs reader can race with a device reset or removal, attempting to read device state when the device is not actually present. eg:

 [exception RIP: qed_get_current_link+17]

#8 [ffffb9e4f2907c48] qedegetlinkksettings at ffffffffc07a994a [qede] #9 [ffffb9e4f2907cd8] _rhcallgetlinkksettings at ffffffff992b01a3 #10 [ffffb9e4f2907d38] _ethtoolgetlinkksettings at ffffffff992b04e4 #11 [ffffb9e4f2907d90] duplexshow at ffffffff99260300 #12 [ffffb9e4f2907e38] devattrshow at ffffffff9905a01c #13 [ffffb9e4f2907e50] sysfskfseqshow at ffffffff98e0145b #14 [ffffb9e4f2907e68] seqread at ffffffff98d902e3 #15 [ffffb9e4f2907ec8] vfsread at ffffffff98d657d1 #16 [ffffb9e4f2907f00] ksysread at ffffffff98d65c3f #17 [ffffb9e4f2907f38] dosyscall_64 at ffffffff98a052fb

crash> struct net_device.state ffff9a9d21336000 state = 5,

state 5 is _LINKSTATESTART (0b1) and _LINKSTATENOCARRIER (0b100). The device is not present, note lack of _LINKSTATE_PRESENT (0b10).

This is the same sort of panic as observed in commit 4224cfd7fb65 ("net-sysfs: add check for netdevice being present to speed_show").

There are many other callers of _ethtoolgetlinkksettings() which don't have a device presence check.

Move this check into ethtool to protect all callers.(CVE-2024-46679)

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

pktgen: use cpusreadlock() in pgnetinit()

I have seen the WARNON(smpprocessorid() != cpu) firing in pktgenthread_worker() during tests.

We must use cpusreadlock()/cpusreadunlock() around the foreachonline_cpu(cpu) loop.

While we are at it use WARNONONCE() to avoid a possible syslog flood.(CVE-2024-46681)

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

selinux,smack: don't bypass permissions check in inode_setsecctx hook

Marek Gresko reports that the root user on an NFS client is able to change the security labels on files on an NFS filesystem that is exported with root squashing enabled.

The end of the kerneldoc comment for _vfssetxattr_noperm() states:

• This function requires the caller to lock the inode's i_mutex before it
• is executed. It also assumes that the caller will make the appropriate
• permission checks.

nfsdsetattr() does do permissions checking via fhverify() and nfsdpermission(), but those don't do all the same permissions checks that are done by securityinode_setxattr() and its related LSM hooks do.

Since nfsdsetattr() is the only consumer of securityinodesetsecctx(), simplest solution appears to be to replace the call to _vfssetxattrnoperm() with a call to _vfssetxattr_locked(). This fixes the above issue and has the added benefit of causing nfsd to recall conflicting delegations on a file when a client tries to change its security label.(CVE-2024-46695)

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

KVM: arm64: Make ICC*SGI*EL1 undef in the absence of a vGICv3

On a system with a GICv3, if a guest hasn't been configured with GICv3 and that the host is not capable of GICv2 emulation, a write to any of the ICC*SGI*EL1 registers is trapped to EL2.

We therefore try to emulate the SGI access, only to hit a NULL pointer as no private interrupt is allocated (no GIC, remember?).

The obvious fix is to give the guest what it deserves, in the shape of a UNDEF exception.(CVE-2024-46707)

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

apparmor: fix possible NULL pointer dereference

profile->parent->dents[AAFSPROFDIR] could be NULL only if its parent is made from _createmissingancestors(..) and 'ent->old' is NULL in aareplace_profiles(..). In that case, it must return an error code and the code, -ENOENT represents its state that the path of its parent is not existed yet.

BUG: kernel NULL pointer dereference, address: 0000000000000030 PGD 0 P4D 0 PREEMPT SMP PTI CPU: 4 PID: 3362 Comm: apparmorparser Not tainted 6.8.0-24-generic #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:aafscreate.constprop.0+0x7f/0x130 Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0 Call Trace: <TASK> ? showregs+0x6d/0x80 ? _die+0x24/0x80 ? pagefaultoops+0x99/0x1b0 ? kernelmodefixuporoops+0xb2/0x140 ? _badareanosemaphore+0x1a5/0x2c0 ? findvma+0x34/0x60 ? badareanosemaphore+0x16/0x30 ? douseraddrfault+0x2a2/0x6b0 ? excpagefault+0x83/0x1b0 ? asmexcpagefault+0x27/0x30 ? aafscreate.constprop.0+0x7f/0x130 ? aafscreate.constprop.0+0x51/0x130 _aafsprofilemkdir+0x3d6/0x480 aareplaceprofiles+0x83f/0x1270 policyupdate+0xe3/0x180 profileload+0xbc/0x150 ? rwverifyarea+0x47/0x140 vfswrite+0x100/0x480 ? _x64sysopenat+0x55/0xa0 ? syscallexittousermode+0x86/0x260 ksyswrite+0x73/0x100 _x64syswrite+0x19/0x30 x64syscall+0x7e/0x25c0 dosyscall64+0x7f/0x180 entrySYSCALL64afterhwframe+0x78/0x80 RIP: 0033:0x7be9f211c574 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574 RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004 RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80 R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30 </TASK> Modules linked in: sndseqdummy sndhrtimer qrtr sndhdacodecgeneric sndhdaintel sndinteldspcfg sndintelsdwacpi sndhdacodec sndhdacore sndhwdep sndpcm sndseqmidi sndseqmidievent sndrawmidi sndseq sndseqdevice i2ci801 sndtimer i2csmbus qxl snd soundcore drmttmhelper lpcich ttm joydev inputleds serioraw machid binfmtmisc msr parportpc ppdev lp parport efipstore nfnetlink dmisysfs qemufwcfg iptables xtables autofs4 hidgeneric usbhid hid ahci libahci psmouse virtiorng xhcipci xhcipcirenesas CR2: 0000000000000030 ---[ end trace 0000000000000000 ]--- RIP: 0010:aafscreate.constprop.0+0x7f/0x130 Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000 ---truncated---(CVE-2024-46721)

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

drm/amdgpu: Fix out-of-bounds write warning

Check the ring type value to fix the out-of-bounds write warning(CVE-2024-46725)

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

drm/amd/display: Ensure index calculation will not overflow

[WHY & HOW] Make sure vmid0p72idx, vnom0p8idx and vmax0p9_idx calculation will never overflow and exceess array size.

This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-46726)

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

drm/amd/display: Assign linearpitchalignment even for VM

[Description] Assign linearpitchalignment so we don't cause a divide by 0 error in VM environments(CVE-2024-46732)

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

nvmet-tcp: fix kernel crash if commands allocation fails

If the commands allocation fails in nvmettcpalloccmds() the kernel crashes in nvmettcpreleasequeue_work() because of a NULL pointer dereference.

nvmet: failed to install queue 0 cntlid 1 ret 6 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008

Fix the bug by setting queue->nrcmds to zero in case nvmettcpalloccmd() fails.(CVE-2024-46737)

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

VMCI: Fix use-after-free when removing resource in vmciresourceremove()

When removing a resource from vmciresourcetable in vmciresourceremove(), the search is performed using the resource handle by comparing context and resource fields.

It is possible though to create two resources with different types but same handle (same context and resource fields).

When trying to remove one of the resources, vmciresourceremove() may not remove the intended one, but the object will still be freed as in the case of the datagram type in vmcidatagramdestroyhandle(). vmciresource_table will still hold a pointer to this freed resource leading to a use-after-free vulnerability.

BUG: KASAN: use-after-free in vmcihandleisequal include/linux/vmwvmcidefs.h:142 [inline] BUG: KASAN: use-after-free in vmciresourceremove+0x3a1/0x410 drivers/misc/vmwvmci/vmciresource.c:147 Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x82/0xa9 lib/dumpstack.c:106 printaddressdescription.constprop.0+0x21/0x366 mm/kasan/report.c:239 _kasanreport.cold+0x7f/0x132 mm/kasan/report.c:425 kasanreport+0x38/0x51 mm/kasan/report.c:442 vmcihandleisequal include/linux/vmwvmcidefs.h:142 [inline] vmciresourceremove+0x3a1/0x410 drivers/misc/vmwvmci/vmciresource.c:147 vmciqpbrokerdetach+0x89a/0x11b9 drivers/misc/vmwvmci/vmciqueuepair.c:2182 ctxfreectx+0x473/0xbe1 drivers/misc/vmwvmci/vmcicontext.c:444 krefput include/linux/kref.h:65 [inline] vmcictxput drivers/misc/vmwvmci/vmcicontext.c:497 [inline] vmcictxdestroy+0x170/0x1d6 drivers/misc/vmwvmci/vmcicontext.c:195 vmcihostclose+0x125/0x1ac drivers/misc/vmwvmci/vmcihost.c:143 _fput+0x261/0xa34 fs/filetable.c:282 taskworkrun+0xf0/0x194 kernel/taskwork.c:164 tracehooknotifyresume include/linux/tracehook.h:189 [inline] exittousermodeloop+0x184/0x189 kernel/entry/common.c:187 exittousermodeprepare+0x11b/0x123 kernel/entry/common.c:220 _syscallexittousermodework kernel/entry/common.c:302 [inline] syscallexittousermode+0x18/0x42 kernel/entry/common.c:313 dosyscall64+0x41/0x85 arch/x86/entry/common.c:86 entrySYSCALL64after_hwframe+0x6e/0x0

This change ensures the type is also checked when removing the resource from vmciresourcetable in vmciresourceremove().(CVE-2024-46738)

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

uiohvgeneric: Fix kernel NULL pointer dereference in hvuiorescind

For primary VM Bus channels, primary_channel pointer is always NULL. This pointer is valid only for the secondary channels. Also, rescind callback is meant for primary channels only.

Fix NULL pointer dereference by retrieving the device_obj from the parent for the primary channel.(CVE-2024-46739)

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

binder: fix UAF caused by offsets overwrite

Binder objects are processed and copied individually into the target buffer during transactions. Any raw data in-between these objects is copied as well. However, this raw data copy lacks an out-of-bounds check. If the raw data exceeds the data section size then the copy overwrites the offsets section. This eventually triggers an error that attempts to unwind the processed objects. However, at this point the offsets used to index these objects are now corrupted.

Unwinding with corrupted offsets can result in decrements of arbitrary nodes and lead to their premature release. Other users of such nodes are left with a dangling pointer triggering a use-after-free. This issue is made evident by the following KASAN report (trimmed):

================================================================== BUG: KASAN: slab-use-after-free in rawspin_lock+0xe4/0x19c Write of size 4 at addr ffff47fc91598f04 by task binder-util/743

CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1 Hardware name: linux,dummy-virt (DT) Call trace: rawspinlock+0xe4/0x19c binderfreebuf+0x128/0x434 binderthreadwrite+0x8a4/0x3260 binderioctl+0x18f0/0x258c [...]

Allocated by task 743: _kmalloccachenoprof+0x110/0x270 bindernewnode+0x50/0x700 bindertransaction+0x413c/0x6da8 binderthreadwrite+0x978/0x3260 binder_ioctl+0x18f0/0x258c [...]

Freed by task 745: kfree+0xbc/0x208 binderthreadread+0x1c5c/0x37d4 binder_ioctl+0x16d8/0x258c [...] ==================================================================

To avoid this issue, let's check that the raw data copy is within the boundaries of the data section.(CVE-2024-46740)

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

of/irq: Prevent device address out-of-bounds read in interrupt map walk

When ofirqparseraw() is invoked with a device address smaller than the interrupt parent node (from #address-cells property), KASAN detects the following out-of-bounds read when populating the initial match table (dyndbg="func ofirqparse* +p"):

OF: ofirqparseone: dev=/soc@0/picasso/watchdog, index=0 OF: parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2 OF: intspec=4 OF: ofirqparseraw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2 OF: -> addrsize=3 ================================================================== BUG: KASAN: slab-out-of-bounds in ofirqparse_raw+0x2b8/0x8d0 Read of size 4 at addr ffffff81beca5608 by task bash/764

CPU: 1 PID: 764 Comm: bash Tainted: G O 6.1.67-484c613561-nokiasmarm64 #1 Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023 Call trace: dumpbacktrace+0xdc/0x130 showstack+0x1c/0x30 dumpstacklvl+0x6c/0x84 printreport+0x150/0x448 kasanreport+0x98/0x140 _asanload4+0x78/0xa0 ofirqparseraw+0x2b8/0x8d0 ofirqparseone+0x24c/0x270 parseinterrupts+0xc0/0x120 offwnodeaddlinks+0x100/0x2d0 fwdevlinkparsefwtree+0x64/0xc0 deviceadd+0xb38/0xc30 ofdeviceadd+0x64/0x90 ofplatformdevicecreatepdata+0xd0/0x170 ofplatformbuscreate+0x244/0x600 ofplatformnotify+0x1b0/0x254 blockingnotifiercallchain+0x9c/0xd0 _ofchangesetentrynotify+0x1b8/0x230 _ofchangesetapplynotify+0x54/0xe4 ofoverlayfdt_apply+0xc04/0xd94 ...

The buggy address belongs to the object at ffffff81beca5600 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 8 bytes inside of 128-byte region [ffffff81beca5600, ffffff81beca5680)

The buggy address belongs to the physical page: page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4 head:00000000230d3d03 order:1 compoundmapcount:0 compoundpincount:0 flags: 0x8000000000010200(slab|head|zone=2) raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300 raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc ================================================================== OF: -> got it !

Prevent the out-of-bounds read by copying the device address into a buffer of sufficient size.(CVE-2024-46743)

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

PCI: Add missing bridge lock to pcibuslock()

One of the true positives that the cfgaccesslock lockdep effort identified is this sequence:

WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pcibridgesecondarybusreset+0x5d/0x70 RIP: 0010:pcibridgesecondarybusreset+0x5d/0x70 Call Trace: <TASK> ? _warn+0x8c/0x190 ? pcibridgesecondarybusreset+0x5d/0x70 ? reportbug+0x1f8/0x200 ? handlebug+0x3c/0x70 ? excinvalidop+0x18/0x70 ? asmexcinvalidop+0x1a/0x20 ? pcibridgesecondarybusreset+0x5d/0x70 pciresetbus+0x1d8/0x270 vmdprobe+0x778/0xa10 pcidevice_probe+0x95/0x120

Where pciresetbus() users are triggering unlocked secondary bus resets. Ironically pcibusreset(), several calls down from pciresetbus(), uses pcibuslock() before issuing the reset which locks everything but the bridge itself.

For the same motivation as adding:

bridge = pciupstreambridge(dev); if (bridge) pcidevlock(bridge);

to pciresetfunction() for the "bus" and "cxlbus" reset cases, add pcidevlock() for @bus->self to pcibus_lock().

bhelgaas: squash in recursive locking deadlock fix from Keith Busch: https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com

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

btrfs: handle errors from btrfsdecref() properly

In walkupproc() we BUGON(ret) from btrfsdec_ref(). This is incorrect, we have proper error handling here, return the error.(CVE-2024-46753)

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

wifi: mwifiex: Do not return unused priv in mwifiexgetprivbyid()

mwifiexgetprivbyid() returns the priv pointer corresponding to the bssnum and bsstype, but without checking if the priv is actually currently in use. Unused priv pointers do not have a wiphy attached to them which can lead to NULL pointer dereferences further down the callstack. Fix this by returning only used priv pointers which have priv->bssmode set to something else than NL80211IFTYPE_UNSPECIFIED.

Said NULL pointer dereference happened when an Accesspoint was started with wpa_supplicant -i mlan0 with this config:

network={ ssid="somessid" mode=2 frequency=2412 key_mgmt=WPA-PSK WPA-PSK-SHA256 proto=RSN group=CCMP pairwise=CCMP psk="12345678" }

When waiting for the AP to be established, interrupting wpa_supplicant with <ctrl-c> and starting it again this happens:

| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140 | 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=0000000046d96000 | [0000000000000140] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP | Modules linked in: caamjr caamhashdesc spidev caamalgdesc cryptoengine authenc libdes mwifiexsdio +mwifiex crct10difce cdcacm onboardusbhub fslimx8ddrperf imx8mddrc rtcds1307 lm75 rtcsnvs +imxsdma caam imx8mmthermal spiimx error imxcpufreqdt fuse iptables xtables ipv6 | CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18 | Hardware name: somemachine (DT) | Workqueue: events sdioirqwork | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : mwifiexgetcfp+0xd8/0x15c [mwifiex] | lr : mwifiexgetcfp+0x34/0x15c [mwifiex] | sp : ffff8000818b3a70 | x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004 | x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9 | x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000 | x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000 | x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517 | x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1 | x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157 | x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124 | x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000 | x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000 | Call trace: | mwifiexgetcfp+0xd8/0x15c [mwifiex] | mwifiexparsesingleresponsebuf+0x1d0/0x504 [mwifiex] | mwifiexhandleeventextscanreport+0x19c/0x2f8 [mwifiex] | mwifiexprocessstaevent+0x298/0xf0c [mwifiex] | mwifiexprocessevent+0x110/0x238 [mwifiex] | mwifiexmainprocess+0x428/0xa44 [mwifiex] | mwifiexsdiointerrupt+0x64/0x12c [mwifiexsdio] | processsdiopendingirqs+0x64/0x1b8 | sdioirqwork+0x4c/0x7c | processonework+0x148/0x2a0 | workerthread+0x2fc/0x40c | kthread+0x110/0x114 | retfrom_fork+0x10/0x20 | Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000) | ---[ end trace 0000000000000000 ]---(CVE-2024-46755)

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

hwmon: (w83627ehf) 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-46756)

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

hwmon: (lm95234) 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-46758)

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

hwmon: (adc128d818) 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-46759)

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

pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv

The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel crash when we try to hot-unplug/disable the PCIe switch/bridge from the PHB.

The crash occurs because although the MSI data structure has been released during disable/hot-unplug path and it has been assigned with NULL, still during unregistration the code was again trying to explicitly disable the MSI which causes the NULL pointer dereference and kernel crash.

The patch fixes the check during unregistration path to prevent invoking pcidisablemsi/msix() since its data structure is already freed.(CVE-2024-46761)

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

can: bcm: Remove proc entry when dev is unregistered.

syzkaller reported a warning in bcm_connect() below. [0]

The repro calls connect() to vxcan1, removes vxcan1, and calls connect() with ifindex == 0.

Calling connect() for a BCM socket allocates a proc entry. Then, bcm_sk(sk)->bound is set to 1 to prevent further connect().

However, removing the bound device resets bcmsk(sk)->bound to 0 in bcmnotify().

The 2nd connect() tries to allocate a proc entry with the same name and sets NULL to bcmsk(sk)->bcmproc_read, leaking the original proc entry.

Since the proc entry is available only for connect()ed sockets, let's clean up the entry when the bound netdev is unregistered.

WARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 procregister+0x645/0x8f0 fs/proc/generic.c:375 Modules linked in: CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:procregister+0x645/0x8f0 fs/proc/generic.c:375 Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 <0f> 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48 RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246 RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002 RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0 R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec FS: 00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> proccreatenetsingle+0x144/0x210 fs/proc/procnet.c:220 bcmconnect+0x472/0x840 net/can/bcm.c:1673 _sysconnectfile net/socket.c:2049 [inline] _sysconnect+0x5d2/0x690 net/socket.c:2066 _dosysconnect net/socket.c:2076 [inline] _sesysconnect net/socket.c:2073 [inline] _x64sysconnect+0x8f/0x100 net/socket.c:2073 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd9/0x1c0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7fbd708b0e5d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIGRAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d RDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040 R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098 R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000 </TASK> removeprocentry: removing non-empty directory 'net/can-bcm', leaking at least '2456'(CVE-2024-46771)

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

udf: Avoid excessive partition lengths

Avoid mounting filesystems where the partition would overflow the 32-bits used for block number. Also refuse to mount filesystems where the partition length is so large we cannot safely index bits in a block bitmap.(CVE-2024-46777)

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

nilfs2: protect references to superblock parameters exposed in sysfs

The superblock buffers of nilfs2 can not only be overwritten at runtime for modifications/repairs, but they are also regularly swapped, replaced during resizing, and even abandoned when degrading to one side due to backing device issues. So, accessing them requires mutual exclusion using the reader/writer semaphore "nilfs->ns_sem".

Some sysfs attribute show methods read this superblock buffer without the necessary mutual exclusion, which can cause problems with pointer dereferencing and memory access, so fix it.(CVE-2024-46780)

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

nilfs2: fix missing cleanup on rollforward recovery error

In an error injection test of a routine for mount-time recovery, KASAN found a use-after-free bug.

It turned out that if data recovery was performed using partial logs created by dsync writes, but an error occurred before starting the log writer to create a recovered checkpoint, the inodes whose data had been recovered were left in the nsdirtyfiles list of the nilfs object and were not freed.

Fix this issue by cleaning up inodes that have read the recovery data if the recovery routine fails midway before the log writer starts.(CVE-2024-46781)

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

can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open

The mcp251xhwwake() function is called with the mpc_lock mutex held and disables the interrupt handler so that no interrupts can be processed while waking the device. If an interrupt has already occurred then waiting for the interrupt handler to complete will deadlock because it will be trying to acquire the same mutex.

CPU0 CPU1 ---- ---- mcp251xopen() mutexlock(&priv->mcplock) requestthreadedirq() <interrupt> mcp251xcanist() mutexlock(&priv->mcplock) mcp251xhwwake() disableirq() <-- deadlock

Use disableirqnosync() instead because the interrupt handler does everything while holding the mutex so it doesn't matter if it's still running.(CVE-2024-46791)

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

ASoC: dapm: Fix UAF for sndsocpcm_runtime object

When using kernel with the following extra config,

• CONFIG_KASAN=y
• CONFIGKASANGENERIC=y
• CONFIGKASANINLINE=y
• CONFIGKASANVMALLOC=y
• CONFIGFRAMEWARN=4096

kernel detects that sndpcmsuspendall() access a freed 'sndsocpcmruntime' object when the system is suspended, which leads to a use-after-free bug:

[ 52.047746] BUG: KASAN: use-after-free in sndpcmsuspend_all+0x1a8/0x270 [ 52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330

[ 52.047785] Call trace: [ 52.047787] dumpbacktrace+0x0/0x3c0 [ 52.047794] showstack+0x34/0x50 [ 52.047797] dumpstacklvl+0x68/0x8c [ 52.047802] printaddressdescription.constprop.0+0x74/0x2c0 [ 52.047809] kasanreport+0x210/0x230 [ 52.047815] _asanreportload1noabort+0x3c/0x50 [ 52.047820] sndpcmsuspendall+0x1a8/0x270 [ 52.047824] sndsocsuspend+0x19c/0x4e0

The sndpcmsync_stop() has a NULL check on 'substream->runtime' before making any access. So we need to always set 'substream->runtime' to NULL everytime we kfree() it.(CVE-2024-46798)

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

drm/amd/display: Add array index check for hdcp ddc access

[Why] Coverity reports OVERRUN warning. Do not check if array index valid.

[How] Check msg_id valid and valid array index.(CVE-2024-46804)

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

drm/amd/display: Check msg_id before processing transcation

[WHY & HOW] HDCPMESSAGEIDINVALID (-1) is not a valid msgid nor is it a valid array index, and it needs checking before used.

This fixes 4 OVERRUN issues reported by Coverity.(CVE-2024-46814)

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

drm/amd/display: Stop amdgpudm initialize when link nums greater than maxlinks

[Why] Coverity report OVERRUN warning. There are only maxlinks elements within dc->links. link count could up to AMDGPUDMMAXDISPLAY_INDEX 31.

[How] Make sure link count less than max_links.(CVE-2024-46816)

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

drm/amd/display: Check gpio_id before used as array index

[WHY & HOW] GPIOIDUNKNOWN (-1) is not a valid value for array index and therefore should be checked in advance.

This fixes 5 OVERRUN issues reported by Coverity.(CVE-2024-46818)

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

drm/amd/pm: Fix negative array index read

Avoid using the negative values for clk_idex as an index into an array pptable->DpmDescriptor.

V2: fix clk_index return check (Tim Huang)(CVE-2024-46821)

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

rtmutex: Drop rtmutex::waitlock before scheduling

rtmutexhandledeadlock() is called with rtmutex::wait_lock held. In the good case it returns with the lock held and in the deadlock case it emits a warning and goes into an endless scheduling loop with the lock held, which triggers the 'scheduling in atomic' warning.

Unlock rtmutex::waitlock in the dead lock case before issuing the warning and dropping into the schedule for ever loop.

tglx: Moved unlock before the WARN(), removed the pointless comment, massaged changelog, added Fixes tag

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

net: hns3: void array out of bound when loop tnl_num

When query reg inf of SSU, it loops tnlnum times. However, tnlnum comes from hardware and the length of array is a fixed value. To void array out of bound, make sure the loop time is not greater than the length of array(CVE-2024-46833)

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

btrfs: don't BUGON on ENOMEM from btrfslookupextentinfo() in walkdownproc()

We handle errors here properly, ENOMEM isn't fatal, return the error.(CVE-2024-46841)

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

um: line: always fill *errorout in setupone_line()

The pointer isn't initialized by callers, but I have encountered cases where it's still printed; initialize it in all possible cases in setuponeline().(CVE-2024-46844)

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

ASoC: meson: axg-card: fix 'use-after-free'

Buffer 'card->dailink' is reallocated in 'mesoncardreallocatelinks()', so move 'pad' pointer initialization after this function when memory is already reallocated.

Kasan bug report:

================================================================== BUG: KASAN: slab-use-after-free in axgcardadd_link+0x76c/0x9bc Read of size 8 at addr ffff000000e8b260 by task modprobe/356

CPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1 Call trace: dumpbacktrace+0x94/0xec showstack+0x18/0x24 dumpstacklvl+0x78/0x90 printreport+0xfc/0x5c0 kasanreport+0xb8/0xfc _asanload8+0x9c/0xb8 axgcardaddlink+0x76c/0x9bc [sndsocmesonaxgsoundcard] mesoncardprobe+0x344/0x3b8 [sndsocmesoncardutils] platformprobe+0x8c/0xf4 reallyprobe+0x110/0x39c _driverprobedevice+0xb8/0x18c driverprobedevice+0x108/0x1d8 _driverattach+0xd0/0x25c busforeachdev+0xe0/0x154 driverattach+0x34/0x44 busadddriver+0x134/0x294 driverregister+0xa8/0x1e8 _platformdriverregister+0x44/0x54 axgcardpdrvinit+0x20/0x1000 [sndsocmesonaxgsoundcard] dooneinitcall+0xdc/0x25c doinitmodule+0x10c/0x334 loadmodule+0x24c4/0x26cc initmodulefromfile+0xd4/0x128 _arm64sysfinitmodule+0x1f4/0x41c invokesyscall+0x60/0x188 el0svccommon.constprop.0+0x78/0x13c doel0svc+0x30/0x40 el0svc+0x38/0x78 el0t64synchandler+0x100/0x12c el0t64sync+0x190/0x194(CVE-2024-46849)

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

net/mlx5: Fix bridge mode operations when there are no VFs

Currently, trying to set the bridge mode attribute when numvfs=0 leads to a crash:

bridge link set dev eth2 hwmode vepa

[ 168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] [ 168.969989] RIP: 0010:mlx5addflowrules+0x1f/0x300 [mlx5core] [...] [ 168.976037] Call Trace: [ 168.976188] <TASK> [ 168.978620] mlx5eswitchsetvepalocked+0x113/0x230 [mlx5core] [ 168.979074] mlx5eswitchsetvepa+0x7f/0xa0 [mlx5core] [ 168.979471] rtnlbridgesetlink+0xe9/0x1f0 [ 168.979714] rtnetlinkrcvmsg+0x159/0x400 [ 168.980451] netlinkrcvskb+0x54/0x100 [ 168.980675] netlinkunicast+0x241/0x360 [ 168.980918] netlinksendmsg+0x1f6/0x430 [ 168.981162] _syssendmsg+0x3bb/0x3f0 [ 168.982155] syssendmsg+0x88/0xd0 [ 168.985036] _syssendmsg+0x59/0xa0 [ 168.985477] dosyscall64+0x79/0x150 [ 168.987273] entrySYSCALL64afterhwframe+0x76/0x7e [ 168.987773] RIP: 0033:0x7f8f7950f917

(esw->fdbtable.legacy.vepafdb is null)

The bridge mode is only relevant when there are multiple functions per port. Therefore, prevent setting and getting this setting when there are no VFs.

Note that after this change, there are no settings to change on the PF interface using bridge link when there are no VFs, so the interface no longer appears in the bridge link output.(CVE-2024-46857)