OESA-2024-2256

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net: hns3: do not allow call hns3nicnet_open repeatedly

hns3nicnetopen() is not allowed to called repeatly, but there is no checking for this. When doing device reset and setup tc concurrently, there is a small oppotunity to call hns3nicnetopen repeatedly, and cause kernel bug by calling napi_enable twice.

The calltrace information is like below: [ 3078.222780] ------------[ cut here ]------------ [ 3078.230255] kernel BUG at net/core/dev.c:6991! [ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 3078.243431] Modules linked in: hns3 hclgevf hclge hnae3 vfioiommutype1 vfiopci vfiovirqfd vfio pv680mii(O) [ 3078.258880] CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G O 5.14.0-rc4+ #1 [ 3078.269102] Hardware name: , BIOS KpxxxFPGA 1P B600 V181 08/12/2021 [ 3078.276801] Workqueue: hclge hclgeservicetask [hclge] [ 3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 3078.296168] pc : napienable+0x80/0x84 tc qdisc sho[w 3d0e7v8 .e3t0h218 79] lr : hns3nicnet_open+0x138/0x510 [hns3]

[ 3078.314771] sp : ffff8000108abb20 [ 3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27: ffff0820a8490300 [ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 0000000000000000 [ 3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880 [ 3078.349018] x20: 0000000000000000 x19: ffff08209cd76900 x18: 0000000000000000 [ 3078.358620] x17: 0000000000000000 x16: ffffc816e1727a50 x15: 0000ffff8f4ff930 [ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12: 0000259e9dbeb6b4 [ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8 [ 3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344 [ 3078.396356] x5 : 0000000000000140 x4 : 0000000000000003 x3 : ffff08209cd76938 [ 3078.405365] x2 : 0000000000000000 x1 : 0000000000000010 x0 : ffff0820abfe38a0 [ 3078.414657] Call trace: [ 3078.418517] napienable+0x80/0x84 [ 3078.424626] hns3resetnotifyupenet+0x78/0xd0 [hns3] [ 3078.433469] hns3resetnotify+0x64/0x80 [hns3] [ 3078.441430] hclgenotifyclient+0x68/0xb0 [hclge] [ 3078.450511] hclgeresetrebuild+0x524/0x884 [hclge] [ 3078.458879] hclgeresetservicetask+0x3c4/0x680 [hclge] [ 3078.467470] hclgeservicetask+0xb0/0xb54 [hclge] [ 3078.475675] processonework+0x1dc/0x48c [ 3078.481888] workerthread+0x15c/0x464 [ 3078.487104] kthread+0x160/0x170 [ 3078.492479] retfrom_fork+0x10/0x18 [ 3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000) [ 3078.506889] ---[ end trace 8ebe0340a1b0fb44 ]---

Once hns3nicnetopen() is excute success, the flag HNS3NICSTATEDOWN will be cleared. So add checking for this flag, directly return when HNS3NICSTATE_DOWN is no set.(CVE-2021-47400)

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

efi: fix NULL-deref in init error path

In cases where runtime services are not supported or have been disabled, the runtime services workqueue will never have been allocated.

Do not try to destroy the workqueue unconditionally in the unlikely event that EFI initialisation fails to avoid dereferencing a NULL pointer.(CVE-2022-48879)

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

f2fs: fix to avoid dirent corruption

As Al reported in link[1]:

f2fsrename() ... if (olddir != newdir && !whiteout) f2fssetlink(oldinode, olddirentry, olddirpage, newdir); else f2fsputpage(olddir_page, 0);

You want correct inumber in the ".." link. And cross-directory rename does move the source to new parent, even if you'd been asked to leave a whiteout in the old place.

[1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/

With below testcase, it may cause dirent corruption, due to it missed to call f2fssetlink() to update ".." link to new directory. - mkdir -p dir/foo - renameat2 -w dir/foo bar

[ASSERT] (_chkdots_dentries:1421) --> Bad inode number[0x4] for '..', parent parent ino is [0x3] [FSCK] other corrupted bugs Fail

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

kprobes: Fix possible use-after-free issue on kprobe registration

When unloading a module, its state is changing MODULESTATELIVE -> MODULESTATEGOING -> MODULESTATEUNFORMED. Each change will take a time. is_module_text_address() and __module_text_address() works with MODULESTATELIVE and MODULESTATEGOING. If we use is_module_text_address() and __module_text_address() separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULESTATEUNFORMED between those operations.

In check_kprobe_address_safe(), if the second __module_text_address() is failed, that is ignored because it expected a kerneltext address. But it may have failed simply because module->state has been changed to MODULESTATEUNFORMED. In this case, armkprobe() will try to modify non-exist module text address (use-after-free).

To fix this problem, we should not use separated is_module_text_address() and __module_text_address(), but use only __module_text_address() once and do try_module_get(module) which is only available with MODULESTATELIVE.(CVE-2024-35955)

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

ipv6: fix race condition between ipv6getifaddr and ipv6deladdr

Although ipv6getifaddr walks inet6addrlst under the RCU lock, it still means hlistforeachentryrcu can return an item that got removed from the list. The memory itself of such item is not freed thanks to RCU but nothing guarantees the actual content of the memory is sane.

In particular, the reference count can be zero. This can happen if ipv6deladdr is called in parallel. ipv6deladdr removes the entry from inet6addrlst (hlistdelinitrcu(&ifp->addrlst)) and drops all references (_in6ifaput(ifp) + in6ifa_put(ifp)). With bad enough timing, this can happen:

1. In ipv6getifaddr, hlistforeachentryrcu returns an entry.

2. Then, the whole ipv6deladdr is executed for the given entry. The reference count drops to zero and kfree_rcu is scheduled.

3. ipv6getifaddr continues and tries to increments the reference count (in6ifahold).

4. The rcu is unlocked and the entry is freed.

5. The freed entry is returned.

Prevent increasing of the reference count in such case. The name in6ifaholdsafe is chosen to mimic the existing fib6infoholdsafe.

[ 41.506330] refcountt: addition on 0; use-after-free. [ 41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcountwarnsaturate+0xa5/0x130 [ 41.507413] Modules linked in: veth bridge stp llc [ 41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14 [ 41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) [ 41.509163] RIP: 0010:refcountwarnsaturate+0xa5/0x130 [ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff [ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282 [ 41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000 [ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900 [ 41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff [ 41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000 [ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48 [ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000 [ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0 [ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 41.516799] Call Trace: [ 41.517037] <TASK> [ 41.517249] ? _warn+0x7b/0x120 [ 41.517535] ? refcountwarnsaturate+0xa5/0x130 [ 41.517923] ? reportbug+0x164/0x190 [ 41.518240] ? handlebug+0x3d/0x70 [ 41.518541] ? excinvalidop+0x17/0x70 [ 41.520972] ? asmexcinvalidop+0x1a/0x20 [ 41.521325] ? refcountwarnsaturate+0xa5/0x130 [ 41.521708] ipv6getifaddr+0xda/0xe0 [ 41.522035] inet6rtmgetaddr+0x342/0x3f0 [ 41.522376] ? _pfxinet6rtmgetaddr+0x10/0x10 [ 41.522758] rtnetlinkrcvmsg+0x334/0x3d0 [ 41.523102] ? netlinkunicast+0x30f/0x390 [ 41.523445] ? _pfxrtnetlinkrcvmsg+0x10/0x10 [ 41.523832] netlinkrcvskb+0x53/0x100 [ 41.524157] netlinkunicast+0x23b/0x390 [ 41.524484] netlinksendmsg+0x1f2/0x440 [ 41.524826] _syssendto+0x1d8/0x1f0 [ 41.525145] _x64syssendto+0x1f/0x30 [ 41.525467] dosyscall64+0xa5/0x1b0 [ 41.525794] entrySYSCALL64after_hwframe+0x72/0x7a [ 41.526213] RIP: 0033:0x7fbc4cfcea9a [ 41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 [ 41.527942] RSP: 002b:00007f ---truncated---(CVE-2024-35969)

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

media: venus: fix use after free in vdec_close

There appears to be a possible use after free with vdec_close(). The firmware will add buffer release work to the work queue through HFI callbacks as a normal part of decoding. Randomly closing the decoder device from userspace during normal decoding can incur a read after free for inst.

Fix it by cancelling the work in vdec_close.(CVE-2024-42313)

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

leds: trigger: Unregister sysfs attributes before calling deactivate()

Triggers which have trigger specific sysfs attributes typically store related data in trigger-data allocated by the activate() callback and freed by the deactivate() callback.

Calling deviceremovegroups() after calling deactivate() leaves a window where the sysfs attributes show/store functions could be called after deactivation and then operate on the just freed trigger-data.

Move the deviceremovegroups() call to before deactivate() to close this race window.

This also makes the deactivation path properly do things in reverse order of the activation path which calls the activate() callback before calling deviceaddgroups().(CVE-2024-43830)

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

memcg: protect concurrent access to memcgroupidr

Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the memcgroupidr, the idralloc() and idrreplace() happen within css callback and thus are protected through cgroupmutex from concurrent modifications. However idrremove() for memcgroupidr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that.

We have been seeing listlru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of listlru code including listlruadd(), listlrudel() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the superblock's listlru didn't have listlruone for the memcg of that object. The initial suspicions were either the object is not allocated through kmemcachealloclru() or somehow memcglistlrualloc() failed to allocate listlruone() for a memcg but returned success. No evidence were found for these cases.

Looking more deeply, we started seeing situations where valid memcg's id is not present in memcgroupidr and in some cases multiple valid memcgs have same id and memcgroupidr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idrremove() calls or race between idralloc()/idrreplace() and idrremove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup listlrus on the system for all of them. Later access from other memcgs to the listlru cause crashes due to missing listlruone.(CVE-2024-43892)

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

serial: core: check uartclk for zero to avoid divide by zero

Calling ioctl TIOCSSERIAL with an invalid baudbase can result in uartclk being zero, which will result in a divide by zero error in uartgetdivisor(). The check for uartclk being zero in uartset_info() needs to be done before other settings are made as subsequent calls to ioctl TIOCSSERIAL for the same port would be impacted if the uartclk check was done where uartclk gets set.

Oops: divide error: 0000 PREEMPT SMP KASAN PTI RIP: 0010:uartgetdivisor (drivers/tty/serial/serialcore.c:580) Call Trace: <TASK> serial8250getdivisor (drivers/tty/serial/8250/8250port.c:2576 drivers/tty/serial/8250/8250port.c:2589) serial8250dosettermios (drivers/tty/serial/8250/8250port.c:502 drivers/tty/serial/8250/8250port.c:2741) serial8250settermios (drivers/tty/serial/8250/8250port.c:2862) uartchangelinesettings (./include/linux/spinlock.h:376 ./include/linux/serialcore.h:608 drivers/tty/serial/serialcore.c:222) uartportstartup (drivers/tty/serial/serialcore.c:342) uartstartup (drivers/tty/serial/serialcore.c:368) uartsetinfo (drivers/tty/serial/serialcore.c:1034) uartsetinfouser (drivers/tty/serial/serialcore.c:1059) ttysetserial (drivers/tty/ttyio.c:2637) ttyioctl (drivers/tty/ttyio.c:2647 drivers/tty/ttyio.c:2791) _x64sysioctl (fs/ioctl.c:52 fs/ioctl.c:907 fs/ioctl.c:893 fs/ioctl.c:893) dosyscall64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)

Rule: add(CVE-2024-43893)

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:

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: clean up our handling of refs == 0 in snapshot delete

In reada we BUGON(refs == 0), which could be unkind since we aren't holding a lock on the extent leaf and thus could get a transient incorrect answer. In walkdownproc we also BUGON(refs == 0), which could happen if we have extent tree corruption. Change that to return -EUCLEAN. In dowalkdown() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN is a more appropriate error code. Finally in walkupproc we have the same BUG_ON(refs == 0), so convert that to proper error handling. Also adjust the error message so we can actually do something with the information.(CVE-2024-46840)

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:

platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses

The panasonic laptop code in various places uses the SINF array with index values of 0 - SINFCURBRIGHT(0x0d) without checking that the SINF array is big enough.

Not all panasonic laptops have this many SINF array entries, for example the Toughbook CF-18 model only has 10 SINF array entries. So it only supports the AC+DC brightness entries and mute.

Check that the SINF array has a minimum size which covers all AC+DC brightness entries and refuse to load if the SINF array is smaller.

For higher SINF indexes hide the sysfs attributes when the SINF array does not contain an entry for that attribute, avoiding show()/store() accessing the array out of bounds and add bounds checking to the probe() and resume() code accessing these.(CVE-2024-46859)