OESA-2024-1497

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

vt: fix memory overlapping when deleting chars in the buffer

A memory overlapping copy occurs when deleting a long line. This memory overlapping copy can cause data corruption when scr_memcpyw is optimized to memcpy because memcpy does not ensure its behavior if the destination buffer overlaps with the source buffer. The line buffer is not always broken, because the memcpy utilizes the hardware acceleration, whose result is not deterministic.

Fix this problem by using replacing the scrmemcpyw with scrmemmovew.(CVE-2022-48627)

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

crypto: qcom-rng - ensure buffer for generate is completely filled

The generate function in struct rngalg expects that the destination buffer is completely filled if the function returns 0. qcomrngread() can run into a situation where the buffer is partially filled with randomness and the remaining part of the buffer is zeroed since qcomrng_generate() doesn't check the return value. This issue can be reproduced by running the following from libkcapi:

kcapi-rng -b 9000000 > OUTFILE

The generated OUTFILE will have three huge sections that contain all zeros, and this is caused by the code where the test 'val & PRNGSTATUSDATA_AVAIL' fails.

Let's fix this issue by ensuring that qcomrngread() always returns with a full buffer if the function returns success. Let's also have qcomrnggenerate() return the correct value.

Here's some statistics from the ent project (https://www.fourmilab.ch/random/) that shows information about the quality of the generated numbers:

$ ent -c qcom-random-before
Value Char Occurrences Fraction
  0           606748   0.067416
  1            33104   0.003678
  2            33001   0.003667
...
253   �        32883   0.003654
254   �        33035   0.003671
255   �        33239   0.003693

Total:       9000000   1.000000

Entropy = 7.811590 bits per byte.

Optimum compression would reduce the size
of this 9000000 byte file by 2 percent.

Chi square distribution for 9000000 samples is 9329962.81, and
randomly would exceed this value less than 0.01 percent of the
times.

Arithmetic mean value of data bytes is 119.3731 (127.5 = random).
Monte Carlo value for Pi is 3.197293333 (error 1.77 percent).
Serial correlation coefficient is 0.159130 (totally uncorrelated =
0.0).

Without this patch, the results of the chi-square test is 0.01%, and the numbers are certainly not random according to ent's project page. The results improve with this patch:

$ ent -c qcom-random-after
Value Char Occurrences Fraction
  0            35432   0.003937
  1            35127   0.003903
  2            35424   0.003936
...
253   �        35201   0.003911
254   �        34835   0.003871
255   �        35368   0.003930

Total:       9000000   1.000000

Entropy = 7.999979 bits per byte.

Optimum compression would reduce the size
of this 9000000 byte file by 0 percent.

Chi square distribution for 9000000 samples is 258.77, and randomly
would exceed this value 42.24 percent of the times.

Arithmetic mean value of data bytes is 127.5006 (127.5 = random).
Monte Carlo value for Pi is 3.141277333 (error 0.01 percent).
Serial correlation coefficient is 0.000468 (totally uncorrelated =
0.0).

This change was tested on a Nexus 5 phone (msm8974 SoC).(CVE-2022-48629)

The brcm80211 component in the Linux kernel through 6.5.10 has a brcmfcfg80211detach use-after-free in the device unplugging (disconnect the USB by hotplug) code. For physically proximate attackers with local access, this "could be exploited in a real world scenario." This is related to brcmfcfg80211escantimeoutworker in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c.(CVE-2023-47233)

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

drm: Don't unref the same fb many times by mistake due to deadlock handling

If we get a deadlock after the fb lookup in drmmodepageflipioctl() we proceed to unref the fb and then retry the whole thing from the top. But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually) end up being freed while it's still in use.

Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup.

This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIGDEBUGWWMUTEXSLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit.(CVE-2023-52486)

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

x86/alternatives: Disable KASAN in apply_alternatives()

Fei has reported that KASAN triggers during apply_alternatives() on a 5-level paging machine:

BUG: KASAN: out-of-bounds in rcu_is_watching()
Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0
...
__asan_load4()
rcu_is_watching()
trace_hardirqs_on()
text_poke_early()
apply_alternatives()
...

On machines with 5-level paging, cpufeatureenabled(X86FEATURELA57) gets patched. It includes KASAN code, where KASANSHADOWSTART depends on _VIRTUALMASKSHIFT, which is defined with cpufeature_enabled().

KASAN gets confused when applyalternatives() patches the KASANSHADOWSTART users. A test patch that makes KASANSHADOWSTART static, by replacing _VIRTUALMASKSHIFT with 56, works around the issue.

Fix it for real by disabling KASAN while the kernel is patching alternatives.

mingo: updated the changelog

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

net: nfc: llcp: Add lock when modifying device list

The device list needs its associated lock held when modifying it, or the list could become corrupted, as syzbot discovered.(CVE-2023-52524)

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

powerpc/mm: Fix null-pointer dereference in pgtablecacheadd

kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.(CVE-2023-52607)

A null pointer dereference vulnerability was found in ath10kwmitlvoppullmgmttxcomplev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service.(CVE-2023-7042)

A race condition was found in the Linux kernel's media/xc4000 device driver in xc4000 xc4000getfrequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.

(CVE-2024-24861)

createemptylvol in drivers/mtd/ubi/vtbl.c in the Linux kernel through 6.7.4 can attempt to allocate zero bytes, and crash, because of a missing check for ubi->leb_size.(CVE-2024-25739)

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

net/smc: fix illegal rmb_desc access in SMC-D connection dump

A crash was found when dumping SMC-D connections. It can be reproduced by following steps:

• run nginx/wrk test: smcrun nginx smcrun wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL>

• continuously dump SMC-D connections in parallel: watch -n 1 'smcss -D'

  BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55 RIP: 0010:smcdiagdump.constprop.0+0x5e5/0x620 [smcdiag] Call Trace: <TASK> ? _die+0x24/0x70 ? pagefaultoops+0x66/0x150 ? excpagefault+0x69/0x140 ? asmexcpagefault+0x26/0x30 ? _smcdiagdump.constprop.0+0x5e5/0x620 [smcdiag] ? _kmallocnodetrackcaller+0x35d/0x430 ? _allocskb+0x77/0x170 smcdiagdumpproto+0xd0/0xf0 [smcdiag] smcdiagdump+0x26/0x60 [smcdiag] netlinkdump+0x19f/0x320 _netlinkdumpstart+0x1dc/0x300 smcdiaghandlerdump+0x6a/0x80 [smcdiag] ? _pfxsmcdiagdump+0x10/0x10 [smcdiag] sockdiagrcvmsg+0x121/0x140 ? _pfxsockdiagrcvmsg+0x10/0x10 netlinkrcvskb+0x5a/0x110 sockdiagrcv+0x28/0x40 netlinkunicast+0x22a/0x330 netlinksendmsg+0x1f8/0x420 _socksendmsg+0xb0/0xc0 _syssendmsg+0x24e/0x300 ? copymsghdrfromuser+0x62/0x80 _syssendmsg+0x7c/0xd0 ? _dofault+0x34/0x160 ? doreadfault+0x5f/0x100 ? dofault+0xb0/0x110 ? _handlemmfault+0x2b0/0x6c0 _syssendmsg+0x4d/0x80 dosyscall64+0x69/0x180 entrySYSCALL64after_hwframe+0x6e/0x76

It is possible that the connection is in process of being established when we dump it. Assumed that the connection has been registered in a link group by smcconncreate() but the rmbdesc has not yet been initialized by smcbufcreate(), thus causing the illegal access to conn->rmbdesc. So fix it by checking before dump.(CVE-2024-26615)

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

ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs

The dreamcastcard->timer could schedule the spudmawork and the spudmawork could also arm the dreamcastcard->timer.

When the sndpcmsubstream is closing, the aicachannel will be deallocated. But it could still be dereferenced in the worker thread. The reason is that deltimer() will return directly regardless of whether the timer handler is running or not and the worker could be rescheduled in the timer handler. As a result, the UAF bug will happen. The racy situation is shown below:

  (Thread 1)                 |      (Thread 2)

sndaicapcmpcmclose() | ... | runspudma() //worker | modtimer() flushwork() | deltimer() | aicaperiodelapsed() //timer kfree(dreamcastcard->channel) | schedulework() | runspu_dma() //worker ... | dreamcastcard->channel-> //USE

In order to mitigate this bug and other possible corner cases, call modtimer() conditionally in runspudma(), then implement PCM syncstop op to cancel both the timer and worker. The sync_stop op will be called from PCM core appropriately when needed.(CVE-2024-26654)

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

tipc: Check the bearer type before calling tipcudpnlbeareradd()

syzbot reported the following general protection fault [1]:

general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087] ... RIP: 0010:tipcudpisknownpeer+0x9c/0x250 net/tipc/udpmedia.c:291 ... Call Trace: <TASK> tipcudpnlbeareradd+0x212/0x2f0 net/tipc/udpmedia.c:646 tipcnlbeareradd+0x21e/0x360 net/tipc/bearer.c:1089 genlfamilyrcvmsgdoit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genlfamilyrcvmsg net/netlink/genetlink.c:1052 [inline] genlrcvmsg+0x561/0x800 net/netlink/genetlink.c:1067 netlinkrcvskb+0x16b/0x440 net/netlink/afnetlink.c:2544 genlrcv+0x28/0x40 net/netlink/genetlink.c:1076 netlinkunicastkernel net/netlink/afnetlink.c:1341 [inline] netlinkunicast+0x53b/0x810 net/netlink/afnetlink.c:1367 netlinksendmsg+0x8b7/0xd70 net/netlink/afnetlink.c:1909 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0xd5/0x180 net/socket.c:745 syssendmsg+0x6ac/0x940 net/socket.c:2584 _syssendmsg+0x135/0x1d0 net/socket.c:2638 _syssendmsg+0x117/0x1e0 net/socket.c:2667 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x40/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

The cause of this issue is that when tipcnlbeareradd() is called with the TIPCNLABEARERUDPOPTS attribute, tipcudpnlbearer_add() is called even if the bearer is not UDP.

tipcudpisknownpeer() called by tipcudpnlbeareradd() assumes that the mediaptr field of the tipcbearer has an udp_bearer type object, so the function goes crazy for non-UDP bearers.

This patch fixes the issue by checking the bearer type before calling tipcudpnlbeareradd() in tipcnlbearer_add().(CVE-2024-26663)

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

nilfs2: fix hang in nilfslookupdirtydatabuffers()

Syzbot reported a hang issue in migratepagesbatch() called by mbind() and nilfslookupdirtydatabuffers() called in the log writer of nilfs2.

While migratepagesbatch() locks a folio and waits for the writeback to complete, the log writer thread that should bring the writeback to completion picks up the folio being written back in nilfslookupdirtydatabuffers() that it calls for subsequent log creation and was trying to lock the folio. Thus causing a deadlock.

In the first place, it is unexpected that folios/pages in the middle of writeback will be updated and become dirty. Nilfs2 adds a checksum to verify the validity of the log being written and uses it for recovery at mount, so data changes during writeback are suppressed. Since this is broken, an unclean shutdown could potentially cause recovery to fail.

Investigation revealed that the root cause is that the wait for writeback completion in nilfspagemkwrite() is conditional, and if the backing device does not require stable writes, data may be modified without waiting.

Fix these issues by making nilfspagemkwrite() wait for writeback to finish regardless of the stable write requirement of the backing device.(CVE-2024-26696)