summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-11-20Linux 6.5.12v6.5.12Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20231115191600.708733204@linuxfoundation.org Tested-by: SeongJae Park <sj@kernel.org> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Ron Economos <re@w6rz.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-20btrfs: make found_logical_ret parameter mandatory for function ↵Qu Wenruo1-3/+7
queue_scrub_stripe() [ Upstream commit 47e2b06b7b5cb356a987ba3429550c3a89ea89d6 ] [BUG] There is a compilation warning reported on commit ae76d8e3e135 ("btrfs: scrub: fix grouping of read IO"), where gcc (14.0.0 20231022 experimental) is reporting the following uninitialized variable: fs/btrfs/scrub.c: In function ‘scrub_simple_mirror.isra’: fs/btrfs/scrub.c:2075:29: error: ‘found_logical’ may be used uninitialized [-Werror=maybe-uninitialized[https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmaybe-uninitialized]] 2075 | cur_logical = found_logical + BTRFS_STRIPE_LEN; fs/btrfs/scrub.c:2040:21: note: ‘found_logical’ was declared here 2040 | u64 found_logical; | ^~~~~~~~~~~~~ [CAUSE] This is a false alert, as @found_logical is passed as parameter @found_logical_ret of function queue_scrub_stripe(). As long as queue_scrub_stripe() returned 0, we would update @found_logical_ret. And if queue_scrub_stripe() returned >0 or <0, the caller would not utilized @found_logical, thus there should be nothing wrong. Although the triggering gcc is still experimental, it looks like the extra check on "if (found_logical_ret)" can sometimes confuse the compiler. Meanwhile the only caller of queue_scrub_stripe() is always passing a valid pointer, there is no need for such check at all. [FIX] Although the report itself is a false alert, we can still make it more explicit by: - Replace the check for @found_logical_ret with ASSERT() - Initialize @found_logical to U64_MAX - Add one extra ASSERT() to make sure @found_logical got updated Link: https://lore.kernel.org/linux-btrfs/87fs1x1p93.fsf@gentoo.org/ Fixes: ae76d8e3e135 ("btrfs: scrub: fix grouping of read IO") Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20perf parse-events: Fix driver config termIan Rogers1-0/+17
commit 45fc4628c15ab2cb7b2f53354b21db63f0a41f81 upstream. Inadvertently deleted in commit 30f4ade33d649aa0 ("perf tools: Revert enable indices setting syntax for BPF map"). Fixes: 30f4ade33d649aa0 ("perf tools: Revert enable indices setting syntax for BPF map") Reported-by: James Clark <james.clark@arm.com> Reviewed-by: James Clark <james.clark@arm.com> Signed-off-by: Ian Rogers <irogers@google.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20230905033805.3094293-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-20bpf, x86: initialize the variable "first_off" in save_args()Menglong Dong1-1/+1
commit 492e797fdab25f2d8eb1b6bb3236f4aac474f878 upstream. As Dan Carpenter reported, the variable "first_off" which is passed to clean_stack_garbage() in save_args() can be uninitialized, which can cause runtime warnings with KMEMsan. Therefore, init it with 0. Fixes: 473e3150e30a ("bpf, x86: allow function arguments up to 12 for TRACING") Cc: Hao Peng <flyingpeng@tencent.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/bpf/09784025-a812-493f-9829-5e26c8691e07@moroto.mountain/ Signed-off-by: Menglong Dong <imagedong@tencent.com> Link: https://lore.kernel.org/r/20230719110330.2007949-1-imagedong@tencent.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-20btrfs: use u64 for buffer sizes in the tree search ioctlsFilipe Manana1-5/+5
[ Upstream commit dec96fc2dcb59723e041416b8dc53e011b4bfc2e ] In the tree search v2 ioctl we use the type size_t, which is an unsigned long, to track the buffer size in the local variable 'buf_size'. An unsigned long is 32 bits wide on a 32 bits architecture. The buffer size defined in struct btrfs_ioctl_search_args_v2 is a u64, so when we later try to copy the local variable 'buf_size' to the argument struct, when the search returns -EOVERFLOW, we copy only 32 bits which will be a problem on big endian systems. Fix this by using a u64 type for the buffer sizes, not only at btrfs_ioctl_tree_search_v2(), but also everywhere down the call chain so that we can use the u64 at btrfs_ioctl_tree_search_v2(). Fixes: cc68a8a5a433 ("btrfs: new ioctl TREE_SEARCH_V2") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/linux-btrfs/ce6f4bd6-9453-4ffe-ba00-cee35495e10f@moroto.mountain/ Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20Revert "mmc: core: Capture correct oemid-bits for eMMC cards"Dominique Martinet1-1/+1
commit 421b605edb1ce611dee06cf6fd9a1c1f2fd85ad0 upstream. This reverts commit 84ee19bffc9306128cd0f1c650e89767079efeff. The commit above made quirks with an OEMID fail to be applied, as they were checking card->cid.oemid for the full 16 bits defined in MMC_FIXUP macros but the field would only contain the bottom 8 bits. eMMC v5.1A might have bogus values in OEMID's higher bits so another fix will be made, but it has been decided to revert this until that is ready. Fixes: 84ee19bffc93 ("mmc: core: Capture correct oemid-bits for eMMC cards") Link: https://lkml.kernel.org/r/ZToJsSLHr8RnuTHz@codewreck.org Link: https://lkml.kernel.org/r/CAPDyKFqkKibcXnwjnhc3+W1iJBHLeqQ9BpcZrSwhW2u9K2oUtg@mail.gmail.com Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com> Cc: stable@vger.kernel.org Cc: Alex Fetters <Alex.Fetters@garmin.com> Reviewed-by: Avri Altman <avri.altman@wdc.com> Link: https://lore.kernel.org/r/20231103004220.1666641-1-asmadeus@codewreck.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-20Revert "PCI/ASPM: Disable only ASPM_STATE_L1 when driver, disables L1"Heiner Kallweit1-1/+2
commit 3cb4f534bac010258b2688395c2f13459a932be9 upstream. This reverts commit fb097dcd5a28c0a2325632405c76a66777a6bed9. After fb097dcd5a28 ("PCI/ASPM: Disable only ASPM_STATE_L1 when driver disables L1"), disabling L1 via pci_disable_link_state(PCIE_LINK_STATE_L1), then enabling one substate, e.g., L1.1, via sysfs actually enables *all* the substates. For example, r8169 disables L1 because of hardware issues on a number of systems, which implicitly disables the L1.1 and L1.2 substates. On some systems, L1 and L1.1 work fine, but L1.2 causes missed rx packets. Enabling L1.1 via the sysfs "aspm_l1_1" attribute unexpectedly enables L1.2 as well as L1.1. After fb097dcd5a28, pci_disable_link_state(PCIE_LINK_STATE_L1) adds only ASPM_L1 (but not any of the L1.x substates) to the "aspm_disable" mask: --- Before fb097dcd5a28 +++ After fb097dcd5a28 # r8169 disables L1: pci_disable_link_state(PCIE_LINK_STATE_L1) - disable |= ASPM_L1 | ASPM_L1_1 | ASPM_L1_2 | ... # disable L1, L1.x + disable |= ASPM_L1 # disable L1 only # write "1" to sysfs "aspm_l1_1" attribute: l1_1_aspm aspm_attr_store_common(state = ASPM_L1_1) disable &= ~ASPM_L1_1 # enable L1.1 if (state & (ASPM_L1_1 | ...)) # if enabling any substate disable &= ~ASPM_L1 # enable L1 # final state: - disable = ASPM_L1_2 | ... # L1, L1.1 enabled; L1.2 disabled + disable = 0 # L1, L1.1, L1.2 all enabled Enabling an L1.x substate removes the substate and L1 from the "aspm_disable" mask. After fb097dcd5a28, the substates were not added to the mask when disabling L1, so enabling one substate implicitly enables all of them. Revert fb097dcd5a28 so enabling one substate doesn't enable the others. Link: https://lore.kernel.org/r/c75931ac-7208-4200-9ca1-821629cf5e28@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> [bhelgaas: work through example in commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-20x86/amd_nb: Use Family 19h Models 60h-7Fh Function 4 IDsYazen Ghannam1-0/+3
commit 2a565258b3f4bbdc7a3c09cd02082cb286a7bffc upstream. Three PCI IDs for DF Function 4 were defined but not used. Add them to the "link" list. Fixes: f8faf3496633 ("x86/amd_nb: Add AMD PCI IDs for SMN communication") Fixes: 23a5b8bb022c ("x86/amd_nb: Add PCI ID for family 19h model 78h") Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230803150430.3542854-1-yazen.ghannam@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-20io_uring/net: ensure socket is marked connected on connect retryJens Axboe1-13/+11
commit f8f9ab2d98116e79d220f1d089df7464ad4e026d upstream. io_uring does non-blocking connection attempts, which can yield some unexpected results if a connect request is re-attempted by an an application. This is equivalent to the following sync syscall sequence: sock = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, IPPROTO_TCP); connect(sock, &addr, sizeof(addr); ret == -1 and errno == EINPROGRESS expected here. Now poll for POLLOUT on sock, and when that returns, we expect the socket to be connected. But if we follow that procedure with: connect(sock, &addr, sizeof(addr)); you'd expect ret == -1 and errno == EISCONN here, but you actually get ret == 0. If we attempt the connection one more time, then we get EISCON as expected. io_uring used to do this, but turns out that bluetooth fails with EBADFD if you attempt to re-connect. Also looks like EISCONN _could_ occur with this sequence. Retain the ->in_progress logic, but work-around a potential EISCONN or EBADFD error and only in those cases look at the sock_error(). This should work in general and avoid the odd sequence of a repeated connect request returning success when the socket is already connected. This is all a side effect of the socket state being in a CONNECTING state when we get EINPROGRESS, and only a re-connect or other related operation will turn that into CONNECTED. Cc: stable@vger.kernel.org Fixes: 3fb1bd688172 ("io_uring/net: handle -EINPROGRESS correct for IORING_OP_CONNECT") Link: https://github.com/axboe/liburing/issues/980 Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-20selftests: mptcp: fix wait_rm_addr/sf parametersGeliang Tang1-4/+10
commit 9168ea02b898d3dde98b51e4bd3fb082bd438dab upstream. The second input parameter of 'wait_rm_addr/sf $1 1' is misused. If it's 1, wait_rm_addr/sf will never break, and will loop ten times, then 'wait_rm_addr/sf' equals to 'sleep 1'. This delay time is too long, which can sometimes make the tests fail. A better way to use wait_rm_addr/sf is to use rm_addr/sf_count to obtain the current value, and then pass into wait_rm_addr/sf. Fixes: 4369c198e599 ("selftests: mptcp: test userspace pm out of transfer") Cc: stable@vger.kernel.org Suggested-by: Matthieu Baerts <matttbe@kernel.org> Reviewed-by: Matthieu Baerts <matttbe@kernel.org> Signed-off-by: Geliang Tang <geliang.tang@suse.com> Signed-off-by: Mat Martineau <martineau@kernel.org> Link: https://lore.kernel.org/r/20231025-send-net-next-20231025-v1-2-db8f25f798eb@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-20Revert "drm/ast: report connection status on Display Port."Sasha Levin4-66/+14
This reverts commit f81bb0ac7872893241319ea82504956676ef02fd. The commit depends on e329cb53b45d ("drm/ast: Add BMC virtual connector") and will cause hangs on boot without that dependency. Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20tracing/kprobes: Fix the order of argument descriptionsYujie Liu1-1/+1
[ Upstream commit f032c53bea6d2057c14553832d846be2f151cfb2 ] The order of descriptions should be consistent with the argument list of the function, so "kretprobe" should be the second one. int __kprobe_event_gen_cmd_start(struct dynevent_cmd *cmd, bool kretprobe, const char *name, const char *loc, ...) Link: https://lore.kernel.org/all/20231031041305.3363712-1-yujie.liu@intel.com/ Fixes: 2a588dd1d5d6 ("tracing: Add kprobe event command generation functions") Suggested-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Yujie Liu <yujie.liu@intel.com> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20fbdev: fsl-diu-fb: mark wr_reg_wa() staticArnd Bergmann1-1/+1
[ Upstream commit a5035c81847430dfa3482807b07325f29e9e8c09 ] wr_reg_wa() is not an appropriate name for a global function, and doesn't need to be global anyway, so mark it static and avoid the warning: drivers/video/fbdev/fsl-diu-fb.c:493:6: error: no previous prototype for 'wr_reg_wa' [-Werror=missing-prototypes] Fixes: 0d9dab39fbbe ("powerpc/5121: fsl-diu-fb: fix issue with re-enabling DIU area descriptor") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20ALSA: hda/realtek: Add support dual speaker for DellKailang Yang1-7/+33
[ Upstream commit f0d9da19d7de9e845e7a93a901c4b9658df6b492 ] Dell new platform support dual speaker. But BIOS verb table only show one speaker. It will fill verb table for second speaker. Then bind with CS AMP model. Fixes: de90f5165b1c ("ALSA: hda/realtek: Add support for DELL Oasis 13/14/16 laptops") Signed-off-by: Kailang Yang <kailang@realtek.com> Link: https://lore.kernel.org/r/4dd390a77bf742b8a518ac2deee00b0f@realtek.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20fbdev: imsttfb: fix a resource leak in probeDan Carpenter1-13/+16
[ Upstream commit aba6ab57a910ad4b940c2024d15f2cdbf5b7f76b ] I've re-written the error handling but the bug is that if init_imstt() fails we need to call iounmap(par->cmap_regs). Fixes: c75f5a550610 ("fbdev: imsttfb: Fix use after free bug in imsttfb_probe") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20fbdev: imsttfb: fix double free in probe()Dan Carpenter1-5/+1
[ Upstream commit e08c30efda21ef4c0ec084a3a9581c220b442ba9 ] The init_imstt() function calls framebuffer_release() on error and then the probe() function calls it again. It should only be done in probe. Fixes: 518ecb6a209f ("fbdev: imsttfb: Fix error path of imsttfb_probe()") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20arm64/arm: arm_pmuv3: perf: Don't truncate 64-bit registersIlkka Koskinen3-48/+31
[ Upstream commit 403edfa436286b21f5ffe6856ae5b36396e8966c ] The driver used to truncate several 64-bit registers such as PMCEID[n] registers used to describe whether architectural and microarchitectural events in range 0x4000-0x401f exist. Due to discarding the bits, the driver made the events invisible, even if they existed. Moreover, PMCCFILTR and PMCR registers have additional bits in the upper 32 bits. This patch makes them available although they aren't currently used. Finally, functions handling PMXEVCNTR and PMXEVTYPER registers are removed as they not being used at all. Fixes: df29ddf4f04b ("arm64: perf: Abstract system register accesses away") Reported-by: Carl Worth <carl@os.amperecomputing.com> Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Acked-by: Will Deacon <will@kernel.org> Closes: https://lore.kernel.org/.. Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/20231102183012.1251410-1-ilkka@os.amperecomputing.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20spi: spi-zynq-qspi: add spi-mem to driver kconfig dependenciesAmit Kumar Mahapatra1-0/+1
[ Upstream commit c2ded280a4b1b7bd93e53670528504be08d24967 ] Zynq QSPI driver has been converted to use spi-mem framework so add spi-mem to driver kconfig dependencies. Fixes: 67dca5e580f1 ("spi: spi-mem: Add support for Zynq QSPI controller") Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Link: https://lore.kernel.org/r/1699037031-702858-1-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20ASoC: dapm: fix clock get nameJerome Brunet1-1/+1
[ Upstream commit 4bdcbc31ad2112385ad525b28972c45015e6ad70 ] The name currently used to get the clock includes the dapm prefix. It should use the name as provided to the widget, without the prefix. Fixes: 3caac759681e ("ASoC: soc-dapm.c: fixup snd_soc_dapm_new_control_unlocked() error handling") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20231106103712.703962-1-jbrunet@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20ASoC: hdmi-codec: register hpd callback on component probeJerome Brunet1-8/+19
[ Upstream commit 15be353d55f9e12e34f9a819f51eb41fdef5eda8 ] The HDMI hotplug callback to the hdmi-codec is currently registered when jack is set. The hotplug not only serves to report the ASoC jack state but also to get the ELD. It should be registered when the component probes instead, so it does not depend on the card driver registering a jack for the HDMI to properly report the ELD. Fixes: 25ce4f2b3593 ("ASoC: hdmi-codec: Get ELD in before reporting plugged event") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20231106104013.704356-1-jbrunet@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20ASoC: mediatek: mt8186_mt6366_rt1019_rt5682s: trivial: fix error messagesEugen Hristev1-2/+2
[ Upstream commit 004fc58edea6f00db9ad07b40b882e8d976f7a54 ] Property 'playback-codecs' is referenced as 'speaker-codec' in the error message, and this can lead to confusion. Correct the error message such that the correct property name is referenced. Fixes: 0da16e370dd7 ("ASoC: mediatek: mt8186: add machine driver with mt6366, rt1019 and rt5682s") Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231031103139.77395-1-eugen.hristev@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20drm/syncobj: fix DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLEErik Kurzinger1-1/+2
[ Upstream commit 101c9f637efa1655f55876644d4439e552267527 ] If DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT is invoked with the DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE flag set but no fence has yet been submitted for the given timeline point the call will fail immediately with EINVAL. This does not match the intended behavior where the call should wait until the fence has been submitted (or the timeout expires). The following small example program illustrates the issue. It should wait for 5 seconds and then print ETIME, but instead it terminates right away after printing EINVAL. #include <stdio.h> #include <fcntl.h> #include <time.h> #include <errno.h> #include <xf86drm.h> int main(void) { int fd = open("/dev/dri/card0", O_RDWR); uint32_t syncobj; drmSyncobjCreate(fd, 0, &syncobj); struct timespec ts; clock_gettime(CLOCK_MONOTONIC, &ts); uint64_t point = 1; if (drmSyncobjTimelineWait(fd, &syncobj, &point, 1, ts.tv_sec * 1000000000 + ts.tv_nsec + 5000000000, // 5s DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE, NULL)) { printf("drmSyncobjTimelineWait failed %d\n", errno); } } Fixes: 01d6c3578379 ("drm/syncobj: add support for timeline point wait v8") Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com> Reviewed by: Simon Ser <contact@emersion.fd> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/1fac96f1-2f3f-f9f9-4eb0-340f27a8f6c0@nvidia.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20drm/vc4: tests: Fix UAF in the mock helpersMaxime Ripard2-2/+2
[ Upstream commit cdcd6aef9db5797995d4153ea19fdf56d189f0e4 ] The VC4 mock helpers allocate the CRTC, encoders and connectors using a call to kunit_kzalloc(), but the DRM device they are attache to survives for longer than the test itself which leads to use-after-frees reported by KASAN. Switch to drmm_kzalloc to tie the lifetime of these objects to the main DRM device. Fixes: f759f5b53f1c ("drm/vc4: tests: Introduce a mocking infrastructure") Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> Closes: https://lore.kernel.org/all/CA+G9fYvJA2HGqzR9LGgq63v0SKaUejHAE6f7+z9cwWN-ourJ_g@mail.gmail.com/ Tested-by: Anders Roxell <anders.roxell@linaro.org> Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231024105640.352752-1-mripard@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20module/decompress: use kvmalloc() consistentlyAndrea Righi1-4/+4
[ Upstream commit 17fc8084aa8f9d5235f252fc3978db657dd77e92 ] We consistently switched from kmalloc() to vmalloc() in module decompression to prevent potential memory allocation failures with large modules, however vmalloc() is not as memory-efficient and fast as kmalloc(). Since we don't know in general the size of the workspace required by the decompression algorithm, it is more reasonable to use kvmalloc() consistently, also considering that we don't have special memory requirements here. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Tested-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20RISC-V: Don't fail in riscv_of_parent_hartid() for disabled HARTsAnup Patel1-5/+6
[ Upstream commit c4676f8dc1e12e68d6511f9ed89707fdad4c962c ] The riscv_of_processor_hartid() used by riscv_of_parent_hartid() fails for HARTs disabled in the DT. This results in the following warning thrown by the RISC-V INTC driver for the E-core on SiFive boards: [ 0.000000] riscv-intc: unable to find hart id for /cpus/cpu@0/interrupt-controller The riscv_of_parent_hartid() is only expected to read the hartid from the DT so we directly call of_get_cpu_hwid() instead of calling riscv_of_processor_hartid(). Fixes: ad635e723e17 ("riscv: cpu: Add 64bit hartid support on RV64") Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20231027154254.355853-2-apatel@ventanamicro.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20net/sched: act_ct: Always fill offloading tuple iifidxVlad Buslov3-15/+32
[ Upstream commit 9bc64bd0cd765f696fcd40fc98909b1f7c73b2ba ] Referenced commit doesn't always set iifidx when offloading the flow to hardware. Fix the following cases: - nf_conn_act_ct_ext_fill() is called before extension is created with nf_conn_act_ct_ext_add() in tcf_ct_act(). This can cause rule offload with unspecified iifidx when connection is offloaded after only single original-direction packet has been processed by tc data path. Always fill the new nf_conn_act_ct_ext instance after creating it in nf_conn_act_ct_ext_add(). - Offloading of unidirectional UDP NEW connections is now supported, but ct flow iifidx field is not updated when connection is promoted to bidirectional which can result reply-direction iifidx to be zero when refreshing the connection. Fill in the extension and update flow iifidx before calling flow_offload_refresh(). Fixes: 9795ded7f924 ("net/sched: act_ct: Fill offloading tuple iifidx") Reviewed-by: Paul Blakey <paulb@nvidia.com> Signed-off-by: Vlad Buslov <vladbu@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Fixes: 6a9bad0069cf ("net/sched: act_ct: offload UDP NEW connections") Link: https://lore.kernel.org/r/20231103151410.764271-1-vladbu@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20netfilter: nat: fix ipv6 nat redirect with mapped and scoped addressesFlorian Westphal1-1/+26
[ Upstream commit 80abbe8a8263106fe45a4f293b92b5c74cc9cc8a ] The ipv6 redirect target was derived from the ipv4 one, i.e. its identical to a 'dnat' with the first (primary) address assigned to the network interface. The code has been moved around to make it usable from nf_tables too, but its still the same as it was back when this was added in 2012. IPv6, however, has different types of addresses, if the 'wrong' address comes first the redirection does not work. In Daniels case, the addresses are: inet6 ::ffff:192 ... inet6 2a01: ... ... so the function attempts to redirect to the mapped address. Add more checks before the address is deemed correct: 1. If the packets' daddr is scoped, search for a scoped address too 2. skip tentative addresses 3. skip mapped addresses Use the first address that appears to match our needs. Reported-by: Daniel Huhardeaux <tech@tootai.net> Closes: https://lore.kernel.org/netfilter/71be06b8-6aa0-4cf9-9e0b-e2839b01b22f@tootai.net/ Fixes: 115e23ac78f8 ("netfilter: ip6tables: add REDIRECT target") Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20netfilter: xt_recent: fix (increase) ipv6 literal buffer lengthMaciej Żenczykowski1-1/+1
[ Upstream commit 7b308feb4fd2d1c06919445c65c8fbf8e9fd1781 ] in6_pton() supports 'low-32-bit dot-decimal representation' (this is useful with DNS64/NAT64 networks for example): # echo +aaaa:bbbb:cccc:dddd:eeee:ffff:1.2.3.4 > /proc/self/net/xt_recent/DEFAULT # cat /proc/self/net/xt_recent/DEFAULT src=aaaa:bbbb:cccc:dddd:eeee:ffff:0102:0304 ttl: 0 last_seen: 9733848829 oldest_pkt: 1 9733848829 but the provided buffer is too short: # echo +aaaa:bbbb:cccc:dddd:eeee:ffff:255.255.255.255 > /proc/self/net/xt_recent/DEFAULT -bash: echo: write error: Invalid argument Fixes: 079aa88fe717 ("netfilter: xt_recent: IPv6 support") Signed-off-by: Maciej Żenczykowski <zenczykowski@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20i2c: iproc: handle invalid slave stateRoman Bacik1-58/+75
[ Upstream commit ba15a14399c262f91ce30c19fcbdc952262dd1be ] Add the code to handle an invalid state when both bits S_RX_EVENT (indicating a transaction) and S_START_BUSY (indicating the end of transaction - transition of START_BUSY from 1 to 0) are set in the interrupt status register during a slave read. Signed-off-by: Roman Bacik <roman.bacik@broadcom.com> Fixes: 1ca1b4516088 ("i2c: iproc: handle Master aborted error") Acked-by: Ray Jui <ray.jui@broadcom.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20net: enetc: shorten enetc_setup_xdp_prog() error message to fit ↵Vladimir Oltean1-1/+1
NETLINK_MAX_FMTMSG_LEN [ Upstream commit f968c56417f00be4cb62eadeed042a1e3c80dc53 ] NETLINK_MAX_FMTMSG_LEN is currently hardcoded to 80, and we provide an error printf-formatted string having 96 characters including the terminating \0. Assuming each %d (representing a queue) gets replaced by a number having at most 2 digits (a reasonable assumption), the final string is also 96 characters wide, which is too much. Reduce the verbiage a bit by removing some (partially) redundant words, which makes the new printf-formatted string be 73 characters wide with the trailing newline. Fixes: 800db2d125c2 ("net: enetc: ensure we always have a minimum number of TXQs for stack") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/lkml/202311061336.4dsWMT1h-lkp@intel.com/ Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20231106160311.616118-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20r8169: respect userspace disabling IFF_MULTICASTHeiner Kallweit1-0/+2
[ Upstream commit 8999ce4cfc87e61b4143ec2e7b93d8e92e11fa7f ] So far we ignore the setting of IFF_MULTICAST. Fix this and clear bit AcceptMulticast if IFF_MULTICAST isn't set. Note: Based on the implementations I've seen it doesn't seem to be 100% clear what a driver is supposed to do if IFF_ALLMULTI is set but IFF_MULTICAST is not. This patch is based on the understanding that IFF_MULTICAST has precedence. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/4a57ba02-d52d-4369-9f14-3565e6c1f7dc@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20vsock/virtio: remove socket from connected/bound list on shutdownFilippo Storniolo1-5/+11
[ Upstream commit 3a5cc90a4d1756072619fe511d07621bdef7f120 ] If the same remote peer, using the same port, tries to connect to a server on a listening port more than once, the server will reject the connection, causing a "connection reset by peer" error on the remote peer. This is due to the presence of a dangling socket from a previous connection in both the connected and bound socket lists. The inconsistency of the above lists only occurs when the remote peer disconnects and the server remains active. This bug does not occur when the server socket is closed: virtio_transport_release() will eventually schedule a call to virtio_transport_do_close() and the latter will remove the socket from the bound and connected socket lists and clear the sk_buff. However, virtio_transport_do_close() will only perform the above actions if it has been scheduled, and this will not happen if the server is processing the shutdown message from a remote peer. To fix this, introduce a call to vsock_remove_sock() when the server is handling a client disconnect. This is to remove the socket from the bound and connected socket lists without clearing the sk_buff. Fixes: 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko") Reported-by: Daan De Meyer <daan.j.demeyer@gmail.com> Tested-by: Daan De Meyer <daan.j.demeyer@gmail.com> Co-developed-by: Luigi Leonardi <luigi.leonardi@outlook.com> Signed-off-by: Luigi Leonardi <luigi.leonardi@outlook.com> Signed-off-by: Filippo Storniolo <f.storniolo95@gmail.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20blk-core: use pr_warn_ratelimited() in bio_check_ro()Yu Kuai1-2/+2
[ Upstream commit 1b0a151c10a6d823f033023b9fdd9af72a89591b ] If one of the underlying disks of raid or dm is set to read-only, then each io will generate new log, which will cause message storm. This environment is indeed problematic, however we can't make sure our naive custormer won't do this, hence use pr_warn_ratelimited() to prevent message storm in this case. Signed-off-by: Yu Kuai <yukuai3@huawei.com> Fixes: 57e95e4670d1 ("block: fix and cleanup bio_check_ro") Signed-off-by: Ye Bin <yebin10@huawei.com> Link: https://lore.kernel.org/r/20231107111247.2157820-1-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20nbd: fix uaf in nbd_openLi Lingfeng1-2/+9
[ Upstream commit 327462725b0f759f093788dfbcb2f1fd132f956b ] Commit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk and blk_cleanup_disk") cleans up disk by blk_cleanup_disk() and it won't set disk->private_data as NULL as before. UAF may be triggered in nbd_open() if someone tries to open nbd device right after nbd_put() since nbd has been free in nbd_dev_remove(). Fix this by implementing ->free_disk and free private data in it. Fixes: 4af5f2e03013 ("nbd: use blk_mq_alloc_disk and blk_cleanup_disk") Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Link: https://lore.kernel.org/r/20231107103435.2074904-1-lilingfeng@huaweicloud.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20tg3: power down device only on SYSTEM_POWER_OFFGeorge Shuklin1-1/+2
[ Upstream commit 9fc3bc7643341dc5be7d269f3d3dbe441d8d7ac3 ] Dell R650xs servers hangs on reboot if tg3 driver calls tg3_power_down. This happens only if network adapters (BCM5720 for R650xs) were initialized using SNP (e.g. by booting ipxe.efi). The actual problem is on Dell side, but this fix allows servers to come back alive after reboot. Signed-off-by: George Shuklin <george.shuklin@gmail.com> Fixes: 2ca1c94ce0b6 ("tg3: Disable tg3 device on system reboot to avoid triggering AER") Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231103115029.83273-1-george.shuklin@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20riscv: boot: Fix creation of loader.binGeert Uytterhoeven1-0/+1
[ Upstream commit 57a4542cb7c9baa1509c3366b57a08d75b212ead ] When flashing loader.bin for K210 using kflash:     [ERROR] This is an ELF file and cannot be programmed to flash directly: arch/riscv/boot/loader.bin Before, loader.bin relied on "OBJCOPYFLAGS := -O binary" in the main RISC-V Makefile to create a boot image with the right format. With this removed, the image is now created in the wrong (ELF) format. Fix this by adding an explicit rule. Fixes: 505b02957e74f0c5 ("riscv: Remove duplicate objcopy flag") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Link: https://lore.kernel.org/r/1086025809583809538dfecaa899892218f44e7e.1698159066.git.geert+renesas@glider.be Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20nvme: fix error-handling for io_uring nvme-passthroughAnuj Gupta1-2/+5
[ Upstream commit 1147dd0503564fa0e03489a039f9e0c748a03db4 ] Driver may return an error before submitting the command to the device. Ensure that such error is propagated up. Fixes: 456cba386e94 ("nvme: wire-up uring-cmd support for io-passthru on char-device.") Signed-off-by: Anuj Gupta <anuj20.g@samsung.com> Signed-off-by: Kanchan Joshi <joshi.k@samsung.com> Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20net/smc: put sk reference if close work was canceledD. Wythe1-1/+2
[ Upstream commit aa96fbd6d78d9770323b21e2c92bd38821be8852 ] Note that we always hold a reference to sock when attempting to submit close_work. Therefore, if we have successfully canceled close_work from pending, we MUST release that reference to avoid potential leaks. Fixes: 42bfba9eaa33 ("net/smc: immediate termination for SMCD link groups") Signed-off-by: D. Wythe <alibuda@linux.alibaba.com> Reviewed-by: Dust Li <dust.li@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20net/smc: allow cdc msg send rather than drop it with NULL sndbuf_descD. Wythe1-5/+4
[ Upstream commit c5bf605ba4f9d6fbbb120595ab95002f4716edcb ] This patch re-fix the issues mentioned by commit 22a825c541d7 ("net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler()"). Blocking sending message do solve the issues though, but it also prevents the peer to receive the final message. Besides, in logic, whether the sndbuf_desc is NULL or not have no impact on the processing of cdc message sending. Hence that, this patch allows the cdc message sending but to check the sndbuf_desc with care in smc_cdc_tx_handler(). Fixes: 22a825c541d7 ("net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler()") Signed-off-by: D. Wythe <alibuda@linux.alibaba.com> Reviewed-by: Dust Li <dust.li@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20net/smc: fix dangling sock under state SMC_APPFINCLOSEWAITD. Wythe4-4/+9
[ Upstream commit 5211c9729484c923f8d2e06bd29f9322cc42bb8f ] Considering scenario: smc_cdc_rx_handler __smc_release sock_set_flag smc_close_active() sock_set_flag __set_bit(DEAD) __set_bit(DONE) Dues to __set_bit is not atomic, the DEAD or DONE might be lost. if the DEAD flag lost, the state SMC_CLOSED will be never be reached in smc_close_passive_work: if (sock_flag(sk, SOCK_DEAD) && smc_close_sent_any_close(conn)) { sk->sk_state = SMC_CLOSED; } else { /* just shutdown, but not yet closed locally */ sk->sk_state = SMC_APPFINCLOSEWAIT; } Replace sock_set_flags or __set_bit to set_bit will fix this problem. Since set_bit is atomic. Fixes: b38d732477e4 ("smc: socket closing and linkgroup cleanup") Signed-off-by: D. Wythe <alibuda@linux.alibaba.com> Reviewed-by: Dust Li <dust.li@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20octeontx2-pf: Free pending and dropped SQEsGeetha sowjanya4-10/+49
[ Upstream commit 3423ca23e08bf285a324237abe88e7e7d9becfe6 ] On interface down, the pending SQEs in the NIX get dropped or drained out during SMQ flush. But skb's pointed by these SQEs never get free or updated to the stack as respective CQE never get added. This patch fixes the issue by freeing all valid skb's in SQ SG list. Fixes: b1bc8457e9d0 ("octeontx2-pf: Cleanup all receive buffers in SG descriptor") Signed-off-by: Geetha sowjanya <gakula@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20selftests: pmtu.sh: fix result checkingHangbin Liu1-1/+1
[ Upstream commit 63e201916b27260218e528a2f8758be47f99bbf4 ] In the PMTU test, when all previous tests are skipped and the new test passes, the exit code is set to 0. However, the current check mistakenly treats this as an assignment, causing the check to pass every time. Consequently, regardless of how many tests have failed, if the latest test passes, the PMTU test will report a pass. Fixes: 2a9d3716b810 ("selftests: pmtu.sh: improve the test result processing") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Acked-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20net: stmmac: xgmac: Enable support for multiple Flexible PPS outputsFurong Xu2-2/+14
[ Upstream commit db456d90a4c1b43b6251fa4348c8adc59b583274 ] From XGMAC Core 3.20 and later, each Flexible PPS has individual PPSEN bit to select Fixed mode or Flexible mode. The PPSEN must be set, or it stays in Fixed PPS mode by default. XGMAC Core prior 3.20, only PPSEN0(bit 4) is writable. PPSEN{1,2,3} are read-only reserved, and they are already in Flexible mode by default, our new code always set PPSEN{1,2,3} do not make things worse ;-) Fixes: 95eaf3cd0a90 ("net: stmmac: dwxgmac: Add Flexible PPS support") Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Furong Xu <0x1207@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20Fix termination state for idr_for_each_entry_ul()NeilBrown1-2/+4
[ Upstream commit e8ae8ad479e2d037daa33756e5e72850a7bd37a9 ] The comment for idr_for_each_entry_ul() states after normal termination @entry is left with the value NULL This is not correct in the case where UINT_MAX has an entry in the idr. In that case @entry will be non-NULL after termination. No current code depends on the documentation being correct, but to save future code we should fix it. Also fix idr_for_each_entry_continue_ul(). While this is not documented as leaving @entry as NULL, the mellanox driver appears to depend on it doing so. So make that explicit in the documentation as well as in the code. Fixes: e33d2b74d805 ("idr: fix overflow case for idr_for_each_entry_ul()") Cc: Matthew Wilcox <willy@infradead.org> Cc: Chris Mi <chrism@mellanox.com> Cc: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20net: r8169: Disable multicast filter for RTL8168H and RTL8107EPatrick Thompson1-1/+3
[ Upstream commit efa5f1311c4998e9e6317c52bc5ee93b3a0f36df ] RTL8168H and RTL8107E ethernet adapters erroneously filter unicast eapol packets unless allmulti is enabled. These devices correspond to RTL_GIGA_MAC_VER_46 and VER_48. Add an exception for VER_46 and VER_48 in the same way that VER_35 has an exception. Fixes: 6e1d0b898818 ("r8169:add support for RTL8168H and RTL8107E") Signed-off-by: Patrick Thompson <ptf@google.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/20231030205031.177855-1-ptf@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20dccp/tcp: Call security_inet_conn_request() after setting IPv6 addresses.Kuniyuki Iwashima2-6/+7
[ Upstream commit 23be1e0e2a83a8543214d2599a31d9a2185a796b ] Initially, commit 4237c75c0a35 ("[MLSXFRM]: Auto-labeling of child sockets") introduced security_inet_conn_request() in some functions where reqsk is allocated. The hook is added just after the allocation, so reqsk's IPv6 remote address was not initialised then. However, SELinux/Smack started to read it in netlbl_req_setattr() after commit e1adea927080 ("calipso: Allow request sockets to be relabelled by the lsm."). Commit 284904aa7946 ("lsm: Relocate the IPv4 security_inet_conn_request() hooks") fixed that kind of issue only in TCPv4 because IPv6 labeling was not supported at that time. Finally, the same issue was introduced again in IPv6. Let's apply the same fix on DCCPv6 and TCPv6. Fixes: e1adea927080 ("calipso: Allow request sockets to be relabelled by the lsm.") Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Acked-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20dccp: Call security_inet_conn_request() after setting IPv4 addresses.Kuniyuki Iwashima1-3/+3
[ Upstream commit fa2df45af13091f76b89adb84a28f13818d5d631 ] Initially, commit 4237c75c0a35 ("[MLSXFRM]: Auto-labeling of child sockets") introduced security_inet_conn_request() in some functions where reqsk is allocated. The hook is added just after the allocation, so reqsk's IPv4 remote address was not initialised then. However, SELinux/Smack started to read it in netlbl_req_setattr() after the cited commits. This bug was partially fixed by commit 284904aa7946 ("lsm: Relocate the IPv4 security_inet_conn_request() hooks"). This patch fixes the last bug in DCCPv4. Fixes: 389fb800ac8b ("netlabel: Label incoming TCP connections correctly in SELinux") Fixes: 07feee8f812f ("netlabel: Cleanup the Smack/NetLabel code to fix incoming TCP connections") Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Acked-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20net: page_pool: add missing free_percpu when page_pool_init failJian Shen1-1/+5
[ Upstream commit 8ffbd1669ed1d58939d6e878dffaa2f60bf961a4 ] When ptr_ring_init() returns failure in page_pool_init(), free_percpu() is not called to free pool->recycle_stats, which may cause memory leak. Fixes: ad6fa1e1ab1b ("page_pool: Add recycle stats") Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Yunsheng Lin <linyunsheng@huawei.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Link: https://lore.kernel.org/r/20231030091256.2915394-1-shaojijie@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20octeontx2-pf: Fix holes in error codeRatheesh Kannoth1-34/+46
[ Upstream commit 7aeeb2cb7a2570bb69a87ad14018b03e06ce5be5 ] Error code strings are not getting printed properly due to holes. Print error code as well. Fixes: 51afe9026d0c ("octeontx2-pf: NIX TX overwrites SQ_CTX_HW_S[SQ_INT]") Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com> Link: https://lore.kernel.org/r/20231027021953.1819959-2-rkannoth@marvell.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20octeontx2-pf: Fix error codesRatheesh Kannoth1-17/+17
[ Upstream commit 96b9a68d1a6e4f889d453874c9e359aa720b520f ] Some of error codes were wrong. Fix the same. Fixes: 51afe9026d0c ("octeontx2-pf: NIX TX overwrites SQ_CTX_HW_S[SQ_INT]") Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com> Link: https://lore.kernel.org/r/20231027021953.1819959-1-rkannoth@marvell.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-12 20:42:55 +0300