OESA-2024-2219

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

bpf: Take return from setmemoryrox() into account with bpfjitbinarylockro()

setmemoryrox() can fail, leaving memory unprotected.

Check return and bail out when bpfjitbinarylockro() returns an error.(CVE-2024-42067)

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

sysctl: always initialize iuid/igid

Always initialize iuid/igid inside the sysfs core so set_ownership() can safely skip setting them.

Commit 5ec27ec735ba ("fs/proc/procsysctl.c: fix the default values of iuid/igid on /proc/sys inodes.") added defaults for iuid/igid when setownership() was not implemented. It also missed adjusting netctlset_ownership() to use the same default values in case the computation of a better value failed.(CVE-2024-42312)

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

parisc: fix a possible DMA corruption

ARCHDMAMINALIGN was defined as 16 - this is too small - it may be possible that two unrelated 16-byte allocations share a cache line. If one of these allocations is written using DMA and the other is written using cached write, the value that was written with DMA may be corrupted.

This commit changes ARCHDMAMINALIGN to be 128 on PA20 and 32 on PA1.1 - that's the largest possible cache line size.

As different parisc microarchitectures have different cache line size, we define archslabminalign(), cachelinesize() and dmagetcache_alignment() so that the kernel may tune slab cache parameters dynamically, based on the detected cache line size.(CVE-2024-44949)

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:

mptcp: pm: only decrement addaddraccepted for MPJ req

Adding the following warning ...

WARNONONCE(msk->pm.addaddraccepted == 0)

... before decrementing the addaddraccepted counter helped to find a bug when running the "remove single subflow" subtest from the mptcp_join.sh selftest.

Removing a 'subflow' endpoint will first trigger a RMADDR, then the subflow closure. Before this patch, and upon the reception of the RMADDR, the other peer will then try to decrement this addaddraccepted. That's not correct because the attached subflows have not been created upon the reception of an ADD_ADDR.

A way to solve that is to decrement the counter only if the attached subflow was an MPJOIN to a remote id that was not 0, and initiated by the host receiving the RMADDR.(CVE-2024-45009)

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

char: xillybus: Check USB endpoints when probing device

Ensure, as the driver probes the device, that all endpoints that the driver may attempt to access exist and are of the correct type.

All XillyUSB devices must have a Bulk IN and Bulk OUT endpoint at address 1. This is verified in xillyusbsetupbase_eps().

On top of that, a XillyUSB device may have additional Bulk OUT endpoints. The information about these endpoints' addresses is deduced from a data structure (the IDT) that the driver fetches from the device while probing it. These endpoints are checked in setup_channels().

A XillyUSB device never has more than one IN endpoint, as all data towards the host is multiplexed in this single Bulk IN endpoint. This is why setup_channels() only checks OUT endpoints.(CVE-2024-45011)

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:

mmc: mmc_test: Fix NULL dereference on allocation failure

If the "test->highmem = allocpages()" allocation fails then calling _free_pages(test->highmem) will result in a NULL dereference. Also change the error code to -ENOMEM instead of returning success.(CVE-2024-45028)

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

i2c: tegra: Do not mark ACPI devices as irq safe

On ACPI machines, the tegra i2c module encounters an issue due to a mutex being called inside a spinlock. This leads to the following bug:

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585
...

Call trace:
__might_sleep
__mutex_lock_common
mutex_lock_nested
acpi_subsys_runtime_resume
rpm_resume
tegra_i2c_xfer

The problem arises because during _pmruntimeresume(), the spinlock &dev->power.lock is acquired before rpmresume() is called. Later, rpmresume() invokes acpisubsysruntimeresume(), which relies on mutexes, triggering the error.

To address this issue, devices on ACPI are now marked as not IRQ-safe, considering the dependency of acpisubsysruntime_resume() on mutexes.(CVE-2024-45029)

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:

smb/client: avoid dereferencing rdata=NULL in smb2newread_req()

This happens when called from SMB2read() while using rdma and reaching the rdmareadwrite_threshold.(CVE-2024-46686)

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:

libfs: fix infinite directory reads for offset dir

After we switch tmpfs dir operations from simplediroperations to simpleoffsetdiroperations, every rename happened will fill new dentry to dest dir's maple tree(&SHMEMI(inode)->diroffsets->mt) with a free key starting with octx->newxoffset, and then set newx_offset equals to free key + 1. This will lead to infinite readdir combine with rename happened at the same time, which fail generic/736 in xfstests(detail show as below).

1. create 5000 files(1 2 3...) under one dir
2. call readdir(man 3 readdir) once, and get one entry
3. rename(entry, "TEMPFILE"), then rename("TEMPFILE", entry)
4. loop 2~3, until readdir return nothing or we loop too many times(tmpfs break test with the second condition)

We choose the same logic what commit 9b378f6ad48cf ("btrfs: fix infinite directory reads") to fix it, record the lastindex when we open dir, and do not emit the entry which index >= lastindex. The file->privatedata now used in offset dir can use directly to do this, and we also update the lastindex when we llseek the dir file.

brauner: only update last_index after seek when offset is zero like Jan suggested

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

net/mlx5e: SHAMPO, Fix incorrect page release

Under the following conditions: 1) No skb created yet 2) headersize == 0 (no SHAMPO header) 3) headerindex + 1 % MLX5ESHAMPOWQHEADERPER_PAGE == 0 (this is the last page fragment of a SHAMPO header page)

a new skb is formed with a page that is NOT a SHAMPO header page (it is a regular data page). Further down in the same function (mlx5ehandlerxcqempwrqshampo()), a SHAMPO header page from headerindex is released. This is wrong and it leads to SHAMPO header pages being released more than once.(CVE-2024-46717)

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 mc_data out-of-bounds read warning

Clear warning that read mc_data[i-1] may out-of-bounds.(CVE-2024-46722)

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: Check index for auxrdinterval before using

auxrdinterval has size of 7 and should be checked.

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

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:

btrfs: fix race between direct IO write and fsync when using same fd

If we have 2 threads that are using the same file descriptor and one of them is doing direct IO writes while the other is doing fsync, we have a race where we can end up either:

1) Attempt a fsync without holding the inode's lock, triggering an assertion failures when assertions are enabled;

2) Do an invalid memory access from the fsync task because the file private points to memory allocated on stack by the direct IO task and it may be used by the fsync task after the stack was destroyed.

The race happens like this:

1) A user space program opens a file descriptor with O_DIRECT;

2) The program spawns 2 threads using libpthread for example;

3) One of the threads uses the file descriptor to do direct IO writes, while the other calls fsync using the same file descriptor.

4) Call task A the thread doing direct IO writes and task B the thread doing fsyncs;

5) Task A does a direct IO write, and at btrfsdirectwrite() sets the file's private to an on stack allocated private with the member 'fsyncskipinode_lock' set to true;

6) Task B enters btrfssyncfile() and sees that there's a private structure associated to the file which has 'fsyncskipinode_lock' set to true, so it skips locking the inode's VFS lock;

7) Task A completes the direct IO write, and resets the file's private to NULL since it had no prior private and our private was stack allocated. Then it unlocks the inode's VFS lock;

8) Task B enters btrfsgetorderedextentsfor_logging(), then the assertion that checks the inode's VFS lock is held fails, since task B never locked it and task A has already unlocked it.

The stack trace produced is the following:

assertion failed: inodeislocked(&inode->vfsinode), in fs/btrfs/ordered-data.c:983 ------------[ cut here ]------------ kernel BUG at fs/btrfs/ordered-data.c:983! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 9 PID: 5072 Comm: worker Tainted: G U OE 6.10.5-1-default #1 openSUSE Tumbleweed 69f48d427608e1c09e60ea24c6c55e2ca1b049e8 Hardware name: Acer Predator PH315-52/CoviniCFS, BIOS V1.12 07/28/2020 RIP: 0010:btrfsgetorderedextentsforlogging.cold+0x1f/0x42 [btrfs] Code: 50 d6 86 c0 e8 (...) RSP: 0018:ffff9e4a03dcfc78 EFLAGS: 00010246 RAX: 0000000000000054 RBX: ffff9078a9868e98 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff907dce4a7800 RDI: ffff907dce4a7800 RBP: ffff907805518800 R08: 0000000000000000 R09: ffff9e4a03dcfb38 R10: ffff9e4a03dcfb30 R11: 0000000000000003 R12: ffff907684ae7800 R13: 0000000000000001 R14: ffff90774646b600 R15: 0000000000000000 FS: 00007f04b96006c0(0000) GS:ffff907dce480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f32acbfc000 CR3: 00000001fd4fa005 CR4: 00000000003726f0 Call Trace: <TASK> ? _diebody.cold+0x14/0x24 ? die+0x2e/0x50 ? dotrap+0xca/0x110 ? doerrortrap+0x6a/0x90 ? btrfsgetorderedextentsforlogging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] ? excinvalidop+0x50/0x70 ? btrfsgetorderedextentsforlogging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] ? asmexcinvalidop+0x1a/0x20 ? btrfsgetorderedextentsforlogging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] ? btrfsgetorderedextentsforlogging.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] btrfssyncfile+0x21a/0x4d0 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] ? _seccompfilter+0x31d/0x4f0 _x64sysfdatasync+0x4f/0x90 dosyscall64+0x82/0x160 ? dofutex+0xcb/0x190 ? _x64sysfutex+0x10e/0x1d0 ? switchfpureturn+0x4f/0xd0 ? syscallexittousermode+0x72/0x220 ? dosyscall64+0x8e/0x160 ? syscallexittousermod ---truncated---(CVE-2024-46734)

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

smb: client: fix double put of @cfile in smb2renamepath()

If smb2setpathattr() is called with a valid @cfile and returned -EINVAL, we need to call cifsgetwritablepath() again as the reference of @cfile was already dropped by previous smb2compoundop() call.(CVE-2024-46736)

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:

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:

wifi: rtw88: usb: schedule rx work after everything is set up

Right now it's possible to hit NULL pointer dereference in rtwrxfillrxstatus on hw object and/or its fields because initialization routine can start getting USB replies before rtw_dev is fully setup.

The stack trace looks like this:

rtwrxfillrxstatus rtw8821cqueryrxdesc rtwusbrxhandler ... queuework rtwusbreadportcomplete ... usbsubmiturb rtwusbrxresubmit rtwusbinitrx rtwusb_probe

So while we do the async stuff rtwusbprobe continues and calls rtwregisterhw, which does all kinds of initialization (e.g. via ieee80211registerhw) that rtwrxfillrxstatus relies on.

Fix this by moving the first usbsubmiturb after everything is set up.

For me, this bug manifested as: [ 8.893177] rtw8821cu 1-1:1.2: band wrong, packet dropped [ 8.910904] rtw8821cu 1-1:1.2: hw->conf.chandef.chan NULL in rtwrxfillrxstatus because I'm using Larry's backport of rtw88 driver with the NULL checks in rtwrxfillrxstatus.(CVE-2024-46760)

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:

net: phy: Fix missing ofnodeput() for leds

The call of ofgetchildbyname() will cause refcount incremented for leds, if it succeeds, it should call ofnodeput() to decrease it, fix it.(CVE-2024-46767)

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

hwmon: (hp-wmi-sensors) Check if WMI event data exists

The BIOS can choose to return no event data in response to a WMI event, so the ACPI object passed to the WMI notify handler can be NULL.

Check for such a situation and ignore the event in such a case.(CVE-2024-46768)

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:

drm/amd/display: Check denominator crb_pipes before used

[WHAT & HOW] A denominator cannot be 0, and is checked before used.

This fixes 2 DIVIDEBYZERO issues reported by Coverity.(CVE-2024-46772)

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

drm/amd/display: Check denominator pbn_div before used

[WHAT & HOW] A denominator cannot be 0, and is checked before used.

This fixes 1 DIVIDEBYZERO issue reported by Coverity.(CVE-2024-46773)

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

drm/amd/display: Run DCLOGDC after checking link->link_enc

[WHAT] The DCLOGDC should be run after link->link_enc is checked, not before.

This fixes 1 REVERSE_INULL issue reported by Coverity.(CVE-2024-46776)

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:

net: mana: Fix error handling in manacreatetxq/rxq's NAPI cleanup

Currently napi_disable() gets called during rxq and txq cleanup, even before napi is enabled and hrtimer is initialized. It causes kernel panic.

? pagefaultoops+0x136/0x2b0 ? pagecountercancel+0x2e/0x80 ? douseraddrfault+0x2f2/0x640 ? refillobjstock+0xc4/0x110 ? excpagefault+0x71/0x160 ? asmexcpagefault+0x27/0x30 ? _mmdrop+0x10/0x180 ? _mmdrop+0xec/0x180 ? hrtimeractive+0xd/0x50 hrtimertrytocancel+0x2c/0xf0 hrtimercancel+0x15/0x30 napidisable+0x65/0x90 manadestroyrxq+0x4c/0x2f0 manacreaterxq.isra.0+0x56c/0x6d0 ? manauncfgvport+0x50/0x50 manaallocqueues+0x21b/0x320 ? skb_dequeue+0x5f/0x80(CVE-2024-46784)

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

userfaultfd: fix checks for huge PMDs

Patch series "userfaultfd: fix races around pmdtranshuge() check", v2.

The pmdtranshuge() code in mfill_atomic() is wrong in three different ways depending on kernel version:

1. The pmdtranshuge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case).
2. As pointed out by Qi Zheng, pmdtranshuge() is not sufficient for detecting PMDs that don't point to page tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've tested this on 6.1 stable by racing migration (with a mdelay() patched into trytomigrate()) against UFFDIOZEROPAGE - on my x86 VM, that causes a kernel oops in ptlockptr().
3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested that), so I think the BUGON() checks in mfillatomic() are just wrong.

I decided to write two separate fixes for these (one fix for bugs 1+2, one fix for bug 3), so that the first fix can be backported to kernels affected by bugs 1+2.

This patch (of 2):

This fixes two issues.

I discovered that the following race can occur:

mfillatomic other thread ============ ============ <zap PMD> pmdpgetlockless() [reads none pmd] <bail if transhuge> <if none:> <pagefault creates transhuge zeropage> _ptealloc [no-op] <zap PMD> <bail if pmdtranshuge(dst_pmd)> BUG_ON(pmd_none(dst_pmd))

I have experimentally verified this in a kernel with extra mdelay() calls; the BUGON(pmdnone(*dst_pmd)) triggers.

On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow pteoffsetmaplock to fail"), this can't lead to anything worse than a BUGON(), since the page table access helpers are actually designed to deal with page tables concurrently disappearing; but on older kernels (<=6.4), I think we could probably theoretically race past the two BUG_ON() checks and end up treating a hugepage as a page table.

The second issue is that, as Qi Zheng pointed out, there are other types of huge PMDs that pmdtranshuge() can't catch: devmap PMDs and swap PMDs (in particular, migration PMDs).

On <=6.4, this is worse than the first issue: If mfillatomic() runs on a PMD that contains a migration entry (which just requires winning a single, fairly wide race), it will pass the PMD to pteoffsetmaplock(), which assumes that the PMD points to a page table.

Breakage follows: First, the kernel tries to take the PTE lock (which will crash or maybe worse if there is no "struct page" for the address bits in the migration entry PMD - I think at least on X86 there usually is no corresponding "struct page" thanks to the PTE inversion mitigation, amd64 looks different).

If that didn't crash, the kernel would next try to write a PTE into what it wrongly thinks is a page table.

As part of fixing these issues, get rid of the check for pmdtranshuge() before _ptealloc() - that's redundant, we're going to have to check for that after the _ptealloc() anyway.

Backport note: pmdpgetlockless() is pmdreadatomic() in older kernels.(CVE-2024-46787)

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

tracing/osnoise: Use a cpumask to know what threads are kthreads

The startkthread() and stopthread() code was not always called with the interfacelock held. This means that the kthread variable could be unexpectedly changed causing the kthreadstop() to be called on it when it should not have been, leading to:

while true; do rtla timerlat top -u -q & PID=$!; sleep 5; kill -INT $PID; sleep 0.001; kill -TERM $PID; wait $PID; done

Causing the following OOPS:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 5 UID: 0 PID: 885 Comm: timerlatu/5 Not tainted 6.11.0-rc4-test-00002-gbc754cc76d1b-dirty #125 a533010b71dab205ad2f507188ce8c82203b0254 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:hrtimeractive+0x58/0x300 Code: 48 c1 ee 03 41 54 48 01 d1 48 01 d6 55 53 48 83 ec 20 80 39 00 0f 85 30 02 00 00 49 8b 6f 30 4c 8d 75 10 4c 89 f0 48 c1 e8 03 <0f> b6 3c 10 4c 89 f0 83 e0 07 83 c0 03 40 38 f8 7c 09 40 84 ff 0f RSP: 0018:ffff88811d97f940 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff88823c6b5b28 RCX: ffffed10478d6b6b RDX: dffffc0000000000 RSI: ffffed10478d6b6c RDI: ffff88823c6b5b28 RBP: 0000000000000000 R08: ffff88823c6b5b58 R09: ffff88823c6b5b60 R10: ffff88811d97f957 R11: 0000000000000010 R12: 00000000000a801d R13: ffff88810d8b35d8 R14: 0000000000000010 R15: ffff88823c6b5b28 FS: 0000000000000000(0000) GS:ffff88823c680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000561858ad7258 CR3: 000000007729e001 CR4: 0000000000170ef0 Call Trace: <TASK> ? dieaddr+0x40/0xa0 ? excgeneralprotection+0x154/0x230 ? asmexcgeneralprotection+0x26/0x30 ? hrtimeractive+0x58/0x300 ? pfxmutexlock+0x10/0x10 ? _pfxlocksremovefile+0x10/0x10 hrtimercancel+0x15/0x40 timerlatfdrelease+0x8e/0x1f0 ? securityfilerelease+0x43/0x80 _fput+0x372/0xb10 taskworkrun+0x11e/0x1f0 ? rawspinlock+0x85/0xe0 ? _pfxtaskworkrun+0x10/0x10 ? poisonslabobject+0x109/0x170 ? doexit+0x7a0/0x24b0 doexit+0x7bd/0x24b0 ? _pfxmigrateenable+0x10/0x10 ? _pfxdoexit+0x10/0x10 ? _pfxreadtsc+0x10/0x10 ? ktimeget+0x64/0x140 ? _rawspinlockirq+0x86/0xe0 dogroupexit+0xb0/0x220 getsignal+0x17ba/0x1b50 ? vfsread+0x179/0xa40 ? timerlatfdread+0x30b/0x9d0 ? _pfxgetsignal+0x10/0x10 ? _pfxtimerlatfdread+0x10/0x10 archdosignalorrestart+0x8c/0x570 ? _pfxarchdosignalorrestart+0x10/0x10 ? vfsread+0x179/0xa40 ? ksysread+0xfe/0x1d0 ? _pfxksysread+0x10/0x10 syscallexittousermode+0xbc/0x130 dosyscall64+0x74/0x110 ? _pfxrseqhandlenotifyresume+0x10/0x10 ? _pfxksysread+0x10/0x10 ? fpregsrestoreuserregs+0xdb/0x1e0 ? fpregsrestoreuserregs+0xdb/0x1e0 ? syscallexittousermode+0x116/0x130 ? dosyscall64+0x74/0x110 ? dosyscall64+0x74/0x110 ? dosyscall64+0x74/0x110 entrySYSCALL64afterhwframe+0x71/0x79 RIP: 0033:0x7ff0070eca9c Code: Unable to access opcode bytes at 0x7ff0070eca72. RSP: 002b:00007ff006dff8c0 EFLAGS: 00000246 ORIGRAX: 0000000000000000 RAX: 0000000000000000 RBX: 0000000000000005 RCX: 00007ff0070eca9c RDX: 0000000000000400 RSI: 00007ff006dff9a0 RDI: 0000000000000003 RBP: 00007ff006dffde0 R08: 0000000000000000 R09: 00007ff000000ba0 R10: 00007ff007004b08 R11: 0000000000000246 R12: 0000000000000003 R13: 00007ff006dff9a0 R14: 0000000000000007 R15: 0000000000000008 </TASK> Modules linked in: sndhdaintel sndinteldspcfg sndintelsdwacpi sndhdacodec sndhwdep sndhda_core ---[ end trace 0000000000000000 ]---

This is because it would mistakenly call kthread_stop() on a user space thread making it "exit" before it actually exits.

Since kthread ---truncated---(CVE-2024-46788)

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:

smb: client: fix double put of @cfile in smb2setpath_size()

If smb2compoundop() is called with a valid @cfile and returned -EINVAL, we need to call cifsgetwritable_path() before retrying it as the reference of @cfile was already dropped by previous call.

This fixes the following KASAN splat when running fstests generic/013 against Windows Server 2022:

CIFS: Attempting to mount //w22-fs0/scratch run fstests generic/013 at 2024-09-02 19:48:59 ================================================================== BUG: KASAN: slab-use-after-free in detachifpending+0xab/0x200 Write of size 8 at addr ffff88811f1a3730 by task kworker/3:2/176

CPU: 3 UID: 0 PID: 176 Comm: kworker/3:2 Not tainted 6.11.0-rc6 #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: cifsoplockd cifsoplockbreak [cifs] Call Trace: <TASK> dumpstacklvl+0x5d/0x80 ? detachifpending+0xab/0x200 printreport+0x156/0x4d9 ? detachifpending+0xab/0x200 ? virtaddrvalid+0x145/0x300 ? _physaddr+0x46/0x90 ? detachifpending+0xab/0x200 kasanreport+0xda/0x110 ? detachifpending+0xab/0x200 detachifpending+0xab/0x200 timerdelete+0x96/0xe0 ? _pfxtimerdelete+0x10/0x10 ? rcuiswatching+0x20/0x50 trytograbpending+0x46/0x3b0 _cancelwork+0x89/0x1b0 ? _pfxcancelwork+0x10/0x10 ? kasansavetrack+0x14/0x30 cifsclosedeferredfile+0x110/0x2c0 [cifs] ? _pfxcifsclosedeferredfile+0x10/0x10 [cifs] ? _pfxdownread+0x10/0x10 cifsoplockbreak+0x4c1/0xa50 [cifs] ? _pfxcifsoplockbreak+0x10/0x10 [cifs] ? lockisheldtype+0x85/0xf0 ? markheldlocks+0x1a/0x90 processonework+0x4c6/0x9f0 ? findheldlock+0x8a/0xa0 ? _pfxprocessonework+0x10/0x10 ? lockacquired+0x220/0x550 ? _listaddvalidorreport+0x37/0x100 workerthread+0x2e4/0x570 ? _kthreadparkme+0xd1/0xf0 ? _pfxworkerthread+0x10/0x10 kthread+0x17f/0x1c0 ? kthread+0xda/0x1c0 ? _pfxkthread+0x10/0x10 retfromfork+0x31/0x60 ? _pfxkthread+0x10/0x10 retfromfork_asm+0x1a/0x30 </TASK>

Allocated by task 1118: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 _kasankmalloc+0xaa/0xb0 cifsnewfileinfo+0xc8/0x9d0 [cifs] cifsatomicopen+0x467/0x770 [cifs] lookupopen.isra.0+0x665/0x8b0 pathopenat+0x4c3/0x1380 dofilpopen+0x167/0x270 dosysopenat2+0x129/0x160 _x64syscreat+0xad/0xe0 dosyscall64+0xbb/0x1d0 entrySYSCALL64after_hwframe+0x77/0x7f

Freed by task 83: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x70 poisonslabobject+0xe9/0x160 _kasanslabfree+0x32/0x50 kfree+0xf2/0x300 processonework+0x4c6/0x9f0 workerthread+0x2e4/0x570 kthread+0x17f/0x1c0 retfromfork+0x31/0x60 retfromforkasm+0x1a/0x30

Last potentially related work creation: kasansavestack+0x30/0x50 _kasanrecordauxstack+0xad/0xc0 insertwork+0x29/0xe0 _queuework+0x5ea/0x760 queueworkon+0x6d/0x90 _cifsFileInfoput+0x3f6/0x770 [cifs] smb2compoundop+0x911/0x3940 [cifs] smb2setpathsize+0x228/0x270 [cifs] cifssetfilesize+0x197/0x460 [cifs] cifssetattr+0xd9c/0x14b0 [cifs] notifychange+0x4e3/0x740 dotruncate+0xfa/0x180 vfstruncate+0x195/0x200 _x64systruncate+0x109/0x150 dosyscall64+0xbb/0x1d0 entrySYSCALL64after_hwframe+0x77/0x7f(CVE-2024-46796)

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

powerpc/qspinlock: Fix deadlock in MCS queue

If an interrupt occurs in queuedspinlockslowpath() after we increment qnodesp->count and before node->lock is initialized, another CPU might see stale lock values in gettail_qnode(). If the stale lock value happens to match the lock on that CPU, then we write to the "next" pointer of the wrong qnode. This causes a deadlock as the former CPU, once it becomes the head of the MCS queue, will spin indefinitely until it's "next" pointer is set by its successor in the queue.

Running stress-ng on a 16 core (16EC/16VP) shared LPAR, results in occasional lockups similar to the following:

$ stress-ng --all 128 --vm-bytes 80% --aggressive \ --maximize --oomable --verify --syslog \ --metrics --times --timeout 5m

watchdog: CPU 15 Hard LOCKUP ...... NIP [c0000000000b78f4] queuedspinlockslowpath+0x1184/0x1490 LR [c000000001037c5c] _rawspinlock+0x6c/0x90 Call Trace: 0xc000002cfffa3bf0 (unreliable) _rawspinlock+0x6c/0x90 rawspinrqlocknested.part.135+0x4c/0xd0 schedttwupending+0x60/0x1f0 _flushsmpcallfunctionqueue+0x1dc/0x670 smpipidemuxrelaxed+0xa4/0x100 xivemuxedipiaction+0x20/0x40 _handleirqeventpercpu+0x80/0x240 handleirqeventpercpu+0x2c/0x80 handlepercpuirq+0x84/0xd0 generichandleirq+0x54/0x80 _doirq+0xac/0x210 _doIRQ+0x74/0xd0 0x0 doIRQ+0x8c/0x170 hardwareinterruptcommonvirt+0x29c/0x2a0 --- interrupt: 500 at queuedspinlockslowpath+0x4b8/0x1490 ...... NIP [c0000000000b6c28] queuedspinlockslowpath+0x4b8/0x1490 LR [c000000001037c5c] _rawspinlock+0x6c/0x90 --- interrupt: 500 0xc0000029c1a41d00 (unreliable) _rawspinlock+0x6c/0x90 futexwake+0x100/0x260 dofutex+0x21c/0x2a0 sysfutex+0x98/0x270 systemcallexception+0x14c/0x2f0 systemcallvectored_common+0x15c/0x2ec

The following code flow illustrates how the deadlock occurs. For the sake of brevity, assume that both locks (A and B) are contended and we call the queuedspinlock_slowpath() function.

    CPU0                                   CPU1
    ----                                   ----

spinlockirqsave(A) | spinunlockirqrestore(A) | spinlock(B) | | | ▼ | id = qnodesp->count++; | (Note that nodes[0].lock == A) | | | ▼ | Interrupt | (happens before "nodes[0].lock = B") | | | ▼ | spinlockirqsave(A) | | | ▼ | id = qnodesp->count++ | nodes[1].lock = A | | | ▼ | Tail of MCS queue | | spinlockirqsave(A) ▼ | Head of MCS queue ▼ | CPU0 is previous tail ▼ | Spin indefinitely ▼ (until "nodes[1].next != NULL") prev = gettail_qnode(A, CPU0) | ▼ prev == &qnodes[CPU0].nodes[0] (as qnodes ---truncated---(CVE-2024-46797)

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/amdgpu: Fix the warning division or modulo by zero

Checks the partition mode and returns an error for an invalid mode.(CVE-2024-46806)

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

drm/amd/display: Fix index may exceed array range within fpuupdatebwboundingbox

[Why] Coverity reports OVERRUN warning. soc.numstates could be 40. But array range of bwparams->clk_table.entries is 8.

[How] Assert if soc.num_states greater than 8.(CVE-2024-46811)

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

drm/amd/display: Skip inactive planes within ModeSupportAndSystemConfiguration

[Why] Coverity reports Memory - illegal accesses.

[How] Skip inactive planes.(CVE-2024-46812)

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:

wifi: ath12k: fix firmware crash due to invalid peer nss

Currently, if the access point receives an association request containing an Extended HE Capabilities Information Element with an invalid MCS-NSS, it triggers a firmware crash.

This issue arises when EHT-PHY capabilities shows support for a bandwidth and MCS-NSS set for that particular bandwidth is filled by zeros and due to this, driver obtains peer_nss as 0 and sending this value to firmware causes crash.

Address this issue by implementing a validation step for the peer_nss value before passing it to the firmware. If the value is greater than zero, proceed with forwarding it to the firmware. However, if the value is invalid, reject the association request to prevent potential firmware crashes.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1(CVE-2024-46827)

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:

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:

scsi: lpfc: Handle mailbox timeouts in lpfcgetsfp_info

The MBXTIMEOUT return code is not handled in lpfcgetsfpinfo and the routine unconditionally frees submitted mailbox commands regardless of return status. The issue is that for MBX_TIMEOUT cases, when firmware returns SFP information at a later time, that same mailbox memory region references previously freed memory in its cmpl routine.

Fix by adding checks for the MBXTIMEOUT return code. During mailbox resource cleanup, check the mbox flag to make sure that the wait did not timeout. If the MBOXWAKE flag is not set, then do not free the resources because it will be freed when firmware completes the mailbox at a later time in its cmpl routine.

Also, increase the timeout from 30 to 60 seconds to accommodate boot scripts requiring longer timeouts.(CVE-2024-46842)

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

scsi: ufs: core: Remove SCSI host only if added

If host tries to remove ufshcd driver from a UFS device it would cause a kernel panic if ufshcdasyncscan fails during ufshcdprobehba before adding a SCSI host with scsiaddhost and MCQ is enabled since SCSI host has been defered after MCQ configuration introduced by commit 0cab4023ec7b ("scsi: ufs: core: Defer adding host to SCSI if MCQ is supported").

To guarantee that SCSI host is removed only if it has been added, set the scsihostadded flag to true after adding a SCSI host and check whether it is set or not before removing it.(CVE-2024-46843)

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:

tracing/timerlat: Only clear timer if a kthread exists

The timerlat tracer can use user space threads to check for osnoise and timer latency. If the program using this is killed via a SIGTERM, the threads are shutdown one at a time and another tracing instance can start up resetting the threads before they are fully closed. That causes the hrtimer assigned to the kthread to be shutdown and freed twice when the dying thread finally closes the file descriptors, causing a use-after-free bug.

Only cancel the hrtimer if the associated thread is still around. Also add the interfacelock around the resetting of the tlatvar->kthread.

Note, this is just a quick fix that can be backported to stable. A real fix is to have a better synchronization between the shutdown of old threads and the starting of new ones.(CVE-2024-46845)

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

spi: rockchip: Resolve unbalanced runtime PM / system PM handling

Commit e882575efc77 ("spi: rockchip: Suspend and resume the bus during NOIRQSYSTEMSLEEP_PM ops") stopped respecting runtime PM status and simply disabled clocks unconditionally when suspending the system. This causes problems when the device is already runtime suspended when we go to sleep -- in which case we double-disable clocks and produce a WARNing.

Switch back to pmruntimeforce_{suspend,resume}(), because that still seems like the right thing to do, and the aforementioned commit makes no explanation why it stopped using it.

Also, refactor some of the resume() error handling, because it's not actually a good idea to re-disable clocks on failure.(CVE-2024-46846)

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:

dma-buf: heaps: Fix off-by-one in CMA heap fault handler

Until VMDONTEXPAND was added in commit 1c1914d6e8c6 ("dma-buf: heaps: Don't track CMA dma-buf pages under RssFile") it was possible to obtain a mapping larger than the buffer size via mremap and bypass the overflow check in dmabufmmapinternal. When using such a mapping to attempt to fault past the end of the buffer, the CMA heap fault handler also checks the fault offset against the buffer size, but gets the boundary wrong by 1. Fix the boundary check so that we don't read off the end of the pages array and insert an arbitrary page in the mapping.(CVE-2024-46852)

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)